[RISC-V] [tech-tee] [RISC-V] [tech-privileged] Proposed deprecation of N extension
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
>
>
>
>
>
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.
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.
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.]
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 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
Contrary to what Greg attests, ...
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.
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