search

riscv-non-isa / riscv-sbi-doc

Documentation for the RISC-V Supervisor Binary Interface
https://jira.riscv.org/browse/RVG-49
Creative Commons Attribution 4.0 International
340 stars 89 forks source link

Add SBI call to disable SBI #102

Open rminnich opened 2 years ago

rminnich commented 2 years ago

At the recent OSFC, the idea was raised that we'd like to have an SBI call to turn off SBI, for working with new implementations that can work without SBI being there.

We would like to add a call that permanently disables SBI. This should be pretty simple.

neuschaefer commented 2 years ago

Some additional thoughts (which may or may not translate into considerations for the specification):

  1. To disable all "runtime services", such a call would also disable timer/external interrupts previously handled in M-mode (or redirect them into H/S mode). Such interrupt handlers can interfere with OS control of the same hardware, so it may be useful to have a guarantee that they are now inactive.
  2. After SBI calls are disabled, there is no need to even have stub that returns SBI_ERR_NOT_SUPPORTED: The OS knows that it requested the SBI to be disabled, it can refrain from making any more SBI calls. Thus, ECALL might be redirected to H/S-mode as well.
  3. Finally, when there is no active entry point into M-mode code anymore, the code can be nulled out, and perhaps even returned to the lower privilege levels for their use (althought making previously reserved memory unreserved may involve some complications that may be beyond the scope of this extension).
atishp04 commented 2 years ago

Can you please provide more details about the usecase for such a call ?

  1. Do you expect to disable SBI after the boot ?
  2. Who will provide the run time services (e.g CPU hotplug, System reset. hart suspend)once it is disabled ?
neuschaefer commented 2 years ago

Can you please provide more details about the usecase for such a call ?

My speculated usecase is perhaps not so much of a usecase, but more an assurance of simplicity: When this call returns successfully the SBI implementation should guarantee that no more M-mode code will run, and thus system state may become easier to reason about. This may be useful in some safety/realtime/security anlysis contexts.

1. Do you expect to disable SBI after the boot ?

"After the boot" is a bit ambiguous, as a boot process tends to proceed in multiple stages: Bootloader, SBI implementation, OS kernel, OS userspace, ...

I expect the call at some point during OS runtime (if at all). When exactly this call shall happen is the OS's choice (and I don't see why the SBI specification should care, although I may be missing something), but it probably makes sense during OS boot.

2. Who will provide the run time services (e.g CPU hotplug, System reset. hart suspend)once it is disabled ?

OS drivers.

Of course this can't work on every hardware platform, but in such cases when the OS can provide all hardware support, it could tell the SBI implementation to get out of the way.

rminnich commented 2 years ago

SBI at this point is system management mode (SMM). There are a number of very successful attacks on SMM based on TOCTOU and SCA approaches, some just this year. Looking at the current SBI standard, there is certainly cause for concern that similar attacks might succeed as well. I suspect that SBI, if not a target today, will be one tomorrow.

In the x86 world, we are doing our best to eliminate SMM, for security reasons at least, so its reappearance and explosive growth in RISC-V is a cause for concern. When I wrote the first SBI support in coreboot, in 2014, I only needed to support a handful of calls. The current standard is at 40+ calls and growing, with 7 implementations in 2 different languages. The name space for the number of calls is gigantic, and at the recent Plumber's conference, it was clear that there will be continuing pressure from vendors to add more.

A number of us are discussing implementing RISC-V CPUs with no M mode but, at this point, a lot of software will want to use SBI -- grub being one example.

Hence, a second alternative to removing M mode is to boot, then disable SBI, and let the OS handle whatever is needed. In the x86 world, this option is becoming increasingly popular, and is called "OS first" mode.

I am not requesting that you implement this call, only that you make a place for it in the standard, so that I can implement and use it in oreboot/RustSBI. The question of who will provide those runtime services -- that's a problem I'm not asking you to solve. This request is purely for making a place in the standard for such a call, no more.

atishp04 commented 2 years ago

I guess you are referring system/hart suspend SBI functions while comparing with SMM. The PMU/Remote fence/IPI operations will no longer be used on capable hardware with new ISA extensions (counter delegation, AIA). The number of SBI calls actually used in the future will be way less than what it is today. Then there are proposed extensions benefiting virtualization (Debug console, Steal time accounting) which will be added in the future.

In the "Os first" mode, you are trying to disable complete M-mode access. What is the expected behavior from M-mode after the disable SBI call ? Any further ECALL will continue trap to M-mode. Do you expect the M-mode to just return a particular error after that ?

atishp04 commented 2 years ago

SBI at this point is system management mode (SMM). There are a number of very successful attacks on SMM based on TOCTOU and SCA approaches, some just this year. Looking at the current SBI standard, there is certainly cause for concern that similar attacks might succeed as well. I suspect that SBI, if not a target today, will be one tomorrow.

In the x86 world, we are doing our best to eliminate SMM, for security reasons at least, so its reappearance and explosive growth in RISC-V is a cause for concern. When I wrote the first SBI support in coreboot, in 2014, I only needed to support a handful of calls. The current standard is at 40+ calls and growing, with 7 implementations in 2 different languages. The name space for the number of calls is gigantic, and at the recent Plumber's conference, it was clear that there will be continuing pressure from vendors to add more.

A number of us are discussing implementing RISC-V CPUs with no M mode but, at this point, a lot of software will want to use SBI -- grub being one example.

Hence, a second alternative to removing M mode is to boot, then disable SBI, and let the OS handle whatever is needed. In the x86 world, this option is becoming increasingly popular, and is called "OS first" mode.

I am not requesting that you implement this call, only that you make a place for it in the standard, so that I can implement and use it in oreboot/RustSBI. The question of who will provide those runtime services -- that's a problem I'm not asking you to solve. This request is purely for making a place in the standard for such a call, no more.

Sure. You can propose the SBI extension. However, it would be difficult to standardize anything without understanding how the system will operate after that. Moreover, introducing any new SBI extension requires complete PoC.