toggle quoted messageShow quoted text
The trap if first address bad is stipulated behaviour.
The other are not specified in the vector extension , but
1. the counter is part of the generalized performance spec.
2. Always trap but allow resume is an implementation option.
3. Dynamically limit vl=1 is a hypothetical extension that could have a csr to manage.
Obviously these could be defined as part of the privilege spec and the VM guys probably want to nail them down exactly.
I prefer minimalistic S and M support with least specs to allow implementations latitude.
On Wed., Nov. 17, 2021, 21:33 Jonathan Behrens, <behrensj@...
Are the mechanisms you mentioned hypothetical future ISA extensions, or something included in the current vector extension? In particular, I don't see anything about M-mode and/or HS-mode requesting a trap if too many non-faulting fault-first-load instructions are executed which modify vl.
On Wed, Nov 17, 2021 at 9:19 PM David Horner <ds2horner@...
that should have been "The HS is in control, it can
"leak" or not as it sees fit" obviously.
On 2021-11-17 8:45 p.m., Andrew
On Wed, Nov 17, 2021 at
5:41 PM Jonathan Behrens <behrensj@...
On Wed, Nov
17, 2021 at 4:19 PM Jonathan Behrens <behrensj@...
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
Yeah, agreed that detecting paged-out pages is a
similar information leak.
The VS having this awareness can be very beneficial.
It allows the OS to better manage its resources. It can switch
to handling other supervisory actions while that data is
Never the less, the control mechanisms I previously mentioned
apply here as well.
The HS is in control, it can "leak" or not as it sees
(Though I think COW is not relevant here, since we're
only talking about load instructions.)