Thanks Jon for the comments. On Wed, 19 Jun 2019 at 18:24, Jon Masters <[email protected]> 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 > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
