Le mar. 4 juin 2019 à 17:31, Tom Rini trini@konsulko.com a écrit :
On Tue, Jun 04, 2019 at 10:25:23AM -0400, Francois Ozog wrote:
On Tue, 4 Jun 2019 at 10:17, Heinrich Schuchardt xypron.glpk@gmx.de
wrote:
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.
In a perfect world, U-Boot shall lead and we should work towards that if not in place. There is no sch a thing as a Linux validated ACPI table, so why for DT?
There _is_ such a thing as a validated ACPI table and functionally ACPI tables on x86 are validated with Windows. This is no different.
I think it may be good to validate but not provide. There is no Linux provided ACPI table right ? So I get the point to validate a DT.
-- Tom