On Wed, 2010-03-31 at 16:43 -0400, Tom "spot" Callaway wrote: > I'm of the opinion that we shouldn't be enabling "dead code" chunks at > random, especially not in situations like this where the primary use is > to encourage vendor utilization of closed source binary blobs or > trusting a hardware vendor in matters of encryption. I'm... slightly uncomfortable with this line of argument. I have a little trouble distinguishing the TXT use case from hardware passwords on hard drives. It's an ATA feature; hdparm has support for it. It depends on an implementation that's buried in the drive's firmware, and you'd hope a competent vendor would have some quantity of encryption involved with it to defeat obvious physical attacks. Normal people never use it, but we've enabled them to do so, and they get to keep both pieces. Or another analogy: AES-NI processors almost certainly have some amount of it implemented in microcode. Should we refuse to upload microcode updates for them? I think it's a goofy feature, and I think anyone who actually trusts Intel's measurement firmware's resistance to attack is out of their mind. But I have difficulty coming up with a dogmatic argument against it. - ajax
_______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
