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. + +A 'no-map' reserved memory node describes memory that the UEFI payload MUST NOT +access. It MUST be modelled as a EfiReservedMemoryType entry in the memory map. + +A reserved memory without the 'no-map' describes memory that MAY be used by the +UEFI payload after ExitBootServices(). It MUST be modelled as a memory map entry +that can only be used by the UEFI payload after ExitBootServices(). It +is recommended to use EfiBootServicesData. The node MUST NOT be modelled as +EfiReservedMemoryType and NOT as EfiConventionalMemory. + Configuration Tables --------------------
diff --git a/source/references.rst b/source/references.rst index 1eb0509..2434137 100644 --- a/source/references.rst +++ b/source/references.rst @@ -16,6 +16,10 @@ https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Interface.pdf`_ 30 January 2015, `Arm Limited http://arm.com`_
+.. [RESMEM] `Reserved memory regions + https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt`_, + 21 July 2020, Linux kernel + .. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirements.pdf`_ 8 March 2016, `Arm Limited http://arm.com`_ -- 2.28.0
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.
``/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 +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.
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.
``/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.
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?
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 mapnot 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.
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.
``/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 mapnot 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.
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.
On Tue, 15 Sep 2020 at 15:59, Grant Likely grant.likely@arm.com wrote:
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.
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservation
On 15/09/2020 14:02, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 15:59, Grant Likely grant.likely@arm.com wrote:
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.
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservation
Does that still make sense? I understand why it was done, but is it right to ignore those reservations outright? As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
g. 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.
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
> +``/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.
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
/ Leif
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 15.09.20 15:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
>> +``/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.
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
The device-tree spec says they are used for device tree blobs. So I guess in the memory map returned by GetMemoryMap() they would have to be EfiACPIReclaimMemory like the area for the device-tree itself. We should define this in the EBBR.
In the device-tree spec an example showing the syntax of /memreserve/ nodes should be added.
Best regards
Heinrich
/ Leif
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 15/09/2020 14:59, Heinrich Schuchardt wrote:
On 15.09.20 15:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
>>> +``/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.
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
The device-tree spec says they are used for device tree blobs. So I guess in the memory map returned by GetMemoryMap() they would have to be EfiACPIReclaimMemory like the area for the device-tree itself. We should define this in the EBBR.
What bit is that? I see the text saying /memreserve/ adds an entry to the blob's reservation table, but not that it is used for device tree blobs:
Memory reservations define an entry for the devicetree blob’s memory reservation table. They have the form: e.g., /memreserve/ <address> <length>; Where <address> and <length> are 64-bit C-style integers.
g.
In the device-tree spec an example showing the syntax of /memreserve/ nodes should be added.
Best regards
Heinrich
/ Leif
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
Not quite that simple. We're not talking about a clean cut-over from non-UEFI to UEFI platforms, but rather a phased transition where with a given DT, both the non-UEFI and UEFI boot paths need to work. e.g., U-Boot platforms where most people are using 'bootm', but want to start encouraging them to use the UEFI infrastructure.
Or in other words, the master source of information is the .dts file, not the firmware itself.
The other issue is that the reserved memory region may not be about firmware at all, but rather a memory layout that is wanted only by the OS. Regardless of the approach we take here, those regions must be respected.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should not be an error to use /memreserve/. That creates a hard break between UEFI and non-UEFI boot paths for /memreserve/. Updating the memory map is fine, which leads to the question of what memory type should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
Other options?
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
/ Leif
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
On Tue, 15 Sep 2020 at 17:05, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
Not quite that simple. We're not talking about a clean cut-over from non-UEFI to UEFI platforms, but rather a phased transition where with a given DT, both the non-UEFI and UEFI boot paths need to work. e.g., U-Boot platforms where most people are using 'bootm', but want to start encouraging them to use the UEFI infrastructure.
Or in other words, the master source of information is the .dts file, not the firmware itself.
The other issue is that the reserved memory region may not be about firmware at all, but rather a memory layout that is wanted only by the OS. Regardless of the approach we take here, those regions must be respected.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should not be an error to use /memreserve/. That creates a hard break between UEFI and non-UEFI boot paths for /memreserve/. Updating the memory map is fine, which leads to the question of what memory type should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
I wouldn't expect so. Unlike /reserved-memory nodes, which can be referenced by other nodes and explicitly tagged as reusable, /memreserve/s are anonymous holes that are punched into the memory map, so I don't see how a driver would be able to get a reference to that memory (and gets its linear address if it _happens_ to be in lowmem in the first place.)
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
EfiRuntimeServicesData is not covered by the linear map, but will map it in the EFI page tables for access by the firmware itself at runtime, so it is not an option here.
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
/ Leif
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
On 15/09/2020 15:16, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 17:05, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
Not quite that simple. We're not talking about a clean cut-over from non-UEFI to UEFI platforms, but rather a phased transition where with a given DT, both the non-UEFI and UEFI boot paths need to work. e.g., U-Boot platforms where most people are using 'bootm', but want to start encouraging them to use the UEFI infrastructure.
Or in other words, the master source of information is the .dts file, not the firmware itself.
The other issue is that the reserved memory region may not be about firmware at all, but rather a memory layout that is wanted only by the OS. Regardless of the approach we take here, those regions must be respected.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should not be an error to use /memreserve/. That creates a hard break between UEFI and non-UEFI boot paths for /memreserve/. Updating the memory map is fine, which leads to the question of what memory type should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
I wouldn't expect so. Unlike /reserved-memory nodes, which can be referenced by other nodes and explicitly tagged as reusable, /memreserve/s are anonymous holes that are punched into the memory map, so I don't see how a driver would be able to get a reference to that memory (and gets its linear address if it _happens_ to be in lowmem in the first place.)
In the typical use case, the driver doesn't directly use the /memreserve/ entry, but rather knowledge of the hole is implicit; the driver expects it to exist via some other mechanism. E.g., a property in the device node. If /memreserve/ gets cleared out, the device node will probably still try to use the region as if it had been reserved.
e.g.: powerpc/boot/dts/akebono.dts: <0x1f00000 0x100000> is reserved, and then used in the cpu-release-address property. This is a case where the memory should still be in the linear map.
These are old use cases, and /memreserve/ is definitely deprecated in favour of the /reserved-memory node, but it has users and I absolutely do not want to create barriers to adopting the UEFI boot flow.
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
EfiRuntimeServicesData is not covered by the linear map, but will map it in the EFI page tables for access by the firmware itself at runtime, so it is not an option here.
Ah, right. So that isn't right either.
g.
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.
On Tue, 15 Sep 2020 at 17:33, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 15:16, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 17:05, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
Not quite that simple. We're not talking about a clean cut-over from non-UEFI to UEFI platforms, but rather a phased transition where with a given DT, both the non-UEFI and UEFI boot paths need to work. e.g., U-Boot platforms where most people are using 'bootm', but want to start encouraging them to use the UEFI infrastructure.
Or in other words, the master source of information is the .dts file, not the firmware itself.
The other issue is that the reserved memory region may not be about firmware at all, but rather a memory layout that is wanted only by the OS. Regardless of the approach we take here, those regions must be respected.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should not be an error to use /memreserve/. That creates a hard break between UEFI and non-UEFI boot paths for /memreserve/. Updating the memory map is fine, which leads to the question of what memory type should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
I wouldn't expect so. Unlike /reserved-memory nodes, which can be referenced by other nodes and explicitly tagged as reusable, /memreserve/s are anonymous holes that are punched into the memory map, so I don't see how a driver would be able to get a reference to that memory (and gets its linear address if it _happens_ to be in lowmem in the first place.)
In the typical use case, the driver doesn't directly use the /memreserve/ entry, but rather knowledge of the hole is implicit; the driver expects it to exist via some other mechanism. E.g., a property in the device node. If /memreserve/ gets cleared out, the device node will probably still try to use the region as if it had been reserved.
e.g.: powerpc/boot/dts/akebono.dts: <0x1f00000 0x100000> is reserved, and then used in the cpu-release-address property. This is a case where the memory should still be in the linear map.
That depends on how the boot CPU accesses this memory - a quick scan shows that many drivers ioremap() this address rather than access it via the linear mapping.
These are old use cases, and /memreserve/ is definitely deprecated in favour of the /reserved-memory node, but it has users and I absolutely do not want to create barriers to adopting the UEFI boot flow.
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
EfiRuntimeServicesData is not covered by the linear map, but will map it in the EFI page tables for access by the firmware itself at runtime, so it is not an option here.
Ah, right. So that isn't right either.
g.
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.
On 15.09.20 16:16, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 17:05, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
Not quite that simple. We're not talking about a clean cut-over from non-UEFI to UEFI platforms, but rather a phased transition where with a given DT, both the non-UEFI and UEFI boot paths need to work. e.g., U-Boot platforms where most people are using 'bootm', but want to start encouraging them to use the UEFI infrastructure.
Or in other words, the master source of information is the .dts file, not the firmware itself.
The other issue is that the reserved memory region may not be about firmware at all, but rather a memory layout that is wanted only by the OS. Regardless of the approach we take here, those regions must be respected.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should not be an error to use /memreserve/. That creates a hard break between UEFI and non-UEFI boot paths for /memreserve/. Updating the memory map is fine, which leads to the question of what memory type should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
I wouldn't expect so. Unlike /reserved-memory nodes, which can be referenced by other nodes and explicitly tagged as reusable, /memreserve/s are anonymous holes that are punched into the memory map, so I don't see how a driver would be able to get a reference to that memory (and gets its linear address if it _happens_ to be in lowmem in the first place.)
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
EfiRuntimeServicesData is not covered by the linear map, but will map it in the EFI page tables for access by the firmware itself at runtime, so it is not an option here.
The device-tree spec specifically says /mmemreserve/ serve to "define an entry for the devicetree blob’s memory reservation table."
If I look at Linux code I find things like:
/* First 4KB has trampoline code for secondary cores. */ /memreserve/ 0x00000000 0x0001000;
/* firmware-provided startup stubs live here, where the secondary CPUs are * spinning. */ /memreserve/ 0x00000000 0x00001000;
/memreserve/ 0x10000000 0x0004000;*/ /* DSP RAM */
CPUs with a 'spin-table' enable-method "should spin outside of the kernel in a reserved area of memory (communicated to the kernel by a /memreserve/ region in the device tree".
This usage is not what I would have understood under the description in the devicetree spec. So the DT spec needs some clarification.
The problem with EfiRuntimeServicesData is that it can be moved anywhere in the virtual address space via SetVirtualAddressMap(). But do we know that the firmware can handle such a relocation?
Best regards
Heinrich
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
/ Leif
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 15/09/2020 15:36, Heinrich Schuchardt wrote:
On 15.09.20 16:16, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 17:05, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
Not quite that simple. We're not talking about a clean cut-over from non-UEFI to UEFI platforms, but rather a phased transition where with a given DT, both the non-UEFI and UEFI boot paths need to work. e.g., U-Boot platforms where most people are using 'bootm', but want to start encouraging them to use the UEFI infrastructure.
Or in other words, the master source of information is the .dts file, not the firmware itself.
The other issue is that the reserved memory region may not be about firmware at all, but rather a memory layout that is wanted only by the OS. Regardless of the approach we take here, those regions must be respected.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should not be an error to use /memreserve/. That creates a hard break between UEFI and non-UEFI boot paths for /memreserve/. Updating the memory map is fine, which leads to the question of what memory type should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
I wouldn't expect so. Unlike /reserved-memory nodes, which can be referenced by other nodes and explicitly tagged as reusable, /memreserve/s are anonymous holes that are punched into the memory map, so I don't see how a driver would be able to get a reference to that memory (and gets its linear address if it _happens_ to be in lowmem in the first place.)
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
EfiRuntimeServicesData is not covered by the linear map, but will map it in the EFI page tables for access by the firmware itself at runtime, so it is not an option here.
The device-tree spec specifically says /mmemreserve/ serve to "define an entry for the devicetree blob’s memory reservation table."
I think this is just poorly worded. It would be better written as: "Memory reservations create entries in the devicetree blob’s memory reservation table."
If I look at Linux code I find things like:
/* First 4KB has trampoline code for secondary cores. */ /memreserve/ 0x00000000 0x0001000;
/* firmware-provided startup stubs live here, where the secondary CPUs are
- spinning.
*/ /memreserve/ 0x00000000 0x00001000;
/memreserve/ 0x10000000 0x0004000;*/ /* DSP RAM */
CPUs with a 'spin-table' enable-method "should spin outside of the kernel in a reserved area of memory (communicated to the kernel by a /memreserve/ region in the device tree".
This usage is not what I would have understood under the description in the devicetree spec. So the DT spec needs some clarification.
The problem with EfiRuntimeServicesData is that it can be moved anywhere in the virtual address space via SetVirtualAddressMap(). But do we know that the firmware can handle such a relocation?
Best regards
Heinrich
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
/ Leif
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
On 15.09.20 16:50, Grant Likely wrote:
On 15/09/2020 15:36, Heinrich Schuchardt wrote:
On 15.09.20 16:16, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 17:05, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
> The EFI stub in Linux removes /memreserve/ entries from the DT > before > handing it to the kernel proper. > > commit 0ceac9e094b065fe3fec19669740f338d3480498 > Author: Mark Salter msalter@redhat.com > Date: Mon Sep 8 13:01:08 2014 -0400 > > efi/arm64: Fix fdt-related memory reservation
Does that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
Not quite that simple. We're not talking about a clean cut-over from non-UEFI to UEFI platforms, but rather a phased transition where with a given DT, both the non-UEFI and UEFI boot paths need to work. e.g., U-Boot platforms where most people are using 'bootm', but want to start encouraging them to use the UEFI infrastructure.
Or in other words, the master source of information is the .dts file, not the firmware itself.
The other issue is that the reserved memory region may not be about firmware at all, but rather a memory layout that is wanted only by the OS. Regardless of the approach we take here, those regions must be respected.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should not be an error to use /memreserve/. That creates a hard break between UEFI and non-UEFI boot paths for /memreserve/. Updating the memory map is fine, which leads to the question of what memory type should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
I wouldn't expect so. Unlike /reserved-memory nodes, which can be referenced by other nodes and explicitly tagged as reusable, /memreserve/s are anonymous holes that are punched into the memory map, so I don't see how a driver would be able to get a reference to that memory (and gets its linear address if it _happens_ to be in lowmem in the first place.)
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
EfiRuntimeServicesData is not covered by the linear map, but will map it in the EFI page tables for access by the firmware itself at runtime, so it is not an option here.
The device-tree spec specifically says /mmemreserve/ serve to "define an entry for the devicetree blob’s memory reservation table."
I think this is just poorly worded. It would be better written as: "Memory reservations create entries in the devicetree blob’s memory reservation table."
Shouldn't the description of /memreserve/ refer to chapter 5.3 Memory Reservation Block? E.g.
"Memory reservations blocks (see chapter 5.3) are represented by lines of the form
/memreserve/ <address> <length>;
where <address> and <length> are 64-bit C-style integers, e.g.
/memreserve/ 0x10000000 0x0004000;"
Some requirements in chapter 5.3.1 sound similar to the description of the no-map sub-nodes of /reserved-memory, e.g. speculative access is prohibited:
"Any memory that is declared in a memory node and is accessed by the boot program or caused to be accessed by the boot program after client entry must be reserved. Examples of this type of access include (e.g., speculative memory reads through a non-guarded virtual page)."
So in line with our discussion concerning no-map EfiReservedMemoryType seems the most appropriate.
UEFI runtime drivers will be relocated by SetVirtualMemoryMap(). So the requirement in the above citation does not make much sense for memory that is EfiRuntimeServicesCode or EfiRuntimeServicesData. So those should not be modeled as /memreserve/. Just another issue with the DT spec.
Best regards
Heinrich
If I look at Linux code I find things like:
/* First 4KB has trampoline code for secondary cores. */ /memreserve/ 0x00000000 0x0001000;
/* firmware-provided startup stubs live here, where the secondary CPUs are * spinning. */ /memreserve/ 0x00000000 0x00001000;
/memreserve/ 0x10000000 0x0004000;*/ /* DSP RAM */
CPUs with a 'spin-table' enable-method "should spin outside of the kernel in a reserved area of memory (communicated to the kernel by a /memreserve/ region in the device tree".
This usage is not what I would have understood under the description in the devicetree spec. So the DT spec needs some clarification.
The problem with EfiRuntimeServicesData is that it can be moved anywhere in the virtual address space via SetVirtualAddressMap(). But do we know that the firmware can handle such a relocation?
Best regards
Heinrich
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Sure. They can be applied in the UEFI memory map. By u-boot, during boot.
/ Leif
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
On 15/09/2020 17:00, Heinrich Schuchardt wrote:
On 15.09.20 16:50, Grant Likely wrote:
On 15/09/2020 15:36, Heinrich Schuchardt wrote:
On 15.09.20 16:16, Ard Biesheuvel wrote:
[...]>>>> EfiRuntimeServicesData is not covered by the linear map, but will map
it in the EFI page tables for access by the firmware itself at runtime, so it is not an option here.
The device-tree spec specifically says /mmemreserve/ serve to "define an entry for the devicetree blob’s memory reservation table."
I think this is just poorly worded. It would be better written as: "Memory reservations create entries in the devicetree blob’s memory reservation table."
Shouldn't the description of /memreserve/ refer to chapter 5.3 Memory Reservation Block? E.g.
"Memory reservations blocks (see chapter 5.3) are represented by lines of the form
/memreserve/ <address> <length>;where <address> and <length> are 64-bit C-style integers, e.g.
/memreserve/ 0x10000000 0x0004000;"
I like that language & layout. I've pulled it into the draft patch. Thanks!
Some requirements in chapter 5.3.1 sound similar to the description of the no-map sub-nodes of /reserved-memory, e.g. speculative access is prohibited:
"Any memory that is declared in a memory node and is accessed by the boot program or caused to be accessed by the boot program after client entry must be reserved. Examples of this type of access include (e.g., speculative memory reads through a non-guarded virtual page)."
So in line with our discussion concerning no-map EfiReservedMemoryType seems the most appropriate.
UEFI runtime drivers will be relocated by SetVirtualMemoryMap(). So the requirement in the above citation does not make much sense for memory that is EfiRuntimeServicesCode or EfiRuntimeServicesData. So those should not be modeled as /memreserve/. Just another issue with the DT spec.
Okay. I'm convinced. I'll specify EfiReservedMemoryType for memreserve.
g.
On Tue, Sep 15, 2020 at 15:04:44 +0100, Grant Likely wrote:
On 15/09/2020 14:46, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote:
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright?
Yes. It is duplication of (sources of) information, forcing the operating system to make runtime, or compile time, judgement calls of which source(s) of information to respect.
Not quite that simple. We're not talking about a clean cut-over from non-UEFI to UEFI platforms, but rather a phased transition where with a given DT, both the non-UEFI and UEFI boot paths need to work. e.g., U-Boot platforms where most people are using 'bootm', but want to start encouraging them to use the UEFI infrastructure.
Sure. They can keep their reservations in the device tree, but if a platform boots in UEFI mode, those reservations should be present in the UEFI memory map. Then linux can keep ignoring the DT reservations if booted through the EFI stub.
Or in other words, the master source of information is the .dts file, not the firmware itself.
This does not absolve u-boot from doing something sensible with what it's passed. This would not be the first thing u-boot would be runtime-processing the DT for.
The other issue is that the reserved memory region may not be about firmware at all, but rather a memory layout that is wanted only by the OS. Regardless of the approach we take here, those regions must be respected.
As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
That should also make it easy to intercept? Like putting a hook in the DT update code that triggers build error/warning (or even update the UEFI memory map) if someone is trying to memreserve with the UEFI interface enabled.
It should not be an error to use /memreserve/. That creates a hard break between UEFI and non-UEFI boot paths for /memreserve/. Updating the memory map is fine, which leads to the question of what memory type should be used?
EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
Other options?
I'll defer to Ard on the actual selection.
But while care should take not to actively *break* Linux (esp wrt backwards compatibility), if we end up picking one over the other based only (or mainly) on Linux internals, we need to very clearly call that out in the spec.
Regards,
Leif
On 15/09/2020 16:31, Leif Lindholm wrote:
On Tue, Sep 15, 2020 at 15:04:44 +0100, Grant Likely wrote:
On 15/09/2020 14:46, Leif Lindholm wrote: EfiBootServicesData: Memory still gets mapped in the linear map, but nothing protects it after ExitBootServices (would require leaving /memreserve/ intact so the OS knows to protect them).
EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but causes a change in behaviour. The memory will not appear in the linear map. This will possibly cause problems with existing drivers
EfiRuntimeServicesData: Keeps the region protected and in the linear map, but feels 'wrong'. An OS might decide to reclaim it anyway if it doesn't use runtime services (against spec?).
Other options?
I'll defer to Ard on the actual selection.
But while care should take not to actively *break* Linux (esp wrt backwards compatibility), if we end up picking one over the other based only (or mainly) on Linux internals, we need to very clearly call that out in the spec.
That's certainly my intent. This is undefined behaviour right now, so Linux behaviour is the de-facto starndard. I'd like to get that coded into a spec.
g. 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.
On Tue, 15 Sep 2020 at 16:15, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 14:02, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 15:59, Grant Likely grant.likely@arm.com wrote:
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.
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright? As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Yes, but by the firmware, not the OS, otherwise we hit the same issue where EFI apps may use the memory because they don't understand DT.
So the correct thing to do here is to make sure that /memreserve/s are accounted for in the memory map. The problem is that listing them as EfiBootServicesData is not sufficient, since the original /memreserve/ is hidden from the OS, and I am reluctant to change that at this point.
Looking at the way /memreserve/s are being used today, I'd argue that EfiReservedMemory is more appropriate for them anyway, so I propose we add some guidance that it is the firmware's job to ensure that /memreserve/s appear as EfiReservedMemory in the EFI memory map.
On 15.09.20 15:49, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 16:15, Grant Likely grant.likely@arm.com wrote:
On 15/09/2020 14:02, Ard Biesheuvel wrote:
On Tue, 15 Sep 2020 at 15:59, Grant Likely grant.likely@arm.com wrote:
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.
The EFI stub in Linux removes /memreserve/ entries from the DT before handing it to the kernel proper.
commit 0ceac9e094b065fe3fec19669740f338d3480498 Author: Mark Salter msalter@redhat.com Date: Mon Sep 8 13:01:08 2014 -0400
efi/arm64: Fix fdt-related memory reservationDoes that still make sense? I understand why it was done, but is it right to ignore those reservations outright? As more U-Boot platforms turn on UEFI there could be unexpected consequences if the memory reservation block are silently ignored. I'm think that on the U-Boot platforms it is more likely that /memreserve/ is in use.
It should be fine for /memreserve/ entries to get applied to the memmap during boot. Are there problems that I'm missing?
Yes, but by the firmware, not the OS, otherwise we hit the same issue where EFI apps may use the memory because they don't understand DT.
So the correct thing to do here is to make sure that /memreserve/s are accounted for in the memory map. The problem is that listing them as EfiBootServicesData is not sufficient, since the original /memreserve/ is hidden from the OS, and I am reluctant to change that at this point.
Looking at the way /memreserve/s are being used today, I'd argue that EfiReservedMemory is more appropriate for them anyway, so I propose we add some guidance that it is the firmware's job to ensure that /memreserve/s appear as EfiReservedMemory in the EFI memory map.
EfiReservedMemory would mean that the area shall never be read by the OS. This does not make sense to me for device tree blobs.
Best regards
Heinrich
boot-architecture@lists.linaro.org
-
Ard Biesheuvel -
Grant Likely -
Heinrich Schuchardt -
Leif Lindholm