On 23/09/11 14:37, Daniel Pittman wrote:
On Thu, Sep 22, 2011 at 21:11, Jason White
<jason(a)jasonjgw.net> wrote:
Daniel Pittman <daniel(a)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