please read the attached. i look forward to any and all comments

On 10/19/21 9:44 AM, swallach wrote:

please read the attached. i look forward to any and all comments

Few comments:

As noted the convention in most operating systems is to map supervisor only memory in the negative address space where most significant bit of the address is 1 and user memory in positive address space.

There are couple of techniques (just to list a few) to worry about here:
1. First make a system call to the kernel causing the kernel to populate an entry in the TLB. Now from user space make a speculative access to the kernel address space and determine if the access was fast (it hit in the TLB) or was slow (caused a page walk).
2. Make a first speculative access to a kernel address to possibly prime the TLB and then make a second speculative access to the kernel address and time the access.
3. Register a signal handler to be invoked on page faults. Access kernel memory (not speculatively) and time the page fault delivery i.e. signal handler being invoked. The timing can expose if the faults occurred from the TLB or from which level of the page table.

The proposal states:
"The higher order bit, bit 63 is used to select which SATP to use for address translation"
I am referring to this - hope this is latest - https://lists.riscv.org/g/software/topic/risc_v_tech_virt_mem/80324548?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,20,80324548

In the proposed scheme, all of above methods will work since the SATPU and SATPK are both resident in hardware and the scheme does not prevent selection of either based on the UK bit.

This is unlike Kaiser where the page table when executing in user mode only has mapping for user addresses and some mappings for a trampoline - like the system call call handler and trap handler. So any probing of the kernel address space is prevented. However, if the hardware just selects between SATPU and SATPK the probing is not prevent.

Bugs like meltdown and L1TF are more fundamentally flaws in the implementation and an implementation that does safe speculation should not be affected by them. Newer processors from vendors originally affected by these bugs seems to deal with meltdown and L1TF through such safe speculations techniques. If an implementation did have such a flaw, it does not seem to be addressed by this proposal as the UK bit just leads to selection of the SATPU or SATPK but does not prevent it.

The proposal to widen the address seems somewhat orthogonal based on my reading. However one of the benefits claimed is "upon the process switching, if one chooses, only the user virtual addresses are purged within the TLB". Would this not be also accomplished by the kernel when it sets the G bit to 1 making translations global across ASID and thus not needing to be flushed?

-ved

first of all, thank you for your time in sharing your thoughts

attached is a proposal i previously made. and at convey computers we implement this. many of the structures described are consistent with yours

the higher order bit was either user or kernel.

the TLB, as you suggested, ion fact has user/kernel partitions. so when there was a new user, only the user portion, need be purges.

and we took this one step further. we implemented a 32 bit ASID. so TLB purges only occurred when a ASID had to be reused. and this was rare.

and finally we had wto page table base registers. one for the user and one for the kernel

Just to point out and avoid a potential source of confusion - For the longest time, the scalar cryptography extensions were referred to collectively as "the K extension", but more accurately is now referred to by the collection of "Zk*" extensions it has been broken into.

This has nothing to do with the Sv57K or "the k extension" mentioned in the previous email. I'm not sure how this overloading came about and it needn't be a problem going forward, I just figured I'd point it out now!

Cheers,
Ben



it is under review.  BUT without the K extension

On Oct 19, 2021, at 10:43 AM, Paul Donahue <pdonahue@...> wrote:



Isn't Sv57 currently under public review?

https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/1bTAL-PJGYQ

Thanks,

-Paul

On Tue, Oct 19, 2021 at 7:44 AM swallach <steven.wallach@...> wrote:

please read the attached. i look forward to any and all comments

-- 
Ben Marshall
Senior Research Associate
University of Bristol
Cryptography Research Group
Dept. Computer Science