1. Tech-Privileged
  2. Topics

[RISC-V] [tech-tee] [RISC-V] [tech-privileged] Proposed deprecation of N extension

Jonathan Behrens <behrensj@...>
 

Wouldn't you also want to isolate different interrupt handlers from each other and from any non-interrupt handler user code running on the system? With the N-extension itself none of that would be possible. In fact, I suspect that a lot of the performance that you might get out of the N-extension specifically comes from running all that code in the same privilege domain.

Jonathan

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






Gernot <gernot.heiser@...>
 

On 6 Jun 2021, at 12:22, Jonathan Behrens <behrensj@...> wrote:

Wouldn't you also want to isolate different interrupt handlers from each other and from any non-interrupt handler user code running on the system? With the N-extension itself none of that would be possible. In fact, I suspect that a lot of the performance that you might get out of the N-extension specifically comes from running all that code in the same privilege domain.

OK, if that’s the case then it is of pretty limited use indeed.

Gernot
Greg Favor
 

On Sat, Jun 5, 2021 at 7:36 PM Gernot <gernot.heiser@...> wrote:
On 6 Jun 2021, at 12:22, Jonathan Behrens <behrensj@...> wrote:
Wouldn't you also want to isolate different interrupt handlers from each other and from any non-interrupt handler user code running on the system? With the N-extension itself none of that would be possible. In fact, I suspect that a lot of the performance that you might get out of the N-extension specifically comes from running all that code in the same privilege domain.
OK, if that’s the case then it is of pretty limited use indeed.

Can I just observe and complain a little that Gernot has been arguing for the N extension - but apparently doesn't know squat about its details.  Questioning is fine, but the last thing we need are people strongly arguing for arch features without having an underlying reasonable technical basis or understanding. 

Ok, I'm done venting.  I've already wasted time on this. :)

Greg


 
David Horner
 

TLDR: just tunnel under the "wall of words" to the recommendation below.


This is hardly the hill for any of us to die on, especially by the hand of our fellow enthusiasts.

The fundamental issue [as I see it] is to remove the designation N from a long standing intended feature.


Andrew and others propose that the time has come to "depreciate" the allocation of this placeholder.

They acknowledge that RISCV.org has done little to develop the original concept under this "N" umbrella.

Further, alternatives to the original concept now appear to provide sufficient functionality to replace their original intent for "N".


Conversely, others had and continue to have high hopes for a feature or features under the "N" umbrella

that will fulfill what they understood/understand to be the most useful application:

hardware [or conceptual, expressive, software translatable] support for [microkernels, rapid I/O handling, platform hardening, etc.]


The fact that development under this "N' placeholder is stalled,
is as much a consequence of its promise as its humble [and spartan] beginnings and
our inadequacies to predictably and spontaneously innovate.


It was much hyped in its early and glory years.

But as it has many promises, the solution that can be developed in our current "extension" methodologies and infrastructure is limited.

We can do two things:

1) Andrew proposed moving out of our current process and abandon "N" as a placeholder.

      Use what we have as good enough and allow in ovation to occur outside RISCV.org where we will follow trends as they occur.

2) Relax our current process to be more inclusive. Allow tentative development under the RISCV umbrella without "strong governance" [ed. - this euphemism should suffice as a label] by which TGs and SIGs are encumbered. In this enhanced and receptive environment self-driven expression and contributions might be able to flourish and fulfill another vision of those who are enamored by what "N" promise to them and the world. 


Contrary to what Greg attests,

I believe all contributors on this list have a correct understanding of what "N" means, including an understand of the limitations of "the details" [certainly more than squat].

On this I fundamentally disagree:

"the last thing we need are people strongly arguing for arch features without having an underlying reasonable technical basis or understanding. "

We definitely need these people, on this list and throughout or organization.

We need visionaries.

Perhaps the need is lower down on the needed list than technophiles, and technologists.

My objection with Greg is not the problem that such people [as he described] present,

but rather the relative value of such persons.

We could argue that luddites are at the the bottom of the "needed list".

