On 23/09/11 14:37, Daniel Pittman wrote:

On Thu, Sep 22, 2011 at 21:11, Jason White <jason@jasonjgw.net> wrote:

...

Daniel Pittman <daniel@rimspace.net> wrote:

...

So, the biggest advantage is that it does work against all those attacks that compromise the kernel and/or drivers to get into the kernel after a restart. Which, indeed, is where many of the "root kit" tools hit, on Windows. That's interesting... and the proposed solution just happens to be the one which also has potential to disadvantage competitors... Well, assuming that the vendors are lazy, yeah. Which /probably/th that the vendors will have an option to turn it off in the configuration whatever, so you can install whatever on it. Because Linux is enough of a server OS, these days, that the low margin, high volume vendors probably don't want to go down the path of cutting off part of their business, and producing two different EFI implementations would cut into that.

Allowing loading another key, probably screwing up any security assurance for !Win32 systems in the process, feels like the cheap option to me.

I think that's exactly what's needed. People should read up on the secure boot process associated with the TPM chips that are in most recent computers, but typically not turned on. If there's a user process to load a new key into the TPM chip, then I don't see a problem with Windows and other OSes being secured in this way. Rather than boot sector viruses, people should probably be thinking about the requirements for full disk encryption to be effective, which is something we want. This basically requires that any non encrypted boot mechanisms must be secured in some fashion, and that's what the TPM implements these checksums for. The other alternative is implementing hardware encryption inside the disk drive itself (as in the hitachi drive that came with my Lenovo x220). This latter is a more expensive option though, and requires BIOS/UEFI support to ask for the password. I'm not clear on how many systems have that. My x220 is a UEFI based system, the TPM can be enabled and disabled from within the bios, and that's protected by the BIOS password. The system ships with the TPM disabled, and so far I haven't played with it. If it shipped with the TPM enabled, I wouldn't have thought that would prevent me installing Linux. I might have to disable it for a bit while I get things set up. I haven't yet gone very far down this road, but I have briefly looked over a 2008 howto at http://www.grounation.org/index.php?post/2008/07/04/8-how-to-use-a-tpm-with-... which includes some details on how one loads a key into the TPM using linux. It's on my to-do list. So far I've just read enough to know that I can do it when I'm ready. So I'm not very worried about booting linux becoming an impossibility. If however hardware manufacturers were to ship systems with TPM enabled and no way to turn it off, or with no way for a user to load their own key, then that would be a different matter. Does the system that Microsoft is mandating necessarily include such user controls in order to be compliant? If not, then that is probably the point we should be aiming any legal efforts at. And perhaps there should be some requirement that if any system is restricted by the keys and ability to change them, such that it is only able to run windows, then that they must advertise that they are *only* compliant with windows 8, rather than just that they *are* compliant with windows 8. I am concerned that it might be harder to boot from a Linux CD in order to install. Not massively harder - it should require only that the TPM be disabled for a while. This will have some impact however on less confident installers. I'd like it to be possible to boot from a CD or USB for anyone who has the BIOS/UEFI password, without making any changes that would affect the subsequent boot. Anti-virus disks are another important one for booting outside the usual OS. I am a bit concerned that I probably won't be able to boot linux from the flash disk on my keyring on most systems in future. It's currently quite convenient. Andrew McNaughton