On Wed, Jun 19, 2019 at 12:24:36PM -0400, Jon Masters 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.
I know that Ard (Cc'd) had looked into this area, as he was involved in LKML discussions. My understanding is that the vast majority of the issues with kernel lockdown are not architecture specific, and for arm/arm64 we've deliberately avoided introducing architecture-specific functionality which would be problematic for lockdown. I strongly suspect the people you need to speak to are not subscribed to this list (nor do they post on hacker news), and asking questions on LAKML and LKML would be much more valuable. Thanks, Mark. > > 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. > > > > > 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. > > Jon. > > -- > Computer Architect | Sent with my Fedora powered laptop > _______________________________________________ > boot-architecture mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/boot-architecture _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
