Clarify permissions when the level extension is not implemented

[arichardson]

Update the infinite cap bit pattern and add a note to GCPERM.

[arichardson]

We could also report a hardcoded 1 here since not implementing the levels extension ensures that all loads/stores behave as if the permissions were always granted. But I think being able to easily detect whether the levels ext is implemented probably makes more sense?

[jrtc27]

I mean, the RISC-V way is to get that information externally, for better or (generally) worse.

[arichardson]

That's true, happy to use hardwired to 1 instead if that sounds better to you?

I noticed I also need to update the infinite cap format to set those bits to zero/one.

This change is motivated by CHERI-Alliance/sail-cheri-riscv#3 since I noticed the M bit location was wrong.

[jrtc27]

Reserved bits should be 0, and without levels the bits are reserved. When an extension adds meaning to those bits, the existing bit pattern should be unchanged in its meaning. I'm concerned the latter isn't true if the natural default is 1.

[arichardson]

I agree that reserved bits should be zero. The problem is that if we add new permissions, those will generally be '1' for permissive behaviour and '0' for restricted, so the natural default is 1 even though cores that don't implement this extension will be reporting zero and doing the permissive behaviour. I am not sure if this can really be fixed.

[jrtc27]

You invert them, you have RES1 bits or you have separate feature enable bits. #502 is the short dump of thoughts I have on the matter, and that I've brought up many times over the years wanting people to think about this carefully with worked examples, to no avail.

[tariqkurd-repo]

ok - so RES1 seems like the way to go

[arichardson]

For the in-memory format it seems like we would have to use inverted bit meaning? Otherwise if we use RES1 we end up having those permissions set to 0 for the null cap which sounds like it would be a problem?

[arichardson]

If we go for RES1 on GCPERM/ACPERM, does that mean we need to have all unused bits hardwired to one?

That would break patterns like gcperm(acperm(cap, REQUESTED_PERMS)) == REQUESTED_PERMS to check if you got exactly what you asked for.

[jrtc27]

These are all good questions that need to be thought through carefully, hence my repeated invitations to think about the problem (e.g. I mentioned this back in October 2023 on our internal Slack)...