Clean up MTDC #21
Comments
Since you have 3 registers, you can initialize the three of them with the 3 different roots. (And revert the following commit e0c5663). |
|
I think the switcher already uses m scratch. |
We could, but putting something non-executable in |
|
.
Don't think so. Where? |
|
If we do decide to use either |
|
It’s convenient for the early loader to be able to keep all of the roots in SCRs so that they can be preserved across calls without needing the stack to be usable. The other option, which might be cleaner, would be to add three new read-only SCRs for the roots, plus a write-only CSR that makes them inaccessible. |
No, still MTDC. I must be thinking of an old version. Easy change to make though. |
The semantics of MTCC is to clear the tag bit on a bad write, and the semantics of MEPCC is to clear the tag bit on bad read (including MRet) - bad read/write is when you need to zero out one or two LSB bits and it becomes unrepresentable. The idea is to run the early loader first which copies these into some specific memory. We already have MScratch holding the seal root, which has to be copied somewhere before execution starts. Adding 3 new CSRs could be a solution because now we don't have to copy any root capabilities into memory, at the cost of a total 6 SCR slots out of 32 slots. I agree that if restricted to putting arbitrary roots in arbitrary SCRs, putting the data root in MEPCC is better than putting that in MTCC. |
|
For a two-stage loader, it is convenient to keep them in SCRs while the first-stage loader runs. I’m not sure what the implications would be on software of not being able to do this (though possibly we still could, the loaders currently run with interrupts disabled and should reboot on traps). We may not need to permanently consume SCR slots with three new ones. If we later introduce three that are not needed during early boot then the monotonic toggle can move them from holding the roots to their alternative use. |
Isn't that exactly the same as using the MTCC, MEPCC and MScratch for holding the 3 roots and later switching them for alternative use? |
|
If possible, could we avoid putting the rw root in GPR? It might be just a matter of opinions but I am a little uneasy about a) making a special case in GPR that in some cases could make implementations more complex b) an reset (due to glitch attacks, etc) may suddenly place a root capability back into a GPR.. |
That's an interesting thought. If it's in an SCR, then you'd need to trick the switcher into misusing it (since it's the only thing that runs with ASR permission). |
|
I think my preferred option for this is to rename |
I would prefer to remove it, since we will probably lose it in v2, but I see that it's hard.
It's annoying to have an SCR that exists solely to hold a root at boot time, but I guess it's unavoidable. |
|
Having an extra scratch register may allow some optimisation in the switcher? Doesn't seem too bad. |
|
In v2, we'll have to add it as an explicit delta to Zcheripurecap. I don't really like having a thing that we're explicitly adding and then not using for anything. |
Oh, that's an interesting aspect I'd not considered. Can you say more about why you want that invariant? |
|
See also discussion at riscv/riscv-cheri#391 |
We now validate capabilities when they are written to those CSRs (checking that they are executable and not sealed) with violations resulting in clearing the tag. This somewhat simplifies exception handling. Having a non-executable capability in them on reset would violate that invariant. |
|
If we adopt Zstid as part of v2, we would have another CSR we could initialize and that we'd actually use (for
|
We inherited the
MTDC(trap default capability) special capability register from upstream but it isn't needed as we don't support hybrid mode. It would make more sense to get rid of it and keep onlyMScratchC,MEPCCandMTCC. This would need a few changes in ISA and RTOS:MTDCcurrently contains the RW root on reset. We'd need to put it somewhere else, perhaps in thec1/x1GPR?MScratchCas a scratch register instead ofMTDC! This should be trivial.The text was updated successfully, but these errors were encountered: