On 13/05/2020 13:54, Ard Biesheuvel wrote:
On 5/13/20 2:48 PM, Grant Likely wrote:
On 12/05/2020 18:54, Ard Biesheuvel wrote:
[...]
"""
If a DTB is used to describe the platform to the OS, it must be
installed as a EFI configuration table under the appropriate GUID by
the system firmware before starting any UEFI applications or drivers
that are not part of the system firmware image themselves. Once the
DTB is installed as a configuration table, the system firmware must
not make any modifications to it.
Works for me.
UEFI applications are permitted to replace the installed DTB.
Modifications to the installed DTB are not allowed, but it is
permitted to clone the installed DTB, apply any changes to the clone
and install it as a replacement.
I think this goes too far. Modifying a DTB in place is normal
practice. Why is in not permitted to modify the firmware-provided DTB
in-place?
This is related to the below. If the system firmware is permitted to use
DTB internally, we should either require it to publish a copy, or
require other agents to make a copy. Otherwise, these other agents may
modify the data structure that the firmware relies on for its internal
implementation. Of course, this assumes the internal and external DT are
the same and thus compatible, which may not be the case.
It's probably a bit sloppy in U-Boot land, but that can be cleaned up if
so. When U-Boot does configure itself via DT, it typically has a
separate copy for passing to the OS. I don't think it is a problem to
specify the loaded DTB is handed off and no longer used once EFI
application execution begins. This is the model I was attempting to
describe in my draft text.
I've reworked the draft. Here is the new text I'm proposing (including
some earlier changes that have been discussed):
g.
----
index c42691b..ff80329 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -86,12 +86,41 @@ tables.
- An Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-As stated above, EBBR systems must not provide both ACPI and Devicetree
+EBBR systems must not provide both ACPI and Devicetree
tables at the same time.
Systems that support both interfaces must provide a configuration
mechanism to select either ACPI or Devicetree,
and must ensure only the selected interface is provided to the OS loader.
+Devicetree
+==========
+
+If firmware provides a Devicetree system description then it must be
provided
+in Flattened Devicetree (DTB) format version 17 or higher as described in
+[DTSPEC]_ § 5.1.
+The following GUID must be used in the EFI system table ([UEFI]_ § 4)
+to identify the DTB.
+The DTB must be contained in memory of type EfiACPIReclaimMemory.
+
+.. code-block:: c
+
+ #define EFI_DTB_GUID \
+ EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
+ 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
+
+Firmware must have the DTB resident in memory and installed in the EFI
system table
+before executing any UEFI applications or drivers that are not part of
the system
+firmware image.
+Once the DTB is installed as a configuration table,
+the system firmware must not make any modification to it or reference
any data
+contained within the DTB.
+
+UEFI applications are permitted to modify or replace the loaded DTB.
+System firmware must not depend on any data contained within the DTB.
+If system firmware makes use of a DTB for its own configuration,
+it should use a separate private copy that is not installed in the
+EFI System Table or otherwise be exposed to EFI applications.
+
UEFI Secure Boot (Optional)
---------------------------
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
