Hi
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 agree with Linus https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1654795.html: we should distinguish UEFI SecureBoot and how to achieve a highly secured Operating System runtime environment.
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.
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 - ...
In my view, we shall not mix the goal and the means to achieve the goal.... For instance, kernel lock down prevents iopl system call which prevents UIO and UIO enabled DPDK drivers. A vendor may evaluate that the security level achieved without kernel lockdown is in line with its objectives to achieve a trustable Linux system: loadable modules disabled by the kernel, kernel embedded initramfs, IMA... As a result, UEFI SecureBoot to secure the boot chain combined with selected Linux hardening can achieve a Trustable Linux System.
As per LEDGE both are highly important I would say that 1) does not need 2) to be complete.
The way to achieve 2) is project dependent. The LEDGE RP will need kernel lockdown because we will allow loadable modules. SoC vendors deriving a product out of LEDGE RP, may take different provisions as per customer projects, in particular, they may derive a version without lockdown but still trustable.
There is an additional twists to this.
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!!!
Cheers
FF