1. Tech-Privileged
  2. Topics

Proposed deprecation of N extension

andrew@...
 

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 M and U privilege modes, with trusted code running in M, untrusted code in U, and interrupts directed to both levels.

This is an important use case to support.  But, we can get the same effect without the N extension: provide M+S+U privilege modes instead.  We'll use "bare S" mode: the satp CSR is hardwired to 0, so there's no MMU.  The trusted code will still run in M; the untrusted code will run in S; and possibly nothing at all will run in U.

The provision of an extra privilege mode might seem wasteful, but it really isn't: bare S-mode adds roughly the same amount of hardware as N.  And the bare-S approach is strongly preferable from the perspective of architectural economy: it's already spec'd and ratified.  Removing N also frees up some precious bits in mstatus (and, less importantly, some CSR addresses).

The other hypothetical use case of N is supporting horizontal user-level synchronous exceptions.  However, those use cases are quite a bit more speculative.  If, down the road, we find that user-level exceptions become important, we will probably want the opportunity to architect a new solution at that time.  It seems unlikely that we will have foreseen the exact use cases, and so N might actually prove to be an albatross around our necks.

So, there you have it: we propose deprecating N in favor of bare S-mode.

Andrew (on behalf of the IC chairs)
Gernot <gernot.heiser@...>
 

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

On 5 Jun 2021, at 08:32, Andrew Waterman <andrew@...> wrote:

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 M and U privilege modes, with trusted code running in M, untrusted code in U, and interrupts directed to both levels.

This is an important use case to support.  But, we can get the same effect without the N extension: provide M+S+U privilege modes instead.  We'll use "bare S" mode: the satp CSR is hardwired to 0, so there's no MMU.  The trusted code will still run in M; the untrusted code will run in S; and possibly nothing at all will run in U.

The provision of an extra privilege mode might seem wasteful, but it really isn't: bare S-mode adds roughly the same amount of hardware as N.  And the bare-S approach is strongly preferable from the perspective of architectural economy: it's already spec'd and ratified.  Removing N also frees up some precious bits in mstatus (and, less importantly, some CSR addresses).

The other hypothetical use case of N is supporting horizontal user-level synchronous exceptions.  However, those use cases are quite a bit more speculative.  If, down the road, we find that user-level exceptions become important, we will probably want the opportunity to architect a new solution at that time.  It seems unlikely that we will have foreseen the exact use cases, and so N might actually prove to be an albatross around our necks.

So, there you have it: we propose deprecating N in favor of bare S-mode.

Andrew (on behalf of the IC chairs)
andrew@...
 



On Fri, Jun 4, 2021 at 6:48 PM Gernot <gernot.heiser@...> 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.
 

Gernot

On 5 Jun 2021, at 08:32, Andrew Waterman <andrew@...> wrote:

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 M and U privilege modes, with trusted code running in M, untrusted code in U, and interrupts directed to both levels.

This is an important use case to support.  But, we can get the same effect without the N extension: provide M+S+U privilege modes instead.  We'll use "bare S" mode: the satp CSR is hardwired to 0, so there's no MMU.  The trusted code will still run in M; the untrusted code will run in S; and possibly nothing at all will run in U.

The provision of an extra privilege mode might seem wasteful, but it really isn't: bare S-mode adds roughly the same amount of hardware as N.  And the bare-S approach is strongly preferable from the perspective of architectural economy: it's already spec'd and ratified.  Removing N also frees up some precious bits in mstatus (and, less importantly, some CSR addresses).

The other hypothetical use case of N is supporting horizontal user-level synchronous exceptions.  However, those use cases are quite a bit more speculative.  If, down the road, we find that user-level exceptions become important, we will probably want the opportunity to architect a new solution at that time.  It seems unlikely that we will have foreseen the exact use cases, and so N might actually prove to be an albatross around our necks.

So, there you have it: we propose deprecating N in favor of bare S-mode.

Andrew (on behalf of the IC chairs)
andrew@...
 



On Fri, Jun 4, 2021 at 6:54 PM Andrew Waterman <andrew@...> wrote:


