On 11/14/23 00:07, Jon Humphreys wrote:
Daniel Thompson <daniel.thomp...@linaro.org> writes:
On Mon, Nov 13, 2023 at 11:18:04AM -0600, Jon Humphreys wrote:
Basic (dumb) questions:
-----------------------
- why is EBBR dictating the location of firmwares? The firmware
locations are a contract with the boot ROM and subsequent stages,
leading up to the OSloader. The OSloader hand-off interface is the
real EBBR contract with an OS provider, I would think.
Mostly it recommends rather that dictates...
ok, thanks for the reminder on should vs shall. Re-looking at the spec,
there are no SHALLS regarding firmware locations.
Firmware locations:
-------------------
- the EBBR states that a dedicated partition is preferred for storing
firmware. This seems to imply that all firmwares will be in a single
location. This isn't true in many cases (eg, some partitions aren't
large enough and subsequent stages are loaded from a different
partition). Is there guidance (or should be guidance) in EBBR on how
to handle these scenarios?
Not sure what you mean here. In general if a partition containing a
filesystem isn't big enough then we can just make it bigger...
Not always. Consider a eMMC hardware partition that is limited in size.
For example, BeaglePlay will put the first stage SPL in the eMMC hardware
partition
and other stages (eg, u-boot) in the UDA partition, so that all stages
will fit.
From what you have said, the main point is to reduce the possibility of
the OS messing with the firmware, so the spec recommends that the
firmware be in dedicated partitions. This is clear at the beginning of
chapter 4:
In general, EBBR compliant platforms should use dedicated
storage for boot firmware images and data ...
What confused me is that 4.2 goes a bit further is specifying firmware
to be stored in "a dedicated firmware partition". (But no SHALLs here!)
Maybe replace "a dedicated firmware partition" with "dedicated firmware
partitions".
Device Tree:
------------
- The EBBR requires a device tree file (or ACPI table). It makes
complete theoretical sense that the board firmware should supply the
DTB, since it is (in theory) a description of the hardware, which
obviously doesn't change. But the unfortunate reality is that the
device tree is always changing to stay in sync with the kernel. My
experience is that OS images ship with a corresponding device
tree. But the device tree location is one example where the EBBR does
not specify a convention. How can the EBBR handle this reality so
that we can standardize where an OS vendor can place its version of
the DTB?
Does EBBR need to specify that? OS will normally provide an
OS bootloader (grub, systemd-boot, etc) and since the OS "owns"
the configuration for that bootloader is already has full
control over where alternative DTs are loaded from.
Note also the discusison w.r.t. the EFI_DT_FIXUP_PROTOCOL which
is a potentially useful EBBR feature to help support OS provided
device trees.
Your point is that if the OS cares enough about using a particular DTB,
then it should specify it in the OS loader (eg, "devicetree" grub2
command), right? True, but I wouldn't say it is normal. I don't see
Debian or Fedora using it. Instead I see them relying on conventions
GRUB's devicetree command is only available if secure boot is disabled.
Ubuntu uses it on RISC-V platforms.
that don't work for all vendors. So there needs to be some influence to
have these guys start using OS loader commands to explicitly specify the DTB.
And yes, DTB fix-up would be an issue.
U-Boot implements the EFI_DT_FIXUP_PROTOCOL for this purpose and
Ubuntu's GRUB invokes it.
Alternately, we could add some standard to the EBBR that specifies where
an OS should put a DTB if it wants the firmware to pick it up. Then,
that DTB goes through the normal firmware handling, including fix-ups.
(We would need to factor in security, though, but this is true
regardless of the approaches taken.)
The problem here is that sometimes device-trees are not forward and
backward compatible and EDK II and U-Boot don't know which kernel will
be booted if GRUB is used.
Another gap is that there is no convention on signing device-trees. So
any device-tree coming from the OS is a gap in secure boot. Signed
unified kernel images (UKI) comprising kernel, initrd, device-trees
could be a solution.
Best regards
Heinrich
_______________________________________________
boot-architecture mailing list -- boot-architecture@lists.linaro.org
To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
