On Tue, Feb 24, 2015 at 10:48 AM, Kay Rydyger <kay.rydyger@yahoo.co.uk> wrote:
The question was [... firmware spies] The answer is [...] to encrypt data.
No, reading bits from platters or the bus is a partial analysis of the whole firmware question. It's already been suggested in links how firmware can hook the users unencrypted boot binaries through to the users kernel. For that matter, a modified boot chain could be stored in the service area. A user would have to use SecureBoot, TPM, IOMMU, TXT, GELI and perhaps other things, all of them properly, having no holes, together, right now, at least three of which they are unlikely to have ubiquitous access to until a couple hardware generations or personal refresh cycles into the future. An ideal full solution for which is yet to come. Not to mention needing to install it all cleanly (from BTW, an install image which has no reproducible build and no cryptographic chain back to the insecure unsigned source repo anyways). But yeah, let's talk circular instead of about possible actually coding defense in depth such as maybe blocking the most common easiest path a malicious opcode will likely take to irrepairably infect clean hardware in the first place... through the drivers ...
There is no threat to freebsd
... because at least Unix is said to be immune to threat... http://www.freebsd.org/security/advisories.html http://www.openbsd.org/errata56.html http://web.nvd.nist.gov/view/vuln/search-results?query=linux+kernel&search_type=last3years&cves=on
Weaknesses of this measure are remote and highly costly for the attacker. If one is such a person of interest
It's already been talked how this tech will be integrated into everyday run of the mill malware. And how users will be subject to infected drives via second purchase, inheritance (both from other people and from other operating systems), use of hosting services, trading, booting CD's, etc. Persistant malware in users boot chains is nasty, users don't have to be of interest or be targeted, the code doesn't care, grandma's surfbox could get it. Please learn to email... trim the original to the minimum needed for context, reply inline below, and stop copying 400 line digests with meaningless digest subject lines out to everyone on the list. On whenever, someone else wrote:
Since the chip holding the firmware has leads through which it is loaded with the firmware, is it not possible to disable or burn (with laser) or cut just the leads through which the chip is WRITTEN to (in order to re-program it)?
Depends on the design. The hacking links or docs from the drive/chip vendors would be more helpful there.