On Fri, Jun 4, 2021 at 6:48 PM Gernot <gernot.heiser@...> 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.

 

Gernot

On 5 Jun 2021, at 08:32, Andrew Waterman <andrew@...> wrote:

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 M and U privilege modes, with trusted code running in M, untrusted code in U, and interrupts directed to both levels.

This is an important use case to support.  But, we can get the same effect without the N extension: provide M+S+U privilege modes instead.  We'll use "bare S" mode: the satp CSR is hardwired to 0, so there's no MMU.  The trusted code will still run in M; the untrusted code will run in S; and possibly nothing at all will run in U.

The provision of an extra privilege mode might seem wasteful, but it really isn't: bare S-mode adds roughly the same amount of hardware as N.  And the bare-S approach is strongly preferable from the perspective of architectural economy: it's already spec'd and ratified.  Removing N also frees up some precious bits in mstatus (and, less importantly, some CSR addresses).

The other hypothetical use case of N is supporting horizontal user-level synchronous exceptions.  However, those use cases are quite a bit more speculative.  If, down the road, we find that user-level exceptions become important, we will probably want the opportunity to architect a new solution at that time.  It seems unlikely that we will have foreseen the exact use cases, and so N might actually prove to be an albatross around our necks.

So, there you have it: we propose deprecating N in favor of bare S-mode.

Andrew (on behalf of the IC chairs)
Gernot <gernot.heiser@...>
 

On 5 Jun 2021, at 12:00, Andrew Waterman <andrew@...> wrote:

On Fri, Jun 4, 2021 at 6:54 PM Andrew Waterman <andrew@...> wrote:


On Fri, Jun 4, 2021 at 6:48 PM Gernot <gernot.heiser@...> 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.)

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.

Gernot
andrew@...
 



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:


















On Fri, Jun 4, 2021 at 6:48 PM Gernot <gernot.heiser@...> 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.







Gernot
Gernot <gernot.heiser@...>
 

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:


















On Fri, Jun 4, 2021 at 6:48 PM Gernot <gernot.heiser@...> 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.







Gernot
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


On Fri, Jun 4, 2021 at 10:29 PM Gernot via lists.riscv.org <gernot.heiser=data61.csiro.au@...> wrote:
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:


















On Fri, Jun 4, 2021 at 6:48 PM Gernot <gernot.heiser@...> 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.







Gernot
Gernot <gernot.heiser@...>
 

On 5 Jun 2021, at 12:59, Jonathan Behrens <behrensj@...> wrote:

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.

VMs are more heavyweight than processes, and slipping a hypervisor underneath isn’t always a suitable approach. In terms of security, putting KVM underneath vastly *increases* the size of the trusted computing base.

Gernot
Zeyu Mi
 

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 case, as Gernot has already pointed out. If we pass through a device directly into a VM, the interactions (e.g., IPC) between the VM driver and other processes outside the VM have to involve costly VM exits.

Moreover, N extension promotes more architectural innovation. For example, Donky [1] leverages N extension to design a mechanism of in-process isolation, in order to address the security threat in Intel PKU that allows untrusted domains to maliciously change domain keys.

Actually, Intel has released their user interrupt extension [2], which is quite similar to RISC-V N extension. Interestingly, it provides an instruction called UIRET, just like URET.

[1] Donky: Domain Keys - Efficient In-Process Isolation for RISC-V and x86, USENIX Security 2020.

--
Zeyu Mi

On Jun 5, 2021, at 10:59 AM, Jonathan Behrens <behrensj@...> wrote:

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

On Fri, Jun 4, 2021 at 10:29 PM Gernot via lists.riscv.org <gernot.heiser=data61.csiro.au@...> wrote:
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:


















On Fri, Jun 4, 2021 at 6:48 PM Gernot <gernot.heiser@...> 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.