But my bottom rung choice is the intolerant; especially those in positions of influence and control


Recommendation:

Leave "N" as a placeholder for now.

Continue to pursue other alternatives than originally envisioned, and incorporate that discussion/discovery under this label.

We have observed great interest in advances in this domain [unlike the L and T placeholders].

Perhaps the "Depreciation" proposal and its discussion will stir up the technologists and RISCV regulators to innovate and make this approach fruitful.



On 2021-06-05 10:49 p.m., Greg Favor wrote:
On Sat, Jun 5, 2021 at 7:36 PM Gernot <gernot.heiser@...> wrote:
On 6 Jun 2021, at 12:22, Jonathan Behrens <behrensj@...> wrote:
Wouldn't you also want to isolate different interrupt handlers from each other and from any non-interrupt handler user code running on the system? With the N-extension itself none of that would be possible. In fact, I suspect that a lot of the performance that you might get out of the N-extension specifically comes from running all that code in the same privilege domain.
OK, if that’s the case then it is of pretty limited use indeed.

Can I just observe and complain a little that Gernot has been arguing for the N extension - but apparently doesn't know squat about its details.  Questioning is fine, but the last thing we need are people strongly arguing for arch features without having an underlying reasonable technical basis or understanding. 

Ok, I'm done venting.  I've already wasted time on this. :)

Greg


 
Greg Favor
 

On Sun, Jun 6, 2021 at 5:25 AM David Horner <ds2horner@...> wrote:

Contrary to what Greg attests, ...

First and foremost, I apologize to Gernot and to the list.  My little rant occurred in a heated moment of frustration with a few things (not related with Gernot or this topic).  It was quick venting to what was supposed to be one specific person, and was overly colorful (as such can be).  It was of only transient meaning from that moment and its context.

In contrast to what was said, I will assert a non-transient or lasting belief that RISC-V is a community that welcomes all.  Everyone comes with different background, different knowledge, and different perspective.  Which is a valuable thing for RISC-V.  And none of us is perfect.  Whether an unintended misstep in this case by me.  Or, more generally, a mistake, or an oversight, or a misunderstanding that occasionally occurs for all of us.  And we should be understanding of that, since together the "sum can be better than the parts".  And with that, I can also say not just for myself but for others of "influence", that there is a conscious view that the goal is not to exert undue influence, but to help guide and to help get all the other work done that getting an idea to a ratified extension entails.

So again, I sincerely apologize for what did not represent my actual views outside of the heat of a certain moment that was not actually centered around Gernot's comments.  Gernot, I look forward to your continued participation as part of this community.

Greg
Greg Favor
 

On Sun, Jun 6, 2021 at 5:25 AM David Horner <ds2horner@...> wrote:

We can do two things:

2) Relax our current process to be more inclusive. Allow tentative development under the RISCV umbrella without "strong governance" [ed. - this euphemism should suffice as a label] by which TGs and SIGs are encumbered. In this enhanced and receptive environment self-driven expression and contributions might be able to flourish and fulfill another vision of those who are enamored by what "N" promise to them and the world. 

... 

Continue to pursue other alternatives than originally envisioned, and incorporate that discussion/discovery under this label.

We have observed great interest in advances in this domain [unlike the L and T placeholders].

Perhaps the "Depreciation" proposal and its discussion will stir up the technologists and RISCV regulators to innovate and make this approach fruitful.


Another suggestion would be for an interested group of people to form an official SIG to pursue this area of ideas and innovation.  SIGs have more flexibility to explore an area of interest without the burdens of a TG.

Whether under the label of "N" or not is beside the point.  It should define its goals and what is/are the problem(s) it is going to tackle (and choose a SIG name).  With that, get approval for its creation by the TSC.  And then that group can work towards those goals as an organized official part of the RISC-V community.  Whether the end result, as an arch extension run through the whole TG process, gets put under the label of "N" or uses a different name is a tertiary issue for when that bridge is crossed.

Greg


 
Allen Baum
 

