Initial proposal for Zcheri SBI #140
Conversation
This is considered to be in scope on the theory that this repository already contains patches to various specifications that touch CHERI, and the SBI is an expected part of the supervisor execution environment with the same status as ISA specifications. Permission checks for SBI ecalls are required to support compartmentalization within S-mode. Using ASR, specifically, is a nontrivial design decision with rationale laid out in https://lists.riscv.org/g/sig-cheri/message/68 . Generating a CHERI exception instead of returning a SBI error code makes the behavior consistent with ISA permission checks, improves error location for debugging, and defers committing to purely software permission checks. Using capabilities for hart start and resume avoids requiring the SBI to be able to mint Infinity capabilities at runtime and is expected to simplifiy the implementation. There is an open question whether Zcheri_legacy can be implemented in a way which maintains simultaneous upward compatibility with Zcheri_purecap and the non-CHERI base ISA. The chosen definitions here are not expected to be particularly useful, but avoid introducing new problems. Signed-off-by: Stefan O'Rear <[email protected]>
Some of this could be moved to an "Extending CHERI RISC-V" section. Signed-off-by: Stefan O'Rear <[email protected]>
|
I don't think it's useful to spend too much time looking at something as boring as SBI until the ISA is more nailed down. At the end of the day it is just engineering. We have plenty of experience with system calls for CHERI, and SBI calls are just system calls at a different level of the stack. I'll also note that the whole firmware feature enable situation is stupid and should be under S-mode control without the need to involve firmware. I know this is inherited from things like Svadu, but that is also a stupid situation where people decided to ignore the industry-standard way of doing things and instead patch over deficient ISA extensions with firmware. We can and should do better. |
| Invocation of SBI functions is only allowed if <<pcc>> grants <<asr_perm>>. If | ||
| an `ECALL` instruction is executed with <<pcc>> that does not grant | ||
| <<asr_perm>>, the supervisor execution environment generates a CHERI exception. | ||
| <<stval>> is set as for a forbidden CSR access. |
There was a problem hiding this comment.
While I believe this makes sense for most calls, I think this may be overly restrictive. I don't see anything in the current space that would be particularly useful to non-ASR callers, but I think we should allow SBI to expose APIs that are available to all callers (e.g. do we really need to restrict querying the SBI version?).
The rationale for expanding the definition of ASR in this way is given in https://lists.riscv.org/g/sig-cheri/message/68, and that may be a better forum for long discussions of the underlying premise.
The SBI is considered to be in scope on the theory that this repository already contains patches to various specifications that touch CHERI, and the SBI is an expected part of the supervisor execution environment with the same status as ISA specifications.
There is an open question whether a Zcheri_legacy SBI can be implemented in a way which maintains simultaneous upward compatibility with Zcheri_purecap and the non-CHERI base ISA.