New SecureBoot Concerns Arise With Windows 10

[Luke]

Kernel hackers must be able to boot their kernels

So, now for some thoughts out of this mess.

Secure Boot is probably gonna stay, so what could be a solution for free software ?

The current problem seems to be that M$ is currently the only OS manufacturer with a signing cert (cross-signed root cert ?).
They have their supporting infrastructure in place, while free software does not.
And we cannot, because the 'free software' cert isn't part of Secure Boot yet.

So, the free software community has to choose a party (FSF/EFF etc ?) that it trusts.
* this party should be professional enough to be/become a Root CA
* this party should create a cert for implementation in Secure Boot
* this party should keep the private key very very secret
* this party would have to create a PKI around their root cert

option 1 (the way M$ probably does it):
The root party signs all kernels/boot files.

Which is only practical if:
* it is highly automated and secure
* communication between parties is highly secure
* identity of the parties involved is 100% certain

option 2:
Subsequent signing certs (sub CA's) are generated from the root cert for distributions (Debian/Redhat etc), so they can sign their own kernels.
* dists should be professional/trustworthy enough
* if one of these keys would get compromised, it should be revoked by the root party


Secure Boot is just what it says: it's only boot files + kernel that should be signed.
M$ has implemented it much further than that, but the free software community does not (should not ?) have to do it that way.
Let's keep in mind that a signed kernel can run unsigned software.

* we would be dependent on our distribution of choice to supply us with signed boot files and kernel
* booting your own baked boot files/kernel would only be an option on non-Secure Boot hardware

If this is how it can work, then the vote is on for one party we trust.
Which is to provide a 'free software' root cert for implementation in Secure Boot.


Let's hear your thoughts.

There also must be the option of user keys or boards that can disable secure boot. Otherwise all kernel development is limited to pre-SB boards and all those servers that Big Business relies on Linux for get no more kernel updates. One good buffer overflow and we are exfilling things like root keys from MS servers that run Linux and can no longer be patched because they locked out all the kernel devs...

[ossuser]

There also must be the option of user keys or boards that can disable secure boot. Otherwise all kernel development is limited to pre-SB boards and all those servers that Big Business relies on Linux for get no more kernel updates. One good buffer overflow and we are exfilling things like root keys from MS servers that run Linux and can no longer be patched because they locked out all the kernel devs...

For kernel development on real hardware (as in not virtual) you are probably right.
As testing the new kernel on real hardware would require signing it first.

My post is about a future where opting out of Secure Boot would not be an option anymore.
In that case you need another root to sign off the boot process.

I heard Canonical/Redhat got their key from M$, and that's obviously not what we want.

BTW: has M$ any patents on Secure Boot ?
Hmmm, not sure about that, that could complicate things a lot.

[Luke]

Virtual machines probably not so good for developing kernels for bare hardware

For kernel development on real hardware (as in not virtual) you are probably right.
As testing the new kernel on real hardware would require signing it first.

My post is about a future where opting out of Secure Boot would not be an option anymore.
In that case you need another root to sign off the boot process.

I heard Canonical/Redhat got their key from M$, and that's obviously not what we want.

BTW: has M$ any patents on Secure Boot ?
Hmmm, not sure about that, that could complicate things a lot.

Virtual machines are not the way to test for brand new hardware, I cannot imagine a virtualized environment would really be the same thing. A kernel for hardware that can never boot Linux is of course a waste of time to develop, but if kernels usable on servers can only be written on brand new $$$ servers, that will seriously slow down kernel development for the machines that serve all that content Hollywood wants you to passively consume and buy from Cable TV to watch on your Windows tablet.

Here's a thought on a way to defeat Secure Boot. Suppose you let it boot the Windows Kernel but then replace the Windows init system with one that will stop the Windows boot process and run an exploit against Windows as installed from the original signed installer with no updates. The rest of Windows is deleted from the disk. The exploit crashes the Windows kernel and gains the ability to run arbitrary code. This is then used to kexec into your desired Linux kernel, and commands to shut down any zombies left over from Windows work like ExitBootServices does in UEFI, which also must be called. At this point you have used the Windows kernel as a bootloader for anything you want, then shut it down hard.

A machine locked to a signed Linux kernel would be far easier to deal with, if you can get someone to sign a kernel with Kexec capability. Run an init script that stops boot and kexecs to an unsigned kernel, command line options for it, and the initramfs for it. In this way new kernels could be developed and tested for machines normally locked to say, a particular version or RHEL for server use. The same technique could be used today to permit loading your favorite kernel as a direct Coreboot payload, with an option in the init script to detect a keypress, stop the boot, and bring up a menu for kexec to another kernel or changing kernel command line options.

[ossuser]

@luke: breaking the security like you describe might work for you, but not for millions of Linux users.
I'd rather have a solution that works for everyone.


Wikipedia quote (edited for readability):
#
The UEFI 2.2 specification adds a protocol known as secure boot, which can secure the boot process by preventing the loading of drivers or OS loaders that are not signed with an acceptable digital signature.
1) When secure boot is enabled, it is initially placed in "setup" mode, which allows a public key known as the "Platform key" (PK) to be written to the firmware.
2) Once the key is written, secure boot enters "User" mode, where only drivers and loaders signed with the platform key can be loaded by the firmware.
Additional "Key Exchange Keys" (KEK) can be added to a database stored in memory to allow other certificates to be used, but they must still have a connection to the private portion of the Platform key.
3) Secure boot can also be placed in "Custom" mode, where additional public keys can be added to the system that do not match the private key.
#

