Le mar. 4 juin 2019 à 17:27, Tom Rini trini@konsulko.com a écrit :
On Tue, Jun 04, 2019 at 10:21:54AM -0400, Francois Ozog wrote:
On Tue, 4 Jun 2019 at 10:00, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Tue, 4 Jun 2019 at 15:55, Francois Ozog francois.ozog@linaro.org 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.
But my point remains the same. If we are accommodating a model where
the
DT is shipped with the OS, the OS can deal with authenticating the DTB files. If the firmware provides the DT, it is a firmware implementation detail how and where it keeps the DTB files internally, as long as it
uses
the official way (i.e., via a UEFI config table) to expose the DT to
the OS.
Rolling all of this into secure boot support (which deals with authenticating OS components/loaders to the firmware) is something we should avoid.
Agreed. There is no such a thing as an OS provided ACPI table.... yet we allow that for DT... strange isn't it?
I think we're getting a bit side tracked. And, depending on what you want to call people having to fixup and recompile DSDT to fix issues... :)
The Linux Kernel happens to be the (generally) authoritative source of DT files, rather than the hardware manufacturer.
To me it looks like walking on the head. I don’t see any OS providing an ACPI table. I think I understand why it happened. But to me it looks like a wrong solution to a real use case: firmware hardware execution environnement is different (probably smaller) than os execution environment. I think this is more about EBBR and it’s compliance. What shall be the right policy ? And then we refine EBBR.
So as a reference platform we can say that an OS provided DT is NOT part
of
the picture. Yet if a vendor still wants to do it, it will be able to. We just don't care.
Now, in the context of standard OTA across SoCs, what shall be
standardized
to support the two DTs (for firmware execution and for OS execution). Are we considering UBoot firmware as a "blob" that embeds those two DTs?
Might
be good enough.
The common case is NOT going to be that the DT is provided embedded within the hardware, please keep that in mind.
EBBR says: “Similarly, devices retained by firmware (i.e., not discoverable by the OS) shall not be accessed by the OS.” so an OS provided DT is a recipe for failure.
-- Tom