Thanks Jon for the comments.

On Wed, 19 Jun 2019 at 18:24, 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.

...

1. 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.

shim is not mandatory at all. shim is necessary if there is a controlling entity that makes signature of kernels complex. the boot chain includes Linux. providing that the linux signature is validated, then the boot chain is good.

No, it is not safe to even think about booting an untrustable kernel with the signed boot flow.

"safe" and UEFI SecureBoot compliant are two very different things.

and as I described below, you can obtain a trustable kernel in particular conditions that do not need lockdown. Let's not mix the goals and the means.

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.

...

2. Trustable Linux system

A trustable Linux system is UEFI SecureBoot loaded and make addition precautions to avoid attacks and attacks to the boot chain. If we think of a highly secured Linux, the kernel lockdown is certainly highly desirable but just as many other aspects:

• iommu must be enabled to protect against DMA attacks
• sysfs needs to be cleaned (access rights are not tight enough)
• debugfs need to be banned (problem: some production control operations

are wrongly in debugfs) -SE Linux

• IMA
• ...

Yes, this is why a real audit is required on the Arm side. As I have repeatedly highlighted to the various parties involved as necessary.

...

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.

Well, there is not need to have a unique central authority for the keys.

For instance, it could be desirable that Caterpilar will be the central authority to deal with keys of all ECUs in a Caterpilar mining machine. AWS or other providers such as Verisign could deliver a "Certificate Authority as a Service" as a turn key solution for those willing to operate such an authority. The need for Arm to have a central authority may exist. I would be willing to promote that discussion in the context of device onboarding activities happening between Intel and Arm.

Jon.

-- Computer Architect | Sent with my Fedora powered laptop

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.

...

1. 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.