On 15/09/2020 13:35, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 15:34, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 13:25, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 15:22, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 09:33, Heinrich Schuchardt wrote:
Closes: #52
The no-map property of the /reserved-memory device tree nodes is used to signal that a memory region shall not be accessed by the operating system, even not via speculative access.
/reserved-memory nodes without the no-map property describe memory that have special usage by the operating system.
This difference has to be reflected in the memory map returned by GetMemoryMap().
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
source/chapter2-uefi.rst | 13 +++++++++++++ source/references.rst | 4 ++++ 2 files changed, 17 insertions(+)diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 74ef70e..f410c57 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -74,6 +74,19 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.+In the device tree reserved memory in modelled as a /reserved-memory nodes +[RESMEM]_. The reserved-memory node MAY carry either the no-map or the resue +property. It MUST NOT carry both properties as this would be contradictary.
After having looked at reserved-memory.txt in the kernel and the devicetree spec, I think this should just go straight into dtspec or into the kernel tree. I drafted a couple patches yesterday that first imports /reserved-memory into dtspec, and then adds the UEFI annotations. Here's the current patch for the latter:
diff --git a/source/chapter3-devicenodes.rst b/source/chapter3-devicenodes.rst index 3043b8a..647e487 100644 --- a/source/chapter3-devicenodes.rst +++ b/source/chapter3-devicenodes.rst @@ -160,6 +160,12 @@ If the VLE storage attribute is supported, with VLE=0. .. note:: All other standard properties (section :ref:`sect-standard-properties`) are allowed but are optional.
+``/memory`` node and UEFI +~~~~~~~~~~~~~~~~~~~~~~~~~~
+When booting via [UEFI]_, the system memory map is obtained via the +GetMemoryMap() UEFI boot time service as defined in [UEFI]_ § 7.2, +and if present, the OS must ignore any ``/memory`` nodes.
This should cover /memreserve/ entries as well.
What memory type should be used for /memreserve/? The memory reserve block isn't nearly as expressive, so we don't have details about how to use it. Be conservative and specify EfiReservedMemoryType?
Currently, we simply ignore memreserve's like we ignore the memory nodes as well.
Looks like in Linux the memory is reserved without the nomap behaviour (not removed). Unlike with /reserved-memory, EfiBootServicesData won't currently give us the behaviour we want if the kernel is currently ignoring the memory reserved block. (for /reserved-memory, the kernel 'finds' the reservations again during early boot, so the UEFI protections only need to extend to the ExitBootServices() call. With the memory reserved block, the kernel has no way to know if it should continue to respect those reservations after ExitBootServices if it isn't parsing the block.
Should the kernel still respect Memory Reserved block when booting via UEFI? At this point I'm inclined to say yes.
g.
``/memory`` Examples ~~~~~~~~~~~~~~~~~~~~@@ -314,6 +320,9 @@ is ignored. The ``no-map`` and ``reusable`` properties are mutually exclusive and both must not be used together in the same node.
+Dynamic reserved memory regions must not listed in the [UEFI]_ memory map
not be listed
+because they are allocated by the OS after exiting firmware boot services.
Linux implementation notes:
- If a ``linux,cma-default`` property is present, then Linux will use the
@@ -341,6 +350,19 @@ nodes by adding a ``memory-region`` property to the device node. Usage legend: R=Required, O=Optional, OR=Optional but Recommended, SD=See Definition
=======================================================================================================
+``/reserved-memory`` and UEFI +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +When booting via [UEFI]_, static ``/reserved-memory`` regions must +also be listed in the system memory map obtained via the GetMemoryMap() +UEFI boot time service as defined in [UEFI]_ § 7.2. +The reserved memory regions need to be included in the UEFI memory map to +protect them from memory allocations by UEFI applications.
+Reserved regions with the ``no-map`` property must be listed in the memory +map with type ``EfiReservedMemoryType``. +All other reserved regions must be listed with the type +``EfiBootServicesData``.
- ``/reserved-memory`` Example
diff --git a/source/references.rst b/source/references.rst index 961fa20..8400e96 100644 --- a/source/references.rst +++ b/source/references.rst @@ -23,3 +23,7 @@ .. [EPAPR] *Power.org Standard for Embedded Power Architecture Platform Requirements*, power.org, 2011,
https://www.power.org/documentation/power-org-standard-for-embedded-power-ar...
+.. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf`_,
- February 2020, `UEFI Forum http://www.uefi.org`_
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.