1. Messages
  2. RISC-V Vector Extension post-public review updates - fault flagging

Re: RISC-V Vector Extension post-public review updates - fault flagging

Jonathan Behrens <behrensj@...>
 



On Wed, Nov 17, 2021 at 8:24 PM Andrew Waterman via lists.riscv.org <andrew=sifive.com@...> wrote:


On Wed, Nov 17, 2021 at 4:19 PM Jonathan Behrens <behrensj@...> wrote:
The security concern was being able to probe addresses to find accessible regions without free of being killed on touching a prohibited region.  It was noted that this is still present even for unit-stride in supervisor mode when using translation to arbitrarily probe supervisor physical space. However, I believe these security concerns are manageable through control mechanisms at higher privilege levels

Could someone say what these control mechanisms are? In particular, it seems like a VS-mode guest operating system could probe the entire guest physical address space using fault-on-first load without triggering any intervention from HS-mode or M-mode.

Perhaps I'm being obtuse, but I'm having trouble understanding why this specific case is a concern: it's within VS-mode's purview to know anything and everything about the guest physical address space.  (The situation is materially different than S vs. U, because those two share a VA space, whereas VS' GPA space is disjoint from HS' VA space.)

The physical address space that the hypervisor tells the guest about may not match the one installed in hgatp. For instance, some pages of the guest's memory might be marked copy-on-write or swapped out to disk. Or a particular device may supposedly be mapped into the guest VM, but actually just be an unmapped region so the host can trap-and-emulate any accesses to it. Even today it is possible for a guest VM to indirectly learn that these things might be happening, but directly being able to check whether a page is mapped adds a new level.
Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.