Gernot
Greg Favor
 

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 should be standardized and immortalized in concrete.  Some set of people that intend to put a new chunk of architecture into actual real-world industrial use, need to drive not just the development of an arch extension, but to put in place the toolchain and software support, help drive development of the architectural infrastructure for the extension (Spike/QEMU modeling and compliance tests), demonstrate through PoC's (Proof of Concept's) the correctness and completeness of the extension, and demonstrate that that is the right solution to the problem being addressed out of all the good ideas people put forth to address the problem.

It appears that no one has invested any effort for the past couple of years to create a complete and vetted N spec, let alone to do all the other things necessary to turn the idea into something ready to be standardized and ready to use in the real world.  Talking about and writing a spec is the easy part, then there is all the hard work to turn that idea into something usable in real products and to incorporate that into real products.  If there aren't people motivated to invest the time, effort, and money to make something real and to incorporate that into real products, then maybe the idea hasn't yet been deemed worthy of standardization and immortalization in the "marketplace" of ideas for real products.

And, to be clear, none of this stands in the way of defining and rallying a set of people around a custom extension for research, to prototype new ideas, and to foster further architectural innovation.  This, for example, could be a prime thing to pursue officially as a RISC-V SIG.  And if fruits of the SIG's efforts justify creation of a TG to do the work to turn something into a standard RISC-V arch extension, that can also happen.

Greg
Paolo Bonzini
 

On 05/06/21 08:15, Greg Favor wrote:
It appears that no one has invested any effort for the past couple of years to create a complete and vetted N spec,
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 full OS running in S-mode, and the current implementation where _all_ timer or external interrupts are delegated to the process doesn't quite work in that context. The N extension is worthwhile but it needs to be redesigned from scratch and based on the RISC-V AIA.

Paolo
mick@...
 

Στις 2021-06-05 05:29, Gernot έγραψε:

