The thread model is any attacks on buggy software, and the defence has been known for 45 years: Satzer & Schroder’s Principle of Least Privilege. This means a highly modularised system with almost

Is there a solution for an M+S+U (non bare S) implementation which contains a CLIC and desires high performance entry into the handler code while also limiting the handlers ability to access memory or

Στις 2021-06-05 05:29, Gernot έγραψε: If we treat N extension as a security-related mechanism, the threat model it tries to address is not clear. Anything that can be done with the N

Thank you for the clarification. I can see now that it doesn't particularly matter which legal encoding is generated when writing the reserved value since it would be the responsibility of the

I agree with Greg on this. There are two uses of U-mode interrupts, one is M+U microcontrollers and that one is served quite well by bare S-mode. The other is user-mode device drivers underneath a

I'll offer a rather contentious view. RISC-V can be a great vehicle for research and for pushing the frontiers of hardware/software/system/security design. That doesn't mean that such great ideas

The N extension benefits important use cases in high-end machines and devices, which cannot be simply achieved by M+S+U privilege modes. Implementing efficient device drivers as user processes is one

On 5 Jun 2021, at 12:59, Jonathan Behrens <behrensj@...> wrote: VMs are more heavyweight than processes, and slipping a hypervisor underneath isn’t always a suitable approach. In terms of security,

Agreed with Andrew that the N-extension isn't useful for M/U systems because it is equivalent to adding S-mode with satp hardwired to zero. The N-extension adds 8 CSRs while S-mode has a total of 12

Hmm, I always thought RISC-V was trying to be a leader in security, not a follower Gernot

I actually do agree with you on the technical merits, but I strongly feel this is _not_ an area in which we should be innovating. We can follow suit quickly if this is actually the way things go in

On 5 Jun 2021, at 12:00, Andrew Waterman <andrew@...> wrote: Hi Andrew, The way I read your original email is that you assume the drivers are in S mode. This is exactly *not* the right design for

And, if this is the direction that conventional OSes are moving towards, then RISC-V can follow suit once other architectures are on board with the idea. Substantially changing Linux to support

Gernot, if you read my email all the way through, you'll see that I explained my agreement with your concern; expressed that N is _not_ the only right design; and described a same-cost solution that

My is that N mode is exactly what you want for low-overhead usermode device drivers. This is the (only) right design if you care about security and thus want to minimise the trusted computing base.

Hi, We are proposing to remove the N extension from the architecture. The most important role the N extension fills is supporting untrusted interrupt handling in microcontrollers. These systems have

This is indeed a pretty vague statement, but Spike certainly isn't violating it. (I also know that several HW implementations do exactly what Spike is doing here.) A more precise statement would be

I would like to clarify the intended behavior of PMP regions when R=0, W=1. The privileged spec

I wrote: Bill Huffman: The RISC-V ISA frequently makes general rules that are qualified with "unless specified otherwise". The argument here is not in favor of state being modified when a write to a