After 1.0 consider decomposing Zyhybrid

[tariqkurd-repo]

We should consider allowing implementations to enable/disable CHERI via xenvcfg.Y without needing to support hybrid mode, and so without allocating the P-bit in the metadata.

Currently you need to have both, but I think it's reasonable to be able to run standard RISC-V binaries without supporting hybrid mode.

This is a proposed re-organisation of extensions, not a spec change as such.

[tariqkurd-repo]

As Jessica Clarke (@jrtc27) pointed out on #1158, DDC is also required if misa.Y is writeable.

[jrtc27]

I reeeeeeally don't want to get into a world where software can "turn off CHERI" without there being a DDC. Hardware fuse, sure, and maybe even some vendor-specific thing only very early firmware can touch, but not in the standard.

[tariqkurd-repo]

yes agreed - turning it off definitely requires DDC

It's a thought experiment that we can decompose it differently into

1. MISA.Y, xENVCFG.Y writable + DDC
2. P-bit in metadata and MODESW* instructions
   only because the metadata bits are precious, so may have use cases that need 1. but not 2. and want to use the metadata for other purposes.

[jrtc27]

Well, they're different, though. Turning off Y gives you no capabilities whatsoever (and gives you back all the custom space for its original uses). You need MODESW.CAP (and .INT back) to be able to do anything with capabilities. That is, turning off Y, whether via misa or the next mode's xenvcfg, gives you vanilla I/E not hybrid, whereas P/MODESW* gives you hybrid.

And once you start doing it via xenvcfg you need to think very carefully about how you deal with DDC, xtvec and xepcc. Probably a mix of legalisation and dynamic xret checks.

But this is all unproven future research.

[arichardson]

I think this is definitely worth having. In (#1158 (comment)) I said we would need to change the reset state to misa.Y=0 for such a system since we need to be running in compat mode on startup. But actually thinking about it a bit more: as long as it's just the bootrom reading a fuse and setting the CSR we could even start up with misa.Y=1 and let the bootrom disable it before jumping to the next stage. Then the "real user code" would only ever see a purecap only or a "non-CHERI" only system.

[arichardson]

So the real question is: is we say it must be read only without zyhybrid, does that prevent vendors from allowing writes in the bootrom? I guess technically that's no longer compliant, but not sure how this is handled for other extensions.

[jrtc27]

I don't think so. If, once control has transferred from the bootrom, you cannot observe it being writable, then the bootrom is just part of the reset process, though you probably need to be a bit careful of the debugger hijacking that sequence.

[tariqkurd-repo]

Just to repeat the message from above - I think this decomposition of Zyhybrid works:

1. MISA.Y writeable, XENVCFG.Y writeable, DDC
2. All YMODE instructions and the P-bit

With part (1) you get standard RISC-V binaries including custom encodings to run but no int mode as there's no P-bit.
With part (2) as well you get int mode.

Is there any reason why part (1) standalone wouldn't work? I agree that the boot code can sort out MISA.Y before handing on to the next stage.

[jrtc27]

How do you prevent xRET to mode y with Y disabled but PCC, DDC and/or zTVEC/zTEPC for all z <= y not almighty? With just the misa.Y way of turning off Y those must all be almighty for misa.Y=0 to be legal, but with xENVCFG.Y being writable it becomes much more complicated, especially with DDC being shared across modes (so you expect it to be null when you turn off xENVCFG.Y, because that's a purecap environment, but must have it be almighty if you're going to xRET to that mode or above).

I think there's probably a way to work, but I am going to be very clear here:

Please can we not start talking about possible future directions before we've finished the current spec? That is the priority. And all these suggestions are speculative and unproven ideas that require research to determine if and how they might be viable. And if we start talking about all these things we could do with the spec without it being very clear of that fact, people might then start asking why we're not allowing things like this. So, please, let's not muddy the waters.