Hmm, I always thought RISC-V was trying to be a leader in security, not a follower
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 extension to delegate traps to U-mode apps through medeleg/sedeleg, can also be done in software (the same software that needs to set medeleg/sedeleg btw so we still rely on it). I don't see what's the difference in terms of security from e.g. delivering a signal to the app and calling its signal handler (I understand it from a performance point of view for some use cases). As for delegating external hw interrupts to U-mode through medeleg/sedeleg, that would only work if we don't have any memory protection mechanism in place (since M-mode/S-mode will be bypassed so it won't be possible to switch PMP rules / page table when we get an interrupt / do uret), not to mention any U-mode app can set utvec and take over the (global) interrupt handler. User I/O on Linux for example is a low-overhead software mechanism (https://www.kernel.org/doc/html/v4.14/driver-api/uio-howto.html) already used e.g. by DPDK or various user-space drivers, which makes much more sense than this.

So unless I'm missing something I don't see any security benefits from the current N extension, or how it gives RISC-V a security advantage. Intel's approach with user interrupts (an overly complicated mechanism IMHO) doesn't bypass memory protections, nor allows an app to take over. An interrupt is delivered directly to a user app, only if an MSR managed by the OS has the expected value (if not the interrupt is pending until the OS switches to that app). We can discuss about a similar mechanism on RISC-V, in fact we 've talked about this on TEE TG some time ago but it was before AIA started, and although we tried to find ways of using the N extension, we also reached to the conclusion that in its current state we can't do much with it. Also as Andrew said we don't gain much hw-wise either, one can just implement S-mode CSRs that are already ratified and have the same functionality. Let's drop it for now, define a threat model (that may for example also include delivery of interrupts to enclaves, something Intel doesn't support), and come back at it.

Regards,
Nick
Richard Bohn
 

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 machine state it should not have? 

A system where the state of the PMPs and page table provides limited access for the user mode handler and is thus able to enter without any additional setup in the common case. 

With the depreciation of N in order to prevent handler code from changing the satp to subvert any page table based restrictions on it we'd need to first enter supervisor mode then SRET to the real handler in user mode? This then does not take advantage of the speed improvements of the CLIC vectoring? Probably need to move some other relevant state from supervisor CSRs into somewhere the user handler could access, further slowing things down? 

From: tech-privileged@... <tech-privileged@...> on behalf of Andrew Waterman <andrew@...>
Sent: Friday, June 4, 2021, 5:33 PM
To: tech-privileged@...
Subject: [RISC-V] [tech-privileged] Proposed deprecation of N extension

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 M and U privilege modes, with trusted code running in M, untrusted code in U, and interrupts directed to both levels.

This is an important use case to support.  But, we can get the same effect without the N extension: provide M+S+U privilege modes instead.  We'll use "bare S" mode: the satp CSR is hardwired to 0, so there's no MMU.  The trusted code will still run in M; the untrusted code will run in S; and possibly nothing at all will run in U.

The provision of an extra privilege mode might seem wasteful, but it really isn't: bare S-mode adds roughly the same amount of hardware as N.  And the bare-S approach is strongly preferable from the perspective of architectural economy: it's already spec'd and ratified.  Removing N also frees up some precious bits in mstatus (and, less importantly, some CSR addresses).

The other hypothetical use case of N is supporting horizontal user-level synchronous exceptions.  However, those use cases are quite a bit more speculative.  If, down the road, we find that user-level exceptions become important, we will probably want the opportunity to architect a new solution at that time.  It seems unlikely that we will have foreseen the exact use cases, and so N might actually prove to be an albatross around our necks.

So, there you have it: we propose deprecating N in favor of bare S-mode.

Andrew (on behalf of the IC chairs)


Seagate Internal
Gernot <gernot.heiser@...>
 

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 everything at user level, including device drivers.

While most security-/safety-critical systems are built that way, it’s hard to get the model to perform. And capturing interrupts in the supervisor and then re-injecting them as a signal is a high-overhead solution, that can be completely avoided by delivering the interrupt directly to usermode code.

Gernot

On 6 Jun 2021, at 04:50, Nick Kossifidis <mick@...> wrote:

Στις 2021-06-05 05:29, Gernot έγραψε:

Hmm, I always thought RISC-V was trying to be a leader in security, not a follower
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 extension to delegate traps to U-mode apps through medeleg/sedeleg, can also be done in software (the same software that needs to set medeleg/sedeleg btw so we still rely on it). I don't see what's the difference in terms of security from e.g. delivering a signal to the app and calling its signal handler (I understand it from a performance point of view for some use cases). As for delegating external hw interrupts to U-mode through medeleg/sedeleg, that would only work if we don't have any memory protection mechanism in place (since M-mode/S-mode will be bypassed so it won't be possible to switch PMP rules / page table when we get an interrupt / do uret), not to mention any U-mode app can set utvec and take over the (global) interrupt handler. User I/O on Linux for example is a low-overhead software mechanism (https://www.kernel.org/doc/html/v4.14/driver-api/uio-howto.html) already used e.g. by DPDK or various user-space drivers, which makes much more sense than this.

So unless I'm missing something I don't see any security benefits from the current N extension, or how it gives RISC-V a security advantage. Intel's approach with user interrupts (an overly complicated mechanism IMHO) doesn't bypass memory protections, nor allows an app to take over. An interrupt is delivered directly to a user app, only if an MSR managed by the OS has the expected value (if not the interrupt is pending until the OS switches to that app). We can discuss about a similar mechanism on RISC-V, in fact we 've talked about this on TEE TG some time ago but it was before AIA started, and although we tried to find ways of using the N extension, we also reached to the conclusion that in its current state we can't do much with it. Also as Andrew said we don't gain much hw-wise either, one can just implement S-mode CSRs that are already ratified and have the same functionality. Let's drop it for now, define a threat model (that may for example also include delivery of interrupts to enclaves, something Intel doesn't support), and come back at it.

Regards,
Nick
洛佳 Luo Jia <me@...>
 

In our research N extension can speed up asynchronous operating system designs. It can run executor environments and tell them when the kernel need them to handle interrupts or raise signals. That may notes an important use scenario of a user level exception handling process. 

FYI our blog link (read with google translate): 执行器与生成语义 - 华中科技大学系统能力竞赛战队官方网站 (qf.rs)

1 - 16 of 16