4 ms·

You can find your answers in the Privileged ISA spec (http://riscv.org/download.html#tab_spec_privileged_isa http://riscv.org/download.html#tab_spec_privileged_

by _chris_ 11y ago

You can find your answers in the Privileged ISA spec (http://riscv.org/download.html#tab_spec_privileged_isa http://riscv.org/download.html#tab_spec_privileged_isa). Of course, it's an open ISA, so you can do whatever you want. The style of virtual memory you choose to use will depend on the target application.

milspec 11y ago
Thanks. The following concerns paging, not the base/limit system: From a security and reliability perspective, I'm saddened to see that rwx got supported while --x did not get supported. That is backwards. Having to change permissions after code modification is not bad; this provides a convenient point for cache flushing and ASLR-enforced address changes. Preventing executable code from being misused as data is valuable. I'm also saddened to see that user access implies supervisor access. This too is exactly backwards; nothing should be both user and supervisor accessible. Given that data access can be performed at a less-privileged level by setting MPRV=1, the ability of the supervisor to access user pages normally is especially strange. Lack of distinct did-execute and did-read bits is mildly annoying. If a page is marked as being accessed and executable, one must assume that it is now in BOTH the instruction cache and the data cache. I have mixed feelings about having page frame numbers shifted over by two bits. The win is Sv32 getting a reach of 16 GiB. I suppose this is worth the minor annoyance when debugging OS kernel code. Other than that, I like it. It's certainly sane. The traditional page table is pretty good for the middle bits of the virtual address. I think it is less good for the upper bits due to ASLR, and I hate to see anything that encourages a failure to use all 64 bits of the virtual address space.
- _chris_ 11y ago
  You should read through the RISCV mailing list archives (https://lists.riscv.org/lists/ https://lists.riscv.org/lists/) for discussions on these topics, and contribute your own thoughts if they haven't been covered. The ISA-dev list should be the most relevant. They have thought very carefully about these things and I'm sure they'd appreciate additional feedback on the topic.
milspec 11y ago
Oh, one other problem. The referenced (R) and dirty (D) bits are only updated in leaf nodes. I strongly suspect that any performance you gain here will be more than consumed by OS software needing to scan all the leaf nodes for these bits. If you update non-leaf nodes, then the OS can use those to avoid checking many of the leaf nodes.

by _chris_ 11y ago

milspec 11y ago

Thanks. The following concerns paging, not the base/limit system: From a security and reliability perspective, I'm saddened to see that rwx got supported while --x did not get supported. That is backwards. Having to change permissions after code modification is not bad; this provides a convenient point for cache flushing and ASLR-enforced address changes. Preventing executable code from being misused as data is valuable. I'm also saddened to see that user access implies supervisor access. This too is exactly backwards; nothing should be both user and supervisor accessible. Given that data access can be performed at a less-privileged level by setting MPRV=1, the ability of the supervisor to access user pages normally is especially strange. Lack of distinct did-execute and did-read bits is mildly annoying. If a page is marked as being accessed and executable, one must assume that it is now in BOTH the instruction cache and the data cache. I have mixed feelings about having page frame numbers shifted over by two bits. The win is Sv32 getting a reach of 16 GiB. I suppose this is worth the minor annoyance when debugging OS kernel code. Other than that, I like it. It's certainly sane. The traditional page table is pretty good for the middle bits of the virtual address. I think it is less good for the upper bits due to ASLR, and I hate to see anything that encourages a failure to use all 64 bits of the virtual address space.

_chris_ 11y ago
You should read through the RISCV mailing list archives (https://lists.riscv.org/lists/ https://lists.riscv.org/lists/) for discussions on these topics, and contribute your own thoughts if they haven't been covered. The ISA-dev list should be the most relevant. They have thought very carefully about these things and I'm sure they'd appreciate additional feedback on the topic.

milspec 11y ago

Oh, one other problem. The referenced (R) and dirty (D) bits are only updated in leaf nodes. I strongly suspect that any performance you gain here will be more than consumed by OS software needing to scan all the leaf nodes for these bits. If you update non-leaf nodes, then the OS can use those to avoid checking many of the leaf nodes.