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.

It could depending upon what implementation details are designed into the hart.

Control Mechanisms:

If the first address of the vector load is problematic, whether first fault or not, the instruction will trap.

So, only in the case that an instruction starts on a valid address and reads past the end of that valid range might the instruction not fault.

The hart is allowed to fault even then.

A count of fault-first events could trigger a trap, thus any misbehaving applications could thus be identified and managed.

This appears to be distinctly different from the SVE design.

Jonathan

On Wed, Nov 17, 2021 at 6:39 PM David Horner via lists.riscv.org <ds2horner=gmail.com@...> wrote:

On 2021-11-17 5:36 p.m., Krste Asanovic wrote:

The primary reason was lack of encoding space for non-unit-stride fault-on-first instructions.

However, we did discuss its merit; if it would trump the encoding dificulties, see below -

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.

Krste

On Nov 17, 2021, at 2:21 PM, Bruce Hoult <bruce@...> wrote:

On Thu, Nov 18, 2021 at 10:33 AM Bill Huffman <huffman@...> wrote:

 

 

From: Bruce Hoult <bruce@...>
Sent: Wednesday, November 17, 2021 4:24 PM
To: Krste Asanovic <krste@...>
Cc: Bill Huffman <huffman@...>; Grigorios Magklis <grigorios.magklis@...>; tech-vector-ext@...
Subject: Re: [RISC-V] [tech-vector-ext] RISC-V Vector Extension post-public review updates

 

EXTERNAL MAIL

Don't forget some code may want to use a mask in inverted sense for individual instructions, without explicitly creating a new mask. This was not listed in the "wish list for 64 bits" below, but it was in early RVV drafts.

 

Yes, that needs to be considered as well.

 

I'm not sure how common that really is, and non-store uses can usually just use a vmerge.vmm at the end anyway, at the expense of possibly using extra registers.

 

While on the subject of future features, and somewhat related ... the one big thing I've noticed RVV lacking that SVE has is a non-faulting version of indexed loads ("gather") which creates a mask showing which elements were accessible. In SVE this goes into a CSR which can then be moved into a mask register, but of course with sufficient encoding bits you could directly put it into a normal register.

 

Traditional vector code doesn't really need this, but SVE has an aim to be able to vectorise all loops.

 

How does this contribute to vectorizing all loops?

Because otherwise you can't safely vectorise loops that do indirect array accesses (e.g. a[b[i]]) with data-dependent control flow.

there are two aspects here -

a) checking array indexes are within bounds, which absent proof that the indexes are always in bound should be checked.

    We have a viable mechanism for that. The index values are loaded into a vector register in any event.

    Set a mask on the compare of the index values with a scalar bound.

b) handle a fault exceptions expeditiously by returning a mask of would be faults.

    This should be the exception case and therefore does not need expediting.

    As Krste says the OS level can provide a cooperative mechanism to set a corresponding mask when exceptions occur, if it is deemed the application [or system code] needs it.

   But this feature does not mitigate the out of bound array fetch. Many out of bounds locations can be in accessible memory.

Thus  no need for instructions to have this feature whether supporting all loop constructs or not.

 I think this was not included for security reasons rather than ignored.

I don't think there is any additional security implication.

I could be wrong, as I'm not an expert on SVE, but I believe that even if the gather operation is done (somewhat) in parallel or in random order, the instruction doesn't actually return a mask indicating all the failed accesses. All mask bits after the first element that was inaccessible are also set to false. The following code will process all the initial elements and then invert the mask and loop back and try to process the tail starting from the first inaccessible element, which will then actually fault if the loop didn't exit or skip that element based on program logic.