While I don't have a strong opinion on N-mode as such, I do worry a bit about being a follower, though not because being a follower is pejorative.
I'd be more concerned that just following may not be possible because of IP issues.

I'd also like to know the reason for the lack of progress on the spec; i
Is it a chicken;egg problem (we need an OS that can demonstrate the value), or
is it that no commerical company sees the value so no one is spending resources to worry about it?
(or is it someone does see the value, and their solution is proprietary...)

On Sun, Jun 6, 2021 at 5:25 AM David Horner <ds2horner@...> wrote:

TLDR: just tunnel under the "wall of words" to the recommendation below.


This is hardly the hill for any of us to die on, especially by the hand of our fellow enthusiasts.

The fundamental issue [as I see it] is to remove the designation N from a long standing intended feature.


Andrew and others propose that the time has come to "depreciate" the allocation of this placeholder.

They acknowledge that RISCV.org has done little to develop the original concept under this "N" umbrella.

Further, alternatives to the original concept now appear to provide sufficient functionality to replace their original intent for "N".


Conversely, others had and continue to have high hopes for a feature or features under the "N" umbrella

that will fulfill what they understood/understand to be the most useful application:

hardware [or conceptual, expressive, software translatable] support for [microkernels, rapid I/O handling, platform hardening, etc.]


The fact that development under this "N' placeholder is stalled,
is as much a consequence of its promise as its humble [and spartan] beginnings and
our inadequacies to predictably and spontaneously innovate.


It was much hyped in its early and glory years.

But as it has many promises, the solution that can be developed in our current "extension" methodologies and infrastructure is limited.

We can do two things:

1) Andrew proposed moving out of our current process and abandon "N" as a placeholder.

      Use what we have as good enough and allow in ovation to occur outside RISCV.org where we will follow trends as they occur.

2) Relax our current process to be more inclusive. Allow tentative development under the RISCV umbrella without "strong governance" [ed. - this euphemism should suffice as a label] by which TGs and SIGs are encumbered. In this enhanced and receptive environment self-driven expression and contributions might be able to flourish and fulfill another vision of those who are enamored by what "N" promise to them and the world. 


Contrary to what Greg attests,

I believe all contributors on this list have a correct understanding of what "N" means, including an understand of the limitations of "the details" [certainly more than squat].

On this I fundamentally disagree:

"the last thing we need are people strongly arguing for arch features without having an underlying reasonable technical basis or understanding. "

We definitely need these people, on this list and throughout or organization.

We need visionaries.

Perhaps the need is lower down on the needed list than technophiles, and technologists.

My objection with Greg is not the problem that such people [as he described] present,

but rather the relative value of such persons.

We could argue that luddites are at the the bottom of the "needed list".

But my bottom rung choice is the intolerant; especially those in positions of influence and control


Recommendation:

Leave "N" as a placeholder for now.

Continue to pursue other alternatives than originally envisioned, and incorporate that discussion/discovery under this label.

We have observed great interest in advances in this domain [unlike the L and T placeholders].

Perhaps the "Depreciation" proposal and its discussion will stir up the technologists and RISCV regulators to innovate and make this approach fruitful.



On 2021-06-05 10:49 p.m., Greg Favor wrote:
On Sat, Jun 5, 2021 at 7:36 PM Gernot <gernot.heiser@...> wrote:
On 6 Jun 2021, at 12:22, Jonathan Behrens <behrensj@...> wrote:
Wouldn't you also want to isolate different interrupt handlers from each other and from any non-interrupt handler user code running on the system? With the N-extension itself none of that would be possible. In fact, I suspect that a lot of the performance that you might get out of the N-extension specifically comes from running all that code in the same privilege domain.
OK, if that’s the case then it is of pretty limited use indeed.

Can I just observe and complain a little that Gernot has been arguing for the N extension - but apparently doesn't know squat about its details.  Questioning is fine, but the last thing we need are people strongly arguing for arch features without having an underlying reasonable technical basis or understanding. 

Ok, I'm done venting.  I've already wasted time on this. :)

Greg


 

1 - 7 of 7