Introduce Physical Memory Protection Extension #37
Conversation
No, this is not provided in devicetree as of today. Linux today is hardcoded to ignore memory below 2MB (64-bit). With this new extension, U-Boot can query SBI firmware and insert a reserved memory node in the DT. |
|
If that’s true, it’s a regression. I can say so with certainty, because I
designed the first mechanism to communicate to the kernel what the SBI
exclusion was. The original mechanism was via the initial page tables. When
we got rid of initial page tables, we started using exclusions in the DT to
communicate the same thing.
Is it possible the DT you’re using is wrong?
IIRC, @terpstra worked on the DT exclusion stuff, so I hope he can comment.
Regardless, I think this API is too narrow. There’s no reason to believe
the SBI exclusion should be contiguous. That’s why we expressed it using
the existing standard mechanism in DT.
…On Fri, Mar 6, 2020 at 10:26 PM Bin Meng ***@***.***> wrote:
This information is already provided through other means (devicetree
something, I’m not sure exactly), or else conventional OS would not
function correctly.
No, this is not provided in devicetree as of today. Linux today is
hardcoded to ignore memory below 2MB (64-bit).
With this new extension, U-Boot can query SBI firmware and insert a
reserved memory node in the DT.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#37>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAH3XQRVW5AX7EPDVCB7TOTRGHSIPANCNFSM4LDM2XXQ>
.
|
I am using the same DT used by U-Boot/Linux (arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts in the kernel tree). There is only one memory node: And U-Boot does not fix up anything (because there is no way to know that currently) before loading the kernel.
I think we can add another function to query how many contiguous memory regions are protected, and pass region number to sbi_get_fw_prot_{base, size} functions? |
|
I don’t know why we would invent a new set of SBI calls to do what DT is
already quite capable of doing. The philosophy was that we would only add
SBI calls for runtime things, whereas we would use DT for anything that can
be communicated at boot time.
|
Of course, we can just manually add a reserved memory node in DT and pass that to kernel. But I don't think that's a clean way. Currently in my view how this extension should be used:
|
|
The device tree spec provides the "Reserved Memory Block" for exactly this purpose. In the binary representation (FDT) this block as actually separate from the tree part of the data structure, so it should be easy quite easy to add entries without needing code to manipulate the nodes of the tree. |
|
We have to use "reserved memory" device tree bindings for memory reservation. Please refer Linux device tree bindings documentation. Regards, |
|
@avpatel Could you link to the relevant documentation? I found this page which seems to be describing a way to use device tree nodes to reserve memory regions for special uses within the Linux kernel, but I didn't see anything about the "Memory Reservation Block" from section 5.3 of the devicetree spec which is meant to be used to protect boot program code/data. Does Linux ignore the Memory Reservation Block? If so, why? |
|
Here's the link to "reserved memory" device tree bindings documentation: Any OS kernel or Hypervisor can implement this bindings to reserve memory. OpenSBI can certainly update DTB as per "reserved memory" bindings and pass modified DTB to next stage (U-Boot or EDK2). If most people agree then we can go this route. Regards, |
|
Before "reserved memory" device tree bindings, there was "/memreserve/" device tree syntax used for memory reservation but it is not preferred anymore because other device DT nodes cannot refer reserved memory described using "/memreserve/" device tree syntax. Regards, |
|
I agree with DT node approach. There was a recent discussion about this on UEFI patches as well. I think OpenSBI should add this node so that U-Boot and Linux kernel doesn't accidentally stomp on that. |
Yes, that's my intention to propose this PMP extension. Please note U-Boot S-mode on FU540 does not use OpenSBI's FDT, instead it uses the kernel's FDT directly, that's why we need a way to query SBI firmware to provide such information, so that U-Boot (not OpenSBI in this case) can fix up the DT. |
Eventually the protected memory region information WILL be encoded in DT, and that's what I wanted as well. But we need a way to query that so that either OpenSBI or S-mode U-Boot can insert the node to the DT! I need to repeat again (below is my previous reply to Andrew, but it looks to me this was ignored). Currently in my view how this extension should be used:
|
|
That suggests to me that M-mode U-boot should add the exclusions to the DT
it passes to S-mode.
…On Sat, Mar 7, 2020 at 8:07 PM Bin Meng ***@***.***> wrote:
I agree with DT node approach. There was a recent discussion about this on
UEFI patches as well. I think OpenSBI should add this node so that U-Boot
and Linux kernel doesn't accidentally stomp on that.
I need to repeat again (below is my previous reply to Andrew, but it looks
to me this was ignored)
Currently in my view how this extension should be used:
- S-mode U-Boot queries M-mode SBI firmware to get such information,
and fix-up the DT by inserting reserved memory node before loading the
S-mode OS. S-mode OS does not need to do anything special to use this
extension unless it is not booted via a bootloader that already does such
job.
- In the OpenSBI case, OpenSBI can fix-up DT directly if DT is
available and pass the modified DT to its payload, e.g.: in the QEMU 'virt'
or 'sifive_u' case, booting Linux directly via "-bios default -kernel
Image".
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#37>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAH3XQRRJTXPHYLGQSKPY2DRGMKYLANCNFSM4LDM2XXQ>
.
|
There is no M-mode U-Boot on FU540 as of today. The mainline OpenSBI/U-Boot workflow is:
|
|
@aswaterman , the U-Boot SPL (M-mode) does not have all the information about amount of memory runtime firmware (i.e. OpenSBI) will use so runtime firmware should add its own reserved memory entries. I think @lbmeng has valid concern here because U-Boot can always override the DTB passed by runtime firmware (i.e. OpenSBI). I suggest that any booting stage (U-Boot SPL, OpenSBI or U-Boot S-mode) can update entries in reserved memory DT node but each stage should ensure that reserved entries done by previous booting stage preserved. To address @lbmeng concern, the U-Boot S-mode should parse and preserve contents of reserved memory DT node from DTB passed by OpenSBI. Now U-Boot S-mode can put back the reserved memory entries passed by previous booting stage (along with any additional reservation if any) in the DTB that is being passed to Linux kernel. Regards, |
|
I forgot to mention that in case of virtualization the SBI calls are provided by Hypervisor (Xvisor RISC-V or KVM RISC-V) and there is no M-mode runtime firmware. In this case, no memory reservation is done by Hypervisors. This means U-Boot S-mode running inside Guest/VM will get DTB (passed by Hypervisor) which does not have any reserved memory DT node. Regards, |
Correct. For U-Boot, the U-Boot SPL (M-mode) and U-Boot proper (S-mode) does not actually use the same DT, in fact SPL uses a much smaller DT, so fixing up the DT from SPL (M-mode) does not help here. The reason why U-Boot SPL was designed like this, is because SPL usually executes in a memory constrained environment and code footprint matters. Not to mention in some SPL implementation, FDT support might be completely missing (i.e.: CONFIG_OF_PLATDATA has to be used).
It looks complicated to do this way on FU540:
For QEMU 'virt' or 'sifive_u' machine, OpenSBI always have FDT available (QEMU built-in), but the workflow is almost similar as FU540. These seem to need quite amount of of work to do. If we could provide PMP extension, it would be much easier. |
|
Yes, indeed it will certainly turn-out to be very complicated for U-Boot considering OF_SEPERATE and OF_PRIOR. Thinking about this more even EDK2 can override the DTB passed by previous booting stage. Also, we are only discussing device tree here and not thinking about ACPI as well. If we take DT centric approach now then later things will be complicated for ACPI based systems. An SBI extension for listing memory regions will certainly simplify things for both U-Boot and EDK2. Any other use-case where this SBI extension can be useful ? Also, SBI calls proposed by this PR can be reduced to just two SBI calls:
Regards, |
|
To be clear, we will still need the DT reservation in runtime firmware (i.e. OpenSBI) so that we can support direct Linux booting as payload. Regards, |
Yes, agreed that we should not focus on DT only.
Yep, this is simpler, and reduces the number of SBI calls. If no one objects, I will update the proposal in the next version. |
Yes, definitely! |
|
While I am not opposed to the new SBI extension, I think this can be solved without it as well. Here is my current approach for U-Boot implementation.
AFAIK, EDK2 doesn't touch the FDT. So it has to rely on FDT modification provided by OpenSBI only. @lbmeng Can you send the SBI patch to the Unix platform working group mailing list so that we can continue the discussion there? We can weigh the pros and cons of both method and pick the best suitable one. |
|
I hope you are able to use @atishp04's PoC approach, rather than expanding the SBI interface for this one particular case. |
|
Like I mentioned previously, we can certainly get this working for DT because all booting stages use DT but if we start supporting ACPI in-future then DT only approach won't work. Because of this reason we have kept DT related code confined to platform code in OpenSBI. |
I have already pointed out this possible solution before, and this is way too complicated for U-Boot to handle. I am not in favor of this solution hence the proposal.
As @avpatel pointed out, we need also consider ACPI here.
Do you mean sending this SBI extension patch in this PR? Is the Unix platform working group mailing list this one: tech-unixplatformspec@lists.riscv.org ? Looks it is not a public mailing list. |
|
Yes, @lbmeng send the patch in PR to tech-unixplatformspec@lists.riscv.org mailing list. It is a public read-only mailing list. Only RISC-V foundation members can join and post on this mailing list. |
|
U-Boot will add equivalent reserved-memory entry to ACPI anyways. Whenever we have ACPI, we may still need to update the ACPI in OpenSBI (assuming we use OpenSBI for ACPI based platforms as well) for direct Linux boot. @lbmeng You need to be a member of RISC-V foundation. IIRC, individual membership is free. |
Email was sent to the Unix platform specification working group mailing list. I have a concern if such proposal needs to be discussed and approved on a members only mailing list, it seems to be against the openness of the RISC-V architecture. |
|
The discussions on the mailing list are public: |
|
@lbmeng SBI is a RISC-V specific standard. The process for SBI specification is same as any other RISC-V specification. Every specification in RISC-V is driven by a working group. Every working group follows the same principle i.e. all the discussions are available to public but voting rights are only reserved for members. |
The Linux EFISTUB reads the FDT from the EFI system configuration table. Before installing the FDT needs to be patched with the booting hartid, because the kernel in S-Mode cannot determine it. Signed-off-by: Daniel Schaefer <daniel.schaefer@hpe.com>
Actually we do touch the FDT in EDK2. Just like U-Boot we need to add the boot-hartid to start the EFISTUB kernel.
EDK2 is not a stage after OpenSBI. EDK2 is the first code to run, then calls sbi_init and uses OpenSBI as a library. We call sbi_init very early, so we'd prefer not to have OpenSBI modify the DT, but EDK2 be able to make the modifications in a later stage. Since the stages of EDK2 run first in M-Mode and then later in S-Mode, we don't directly need this extension or the proposed trap-n-emulate for PMP CSRs. |
|
Maybe I'm not getting something but what is the point of restricting mvendorid, marchid, mimpid and PMP CSRs to M-Mode if we provide an unfiltered way to access them from S-Mode? I guess PMP CSRs shouldn't be writable by S-Mode. But couldn't we make them read-write in M-Mode and readonly in S-Mode? Of course this would need modifications in the privileged spec. |
|
EDK2 has many memory types for the memory blocks maintained in its memory manager and also provides GetMemoryMap for ACPI-capable OS to get the memory region type and attributes before OS invokes ExitBootService. So for edk2+ACPI OS, we will provide enough information to the next UEFI-aware boot stage through boot service GetMemoryMap(). But we (RISC-V edk2 port) still can modify DT as Daniel said to add the reserver memory region if DT aware boot stage needs it. RISC-V edk2 port will have DT in EFI configuration table and EFI GetMemoryMap simultaneously for reporting memory information. If my understanding is correct, this proposal is to get PMP settings to know the reserved memory region, right? However, PMP is the memory region configuration and can not exactly reflect which memory region is reserved. A R/W-able memory region could be reserved for some reason. Maybe I get it wrong with the proposal been discussing here. |
There is a proposal in TEE TG(?) The sPMP, which Smode can have its own PMP set. These sPMP registers are definitely R/W-able. Not sure the latest proposal of sPMP though. |
|
@JohnAZoidberg wrote...
The SBI provider is allowed to lie. Most of the time it probably wouldn't, but there are cases like having code running inside a VM where it might be useful to lie about exactly what hardware is being used. |
As per my understanding, sPMP is in addition to existing PMP. sPMP allows S-mode to create physical address protection from U-Mode. |
@changab If I understand you correctly, EDK2 doesn't need any SBI call to update the ACPI tables. OpenSBI still need to modify the DT to allow direct booting of Linux without any real boot loader or firmware. It's up to the EDK2 to reuse the information updated by OpenSBI or just read the PMP config registers directly in M-mode and update the DT by itself.
I think "reserved" here means that any region that doesn't have R/W permission. It ensures that S-mode software do not try to read/write from that region. |
Right. We can report the initial EFI memory map according to PMP setting in the very early boot phase (M-Mode PEI phase) and do whatever we need before entering OS. However... I can't say EDK2 doesn't need SBI to read/write PMP. In our proposal of RISC-V edk2 port, we design the mechanism that allows load EFI SMode driver or EFI MMode driver in POST. We also defined the new EFI_MEMORY_TYPE for SMode accessible memory region and MMode accessible memory region for security reasons. This may requrie to manipulate PMPs in runtime during POST. We also evaluate the implementation of RISC-V version Management Mode, this may also need to update PMP in runtime. That would be good if OpenSBI provides the API for accessing PMPs, although we originally plan to have similar APIs in EFI_OPEN_SBI_PROTOCOL for EFI DXE phase driver.
Right. but it would be good if OpenSBI defines a standard process for updating DT either for boot hart or reserved memory region. Then firmware could have a standard to follow.
Ok. |
This calls fdt_reserved_memory_fixup() helper in the platform's
final_init() routine.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Series-version: 2
Series-prefix: RESEND
Cover-letter:
lib: Fix up device tree to insert a reserved memory node
Currently there is no way for S-mode payload to know the information
of the memory region used by OpenSBI firmware. The on-chip Physical
Memory Proction CSR has been programmed to protect this memory region
from buggy S-mode software. We have to find a way to tell such info
to S-mode software, and fortunately the device tree specification
in the Linux kernel [1] allows us to convey it via a reserved memory
node in the DT.
This adds a helper API to do the reserved memory node fix-up. Platform
codes are updated to call the helper in their final_init().
Tested on QEMU 'sifive_u' machine, booting to S-mode U-Boot, then print
the device tree from the shell:
=> fdt print
/ {
#address-cells = <0x00000002>;
#size-cells = <0x00000002>;
compatible = "sifive,hifive-unleashed-a00";
model = "SiFive HiFive Unleashed A00";
reserved-memory {
#address-cells = <0x00000002>;
#size-cells = <0x00000002>;
ranges;
opensbi@80000000 {
reg = <0x00000000 0x80000000 0x00000000 0x0001b000>;
no-map;
};
};
Tested on QEMU 'sifive_u' machine, booting to Linux kernel v5.5 directly.
Note there is still an on-going discussion [2] about whether we need
introduce a new SBI extension for converying such information directly
to S-mode payload.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
[2] riscv-non-isa/riscv-sbi-doc#37
END
S-mode can't manipulate PMP configuration. If EDK2 wants manipulate the PMP configuration in M-mode, you don't need SBI extension for that. I am okay with OpenSBI providing an API to read/write PMP configurations so that EDK2 can use it in M-mode. That is completely different from a SBI extension being discussed here. Let's continue the discussion in unix platform mailing list as more folks are watching that.
Yes. That's what we are trying to do it. As I said above, we can continue discussing the best approach to solve the problem in unix platform mailing list.
|
Most of EDK2 POST time is in SMode and it has to switch to Mmode for configuring PMPs. Thus I said above it would be good if OpenSBI could provide SBI if those SBIs are not just benefiting to edk2.
sure. |
|
Perhaps this should be a broader question about the scope of SBI, but shouldn't it only cover interfaces between the SBI provider and the operating system? I'd expect what happens before Linux starts to be irrelevant from the perspective of this standard. That would include ways to gather information to be included in the device tree, like this proposal to query reserved memory regions |
This calls fdt_reserved_memory_fixup() helper in the platform's
final_init() routine.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Series-version: 4
Cover-letter:
lib: Fix up device tree to insert a reserved memory node
Currently there is no way for S-mode payload to know the information
of the memory region used by OpenSBI firmware. The on-chip Physical
Memory Proction CSR has been programmed to protect this memory region
from buggy S-mode software. We have to find a way to tell such info
to S-mode software, and fortunately the device tree specification
in the Linux kernel [1] allows us to convey it via a reserved memory
node in the DT.
This adds several helper APIs to do various device tree fix-ups. This
includes a generic CPU node "status" property fix-up per hart status,
PLIC "interrupts-extended" fix-up, adding reserved memory node and a
general fdt_fixups() for convenience. Platform codes are updated to
call these helpers in their final_init().
Tested on QEMU 'sifive_u' machine, booting to S-mode U-Boot, then print
the device tree from the shell:
=> fdt print
/ {
#address-cells = <0x00000002>;
#size-cells = <0x00000002>;
compatible = "sifive,hifive-unleashed-a00";
model = "SiFive HiFive Unleashed A00";
reserved-memory {
#address-cells = <0x00000002>;
#size-cells = <0x00000002>;
ranges;
mmode_pmp0@80000000 {
reg = <0x00000000 0x80000000 0x00000000 0x00020000>;
no-map;
};
};
Tested on QEMU 'sifive_u' machine, booting to Linux kernel v5.5 directly.
Note there is still an on-going discussion [2] about whether we need
introduce a new SBI extension for converying such information directly
to S-mode payload.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
[2] riscv-non-isa/riscv-sbi-doc#37
END
Currently, there is no mechanism through which the SBI firmware can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that it will happen via the device-tree, a new set of SBI calls, or some combination of both. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. OpenSBI has begun specifying its section of memory under the "reserved-memory" device-tree property [2], which we can parse easily. If this property is present, we know exactly which region of physical memory the kernel should ignore. In the case that no "reserved-memory" property is found, exclude the lowest 2MB of memory from allocation. This isn't a perfect solution, but it is consistent with how the currently supported platforms are set up, allowing us to handle this case with BBL or the current release of OpenSBI. [1] riscv-non-isa/riscv-sbi-doc#37 [2] https://lists.infradead.org/pipermail/opensbi/2020-March/001544.html
Currently, there is no mechanism through which the SBI firmware can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that it will happen via the device-tree, a new set of SBI calls, or some combination of both. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. OpenSBI has begun specifying its section of memory under the "reserved-memory" device-tree property [2], which we can parse easily. If this property is present, we know exactly which region of physical memory the kernel should ignore. In the case that no "reserved-memory" property is found, exclude the lowest 2MB of memory from allocation. This isn't a perfect solution, but it is consistent with how the currently supported platforms are set up, allowing us to handle this case with BBL or the current release of OpenSBI. [1] riscv-non-isa/riscv-sbi-doc#37 [2] https://lists.infradead.org/pipermail/opensbi/2020-March/001544.html
Currently, there is no mechanism through which the SBI firmware can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that it will happen via the device-tree, a new set of SBI calls, or some combination of both. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. OpenSBI has begun specifying its section of memory under the "reserved-memory" device-tree property [2], which we can parse easily. If this property is present, we know exactly which region of physical memory the kernel should ignore. In the case that no "reserved-memory" property is found, exclude the lowest 2MB of memory from allocation. This isn't a perfect solution, but it is consistent with how the currently supported platforms are set up, allowing us to handle this case with BBL or the current release of OpenSBI. [1] riscv-non-isa/riscv-sbi-doc#37 [2] https://lists.infradead.org/pipermail/opensbi/2020-March/001544.html
Currently, there is no mechanism through which the SBI firmware can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that it will happen via the device-tree, a new set of SBI calls, or some combination of both. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. OpenSBI has begun specifying its section of memory under the "reserved-memory" device-tree property [2], which we can parse easily. If this property is present, we know exactly which region of physical memory the kernel should ignore. In the case that no "reserved-memory" property is found, exclude the lowest 2MB of memory from allocation. This isn't a perfect solution, but it is consistent with how the currently supported platforms are set up, allowing us to handle this case with BBL or the current release of OpenSBI. [1] riscv-non-isa/riscv-sbi-doc#37 [2] https://lists.infradead.org/pipermail/opensbi/2020-March/001544.html
Currently, there is no mechanism through which the SBI firmware can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that it will happen via the device-tree, a new set of SBI calls, or some combination of both. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. OpenSBI has begun specifying its section of memory under the "reserved-memory" device-tree property [2], which we can parse easily. If this property is present, we know exactly which region of physical memory the kernel should ignore. In the case that no "reserved-memory" property is found, exclude the lowest 2MB of memory from allocation. This isn't a perfect solution, but it is consistent with how the currently supported platforms are set up, allowing us to handle this case with BBL or the current release of OpenSBI. [1] riscv-non-isa/riscv-sbi-doc#37 [2] https://lists.infradead.org/pipermail/opensbi/2020-March/001544.html
Currently, there is no mechanism through which the SBI firmware can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that it will happen via the device-tree, a new set of SBI calls, or some combination of both. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. OpenSBI has begun specifying its section of memory under the "reserved-memory" device-tree property [2], which we can parse easily. If this property is present, we know exactly which region of physical memory the kernel should ignore. In the case that no "reserved-memory" property is found, exclude the lowest 2MB of memory from allocation. This isn't a perfect solution, but it is consistent with how the currently supported platforms are set up, allowing us to handle this case with BBL or the current release of OpenSBI. [1] riscv-non-isa/riscv-sbi-doc#37 [2] https://lists.infradead.org/pipermail/opensbi/2020-March/001544.html
The device tree may contain a "reserved-memory" node, whose purpose is to communicate sections of physical memory that should not be used for general allocations. Add the logic to parse and exclude these regions. The particular motivation for this is protection of the SBI runtime firmware. Currently, there is no mechanism through which the SBI can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that the path going forward will be to add an entry to the reserved-memory node. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. This will change in another commit, so as a safety measure, ensure that the lowest 2MB of memory is excluded if this region has not been reported. [1] riscv-non-isa/riscv-sbi-doc#37 Reviewed by: markj, nick (older version) Differential Revision: https://reviews.freebsd.org/D24155 git-svn-id: svn+ssh://svn.freebsd.org/base/head@360084 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
The device tree may contain a "reserved-memory" node, whose purpose is to communicate sections of physical memory that should not be used for general allocations. Add the logic to parse and exclude these regions. The particular motivation for this is protection of the SBI runtime firmware. Currently, there is no mechanism through which the SBI can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that the path going forward will be to add an entry to the reserved-memory node. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. This will change in another commit, so as a safety measure, ensure that the lowest 2MB of memory is excluded if this region has not been reported. [1] riscv-non-isa/riscv-sbi-doc#37 Reviewed by: markj, nick (older version) Differential Revision: https://reviews.freebsd.org/D24155
The device tree may contain a "reserved-memory" node, whose purpose is to communicate sections of physical memory that should not be used for general allocations. Add the logic to parse and exclude these regions. The particular motivation for this is protection of the SBI runtime firmware. Currently, there is no mechanism through which the SBI can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that the path going forward will be to add an entry to the reserved-memory node. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. This will change in another commit, so as a safety measure, ensure that the lowest 2MB of memory is excluded if this region has not been reported. [1] riscv-non-isa/riscv-sbi-doc#37 Reviewed by: markj, nick (older version) Differential Revision: https://reviews.freebsd.org/D24155
|
As the proposed features are implemented via DT, we can close this PR. |
The device tree may contain a "reserved-memory" node, whose purpose is to communicate sections of physical memory that should not be used for general allocations. Add the logic to parse and exclude these regions. The particular motivation for this is protection of the SBI runtime firmware. Currently, there is no mechanism through which the SBI can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that the path going forward will be to add an entry to the reserved-memory node. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. This will change in another commit, so as a safety measure, ensure that the lowest 2MB of memory is excluded if this region has not been reported. [1] riscv-non-isa/riscv-sbi-doc#37 Reviewed by: markj, nick (older version) Differential Revision: https://reviews.freebsd.org/D24155
The device tree may contain a "reserved-memory" node, whose purpose is to communicate sections of physical memory that should not be used for general allocations. Add the logic to parse and exclude these regions. The particular motivation for this is protection of the SBI runtime firmware. Currently, there is no mechanism through which the SBI can communicate the details of its reserved memory region(s) to a supervisor payload. There has been some discussion recently on how this can be achieved [1], and it seems that the path going forward will be to add an entry to the reserved-memory node. This hasn't caused any issues for us yet, since we exclude all physical memory below the kernel's load address from being allocated, and on all currently supported platforms this covers the SBI firmware region. This will change in another commit, so as a safety measure, ensure that the lowest 2MB of memory is excluded if this region has not been reported. [1] riscv-non-isa/riscv-sbi-doc#37 Reviewed by: markj, nick (older version) Differential Revision: https://reviews.freebsd.org/D24155 git-svn-id: svn+ssh://svn.freebsd.org/base/head@360084 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
S-mode software needs a way to know memory used by SBI firmware so
that it can correctly mark such memory as reserved.
Related discussion:
riscv-software-src/opensbi#103
Signed-off-by: Bin Meng bmeng.cn@gmail.com