On 6/4/19 3:55 PM, Francois Ozog wrote:
On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Tue, 4 Jun 2019 at 15:44, Francois Ozog francois.ozog@linaro.org wrote:
Hi Ard,
On Fri, 31 May 2019 at 13:35, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Fri, 31 May 2019 at 19:25, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Grant,
I see two ways to handle this that fits with the Secure Boot authentication path:
Option 1: Leave it to the OS loader We could simply say that if the OS wants to replace the DTB, then it should take care of authentication itself within the OS loader
(possibly
the in-kernel UEFI stub) and install a replacement DTB in the configuration table before calling exit boot services. In this
scenario,
U-Boot doesn't authenticate the DTB at all.
In fact, Option 1 is pretty close to what is required for the initrd.
I wonder if it is possible to wrap the DTB with a PE/COFF so that
the os
loader can use load_image to authenticate and retrieve the data
without
actually executing the image. That would allow for the DTB & initrd
to
be authenticated in the same way as the kernel.
I asked around on this prior to the email, but i think it boils down to "UEFI is intended to authenticate bootable images for the platform",
so i doubt
this will be allowed.
The point I raised when we discussed this is that UEFI is an interface between the firmware and the OS, and it is up to the firmware to *provide* the DT not the other way around.
Whether the firmware reuses some of the existing machinery if it chooses to load the DT it provides from an arbitrary file on the file system is an implementation detail, and shouldn't be part of how we design the interface. The more we standardize this and the more we make it similar to how the OS loader is authenticated, the more likely it becomes that it will be relied upon for DTs that are bundled with the OS, which is a practice we are trying very hard to move away from.
I have the impression that OS provided DT is a bad solution to a real problem: There should be a Firmware hardware environment (what to initialize, use...) and a OS hardware environment. Both should be signed, and controlled by the firmware. So I would try to find a way to supply firmware with two DTs, or more likely one DT and one OS overlay (if overlays can remove some hardware).
If the OS provides a DT to itself, what is the point of pretending that it has been authenticated to the firmware?
Agreed, that is stupid! I mispresented my idea: I talk about two DTs controlled by hardware/Firmware provider. OS shall be a consumer only.
In a perfect world firmware would provide the authoritative source of the device tree. The current situation has device trees developed in the context of Linux and U-Boot picking them up. U-Boot is lagging far behind Linux. Whenever I wanted to change a device tree in U-Boot I was told to first get that change into Linux. I see no commitment to change this process.
Device-trees are provided by U-Boot to Linux as UEFI configuration tables. If a device-tree is malicious it may lead to the destruction of hardware. So whatever U-Boot provides as a device-tree to Linux should be validated.
Best regards
Heinrich