Could you clarify what suggestions you think we should implement? The KAISER paper describes a way of mitigating side channel attacks, but do you have specific lessons you think we should learn from

this is a good start imho, perhaps not not for sv57, but for sv64, we incorporate some of the suggestions of the KASLR people. there are linux versions that implement their suggestions. perhaps

It hasn’t been standardized yet, but there is a placeholder for the Sv57 encoding in the satp.MODE register field. There isn’t a chapter on the Sv57 spec, but it will follow the pattern of Sv39 ->

is this documented? much appreciated WARNING / LEGAL TEXT: This message is intended only for the use of theindividual or entity to which it is addressed and may containinformation which is privileged,

The basic design is already laid out for expansion to Sv57 and Sv64 following the template of fewer bits, Krste

the current size of the virtual address space is 48 bits. (per the june 2019 spec - volume II) as many of you know, INTEL has increased their address space to 57 bits. several designers of server

The actual PTE access is either a page-table data read or page-tabledata write (which gets checked against PMAs and PMPs as such). But the "original access type" refers to the access that is being

From the Privileged spec, the 2nd step of virtual Address Translation process said, [2. Let pte be the value of the PTE at address a+va.vpn[i]×PTESIZE. (For Sv32, PTESIZE=4.) If accessing pte

The sPMP proposal has not been discussed in any detail as far as I know, so it is hard to pin down. The advantage of sPMP is that it should be much lower cost and simpler compared to page-based

This is just a quick FYI. (Sorry if this is a bit spam'y; there isn't a clear TG to target with this email. And I don't expect that this is something that plays into any near-term RISC-V

Is sPMP an alternative to page-based permissions? If so, what advantage does it provide over the latter? Thanks, Freddie

I'd tend to think that the user processes running under sPMP will have few enough data regions that software base-and-bounds checks on syscall arguments isn't prohibitively expensive.

That might mean that the sPMP being considered might need a probe of some sort. Bill On 10/30/20 3:39 PM, Jonathan Behrens wrote:

On 10/30/20 3:25 PM, Andrew Waterman wrote: Yes, I overstated a bit. But embedded address maps vary quite a bit more than Linux address maps. I have wondered whether we'd want a state bit, maybe in

In the worst case, a software page table walk isn't that expensive.

It's not especially Linux-centric; it's more conventional-OS-with-paging-centric. mstatus.MPRV handles the situation adequately for PMP-based protection in M/U systems. S-mode with general address

On 10/30/20 2:32 PM, Andrew Waterman wrote: That's, of course, a very Linux centric answer. With more general address maps - or a "bare MMU" - the problem is harder to solve. Do you have an

My experience has been that, in the grand scheme of the cost of the syscall, the sstatus writes don't have a major effect on performance. (Also, many syscalls don't need to access user memory, since

Right. SUM can be used to solve the same problem as LDTR/STTR, but it is not equivalent. To avoid the concern you describe, the Linux kernel first performs a bounds check to guarantee the address is

Hi Andrew, I’m not sure the sstatus.SUM bit is providing the equivalent of LDTR/STTR. The pair of load/store instructions lower their privilege level so that if they end up access privileged