Jonathan Behrens <behrensj@...>
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 CSRs of which 8 are analogous, 2 more are just to control the N-extension, one other is satp (would just be hardwired), and the last is scounteren (which could just be hardwired as well).
To the point about Linux letting processes handle interrupts themselves, this is actually already possible today... using KVM. If you create a virtual machine, then you can setup passthrough so that a hardware device and the associated interrupts are handled within it. In fact, if you go through the same exercise of comparing CSRs that I did above, you'll see that a M/S/U + N system is actually very similar to a M/HS/VS/U system with vsatp hardwired to zero.
Jonathan
Hmm, I always thought RISC-V was trying to be a leader in security, not a follower
Gernot
On 5 Jun 2021, at 12:21, Andrew Waterman < andrew@...> wrote:
On Fri, Jun 4, 2021 at 7:12 PM Heiser, Gernot (Data61, Eveleigh) < Gernot.Heiser@...> wrote:
On 5 Jun 2021, at 12:00, Andrew Waterman < andrew@...> wrote:
On Fri, Jun 4, 2021 at 6:54 PM Andrew Waterman < andrew@...> wrote:
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. It’s what microkernels
do, and even Linux is
moving more drivers out of the kernel.
This see this as a step backward, unless the same functionality is available in another way.
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 relies only on
already-ratified specifications.
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 user-mode interrupts is not in our bailiwick. If e.g. Arm and
Intel drive that effort on the Linux side, then we should revisit this topic.
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 security. You want drivers in U mode. (Yes, fundamentally changing Linux design isn’t going to happen any time soon, but
that’s not the point here. Even Linux has usermode drivers, although they are still in the minority.)
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 practice.
The question is whether RISC-V is taking suppoort for secure sysems seriously. I remember being really excited when I first saw the N extension, thinking finally someone is doing the right thing.
|