Option 2 -> Additional "Key Exchange Keys", that's where we would need our 'free software' root key, isn't it ?

Thinking about it some more, not even the kernel needs to be signed necessarily (but some kernel files might be needed to boot).

UEFI Secure Boot basically seems to be about the files that are needed to boot the system to a 'let's load an OS' state.

Does anyone with UEFI specific knowledge care to comment on this ?

[ossuser]

... for machines normally locked to say, a particular version or RHEL for server use...

Let's hope it will never come to that, Redhat or Canonical would probably like that idea.
However, it looks like systemd (with a lot devs from Redhat) is currently positioning itself in this direction (gummyboot).

A 'free software' root key would allow for different (but only major) distributions, so you would still have a choice.

[chithanh]

Actually, Red Hat plugged the kexec hole for secure boot, by introducing signature checking.

[ossuser]

Actually, Red Hat plugged the kexec hole for secure boot, by introducing signature checking.

But for reaching that (kernel) stage, you have to boot first, isn't it ?

Which most probably is not going to happen if M$ is the only one having the cert in place to get through the boot process.

[Luke]

Red Hat's code seems to allow self-signed certs

Actually, Red Hat plugged the kexec hole for secure boot, by introducing signature checking.

The Red hat code seems to allow a self-signed certificate, which is all we need to be able to run custom kernels. This way you can kexec to a kernel you signed, but it's more difficult for an enemy to covertly replace your custom kernel with his malicious one. This let's yo "have it both ways" if the code really works that way.

This whole mess comes down to control, and to the danger of future generations of computers that answer to their makers and not their users. If it were possible to fab all your own chips, which I doubt it ever will be, this would be totally another matter, as the user and maker would be the same. The NSA would HATE that one, as anyone who feared them would lock them out on both the CPU and the chipset.

[ossuser]

The Red hat code seems to allow a self-signed certificate, which is all we need to be able to run custom kernels. This way you can kexec to a kernel you signed, but it's more difficult for an enemy to covertly replace your custom kernel with his malicious one. This let's yo "have it both ways" if the code really works that way.....

Please forgive me if I get it wrong, but ...

As I understand the workings of Secure Boot (with only M$ cert and you can't turn it off) you'll never get to Linux kexec in the first place.
Because your boot system would not allow it.

That's would be the whole point, and that's why I would like a 'free software' cert to become a part of Secure Boot.
Now, not in a few years when the problem arises.

Anyone with specific knowledge of UEFI/Secure Boot here ?
Is my assumption right ?

[Luke]

That would be decided by OEM's

Please forgive me if I get it wrong, but ...

As I understand the workings of Secure Boot (with only M$ cert and you can't turn it off) you'll never get to Linux kexec in the first place.
Because your boot system would not allow it.

That's would be the whole point, and that's why I would like a 'free software' cert to become a part of Secure Boot.
Now, not in a few years when the problem arises.

Anyone with specific knowledge of UEFI/Secure Boot here ?
Is my assumption right ?

I was assuming in this scenario an OEM that sells server boards and locks them to RHEL or possibly Ubuntu. In the Windows case the equivalent of Kexec would be an exploit against the first part
of the Windows boot that is not locked, or even an exploit against fully booted (but offline) Windows that would crash the kernel and allow arbitrary code equiivalent to Kexec to be run. In this scenario Windows is booted far enough to get past the locked code, then deliberately crashed and an exploit run to get code running on bare metal, this code being a Linux bootloader. All of this done offline, probably by using only a USB network device never inserted until Windows has been crashed and shut down.

Unless MS could stop every buffer overflow every time, and unless they did not permit any unsigned app to run (ever), and unless no app ever had an exploit there would be exactly NO way Micro$oft could keep this stopped. It would differ from running Linux in a VM under Windows in that since Windows is not running it cannot access the network and export personal information, encryption keys, etc. Also greater performance on bare metal. I suppose M$ would pursue legislation against this like their failed 2002 attempt to pass legislation (Broadband TV Promotion Act or some such thing) imposing up to 20 years in prison for posessing a computer containing unlocked software that could defeat DRM.