On Wed, 19 Jun 2019 at 18:25, Jon Masters jcm@redhat.com wrote:
On 6/19/19 10:56 AM, Francois Ozog wrote:
I was tasked to come back to Linaro TSC with an answer on Linaro and kernel lockdown for UEFI SecureBoot, hence the call for feed back.
So I did some research... The kernel lockdown does not seem to be a full consensus yet: https://news.ycombinator.com/item?id=16761827
I also did some research. There is nobody currently working on lockdown patches for Arm. As in the upstream lockdown effort explicitly is not involving Arm at this stage. I flagged this with Arm several years ago, re-raised it a few months ago, and am raising it again here right now.
- UEFI SecureBoot: boot chain trust
My understanding is that UEFI SecureBoot ensures that the booted UEFI payload is trusted. Should the UEFI payload (a Linux OS) not be that secure it is irrelevant to the UEFI SecureBoot itself.
Sure. But the signed shim loader isn't going to boot a kernel unless it also is trusted. If it boots an untrustable kernel, then the keys are likely to be revoked (as you later mentioned). A Linux distro actually did this and are (from my understanding) going to have consequences for not listening or implementing this correctly. No, it is not safe to even think about booting an untrustable kernel with the signed boot flow.
Now sure, you can have your own platform keys, but then you're going to need to do all of the signing yourself, and not work out of the box.
We need some middle ground here - see below.
...
UEFI SecureBoot does not mandate Microsoft signed keys. But if you use Microsoft keys, I was warned that Microsoft may revoke certificates for non locked down systems. This warning illustrate the absolute need for independence related to UEFI SecureBoot: I can't imagine a system in Europe (particularly in military) prevented to boot because Microsoft revoked a certificate!!!
I know you don't mean anything against Microsoft here, but just in case others get the wrong angle. We actually pushed Arm to go and setup a neutral certificate authority for exactly this reason. Years ago. But nobody has done it. So we are *grateful* that Microsoft are willing to do so. Since they are the only ones will to do it, we'll play by their rules, which means (rightly) not allowing Linux to be used as a malware trojan - the signed path needs to be done right, meaning that we need real lockdown patches implemented properly to do it right at all.
So why again does there need to only a single signing authority? If I run RHEL on my servers, I only care about the RedHat signing key, and perhaps the signing key of the vendor of the NIC if it is a plugin type.
i know it is inconvenient, but it is also a *lot* more secure, so if we takes all this stuff as seriously as we say we do, let's implement it properly and use UEFI secure boot the way it was intended.
By the same reasoning, one of the things on my todo list is to make GRUB work without shim. E.g., if the RHEL installer spots the RedHat certificate in db, why on earth should it bother to install shim in the first place?
As usual, the things that are driven mostly from the distro side are way too much geared towards making things work exactly like on x86, even if it makes no sense whatsoever to do so.