On 15.09.20 15:49, Ard Biesheuvel wrote: > On Tue, 15 Sep 2020 at 16:15, Grant Likely <[email protected]> wrote: >> >> On 15/09/2020 14:02, Ard Biesheuvel wrote: >>> On Tue, 15 Sep 2020 at 15:59, Grant Likely <[email protected]> wrote: >>>> >>>> >>>> >>>> On 15/09/2020 13:35, Ard Biesheuvel wrote: >>>>> On Tue, 15 Sep 2020 at 15:34, Grant Likely <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 15/09/2020 13:25, Ard Biesheuvel wrote: >>>>>>> On Tue, 15 Sep 2020 at 15:22, Grant Likely <[email protected]> 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 <[email protected]> >>>>>>>>> --- >>>>>>>>> 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 <[email protected]> >>> 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? >> > > 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 mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
