Re: [RESEND PATCH v3 1/2] RISC-V: mm: Restrict address space for sv39,sv48,sv57

[Jessica Clarke <jrtc27@jrtc27.com>]

On 7 Jul 2023, at 00:56, Charlie Jenkins <charlie@rivosinc.com> wrote:
> 
> On Thu, Jul 06, 2023 at 11:11:37AM +0200, Alexandre Ghiti wrote:
>> Hi Charlie,
>> 
>> 
>> On 05/07/2023 20:59, Charlie Jenkins wrote:
>>> Make sv48 the default address space for mmap as some applications
>>> currently depend on this assumption. The RISC-V specification enforces
>>> that bits outside of the virtual address range are not used, so
>>> restricting the size of the default address space as such should be
>>> temporary.
>> 
>> 
>> What do you mean in the last sentence above?
>> 
> Applications like Java and Go broke when sv57 was implemented because
> they shove bits into the upper space of pointers. However riscv enforces
> that all of the upper bits in the virtual address are equal to the most 
> significant bit. "Temporary" may not have been the best word, but this change 
> would be irrelevant if application developers were following this rule, if I
> am understanding this requirement correctly. What this means to me is
> that riscv hardware is not guaranteed to not discard the bits in the virtual 
> address that are not used in paging.

RISC-V guarantees that it will not discard the bits*. Java and Go aren’t
actually dereferencing the pointers with their own metadata in the top
bits (doing so would require a pointer masking extension, like how Arm
has TBI), they’re just temporarily storing it there, assuming they’re
not significant bits, then masking out and re-canonicalising the
address prior to dereferencing. Which breaks, not because the hardware
is looking at the higher bits (otherwise you could never use Sv57 for
such applications even if you kept your addresses < 2^47), but because
the chosen addresses have those high bits as significant.

* A page fault is guaranteed if the address isn’t sign-extended

Jess