On Tue, 4 Jun 2019 at 10:57, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Tue, 4 Jun 2019 at 16:52, Francois Ozog francois.ozog@linaro.org wrote:
On Tue, 4 Jun 2019 at 10:37, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 6/4/19 4:20 PM, Ard Biesheuvel wrote:
On Tue, 4 Jun 2019 at 16: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.
Of course. But that does not mean it should be the job of UEFI secure boot to do so.
For me validating the device-tree means that U-Boot checks a signature added to the device-tree. It is just the same type ofprocess as the one we will do in UEFI secure boot when loading an application like GRUB or Linux.
Even if we use the same algorithms to authenticate a DT as we use to authenticate parts of the OS, conflating the two is a dangerous and slippery slope. The industry today expresses a strong preference towards putting all the security eggs in a single basket, and make Microsoft the owner of all keys relating to secure boot.
Aren't we talking about Arm systems that do not need Microsoft keys?
Yes, we are. And this is a battle I have been fighting for years, but the distros as well as the silicon vendors are only interested in Microsoft owning all the secure boot signing keys, as they do on x86.
This means that if we standardize secure boot as the means to
authenticate DT to the firmware, this may lead to a situation where I can load a DT for a different but similar SoC into my system (given that they are all signed by Microsoft), and possibly circumvent security features since the GPIOs are not wired the same.
So now we have two classes of images, platform and OS. Do we add separate keyrings? Do we add metadata? What else do we need to add beyond what the UEFI spec defines to support this model?
EL3 software (trustedfirmware for instance) validates untrusted
firmware, and probably DTs. Or is U-Boot a consummer of TF provided DT? Does U-Boot provide a DT to OS? I had a discussion with Loic from ST (added) that he sees multiple keys for different parts of the boot.
Yes, that makes sense. But the problem is that UEFI secure boot does not support this model. An image is considered valid if it authenticates against any of the keys in db. And any key in KEK can sign updates to db and dbx. And today's current practice is to include Microsoft keys in both KEK and db.
I have argued time and time again that this is entirely broken as a security model. Any db update that Microsoft has ever signed can be applied to my brand new arm64 system (unless it has been blacklisted explicitly, and my vendor has bothered to ship with an up to date dbt)
I am perfectly happen to reopen that debate as well, by the way :-)
Is it correct to say that Msft could revoke selective keys and prevent the boot of selected devices? If true, in the current geopolitical context, I would assume this is not acceptable... and distros may not have the final word here as it may be regulatory costrainst or customer requirement.