Clarify what happens if "Reserved 1" bits are clear in the acperm mask

[chrehrhardt]

The latest PR that introduced bits that are "Reserved 1" int the acperm/gcperm masks does not really explain what happends if one of these reserved bits is zero in the mask passed to acperm. At least two options are possible that I can think of:

• Make the bits WARL as most riscv registers do, i.e. trying to clear the bits is simply ignored on hardware that has them set to "Reserved 1".
• Clear the tag on the capability.

I'm not sure which version I'd prefer, though.

[tariqkurd-repo]

I vote for making the reserved bits WARL, so it doesn't matter what the written value is

[martin-kaiser]

If the software understands more permissions than the CPU, the software may set one of them to 0 where the default is 1.
The CPU sees an acperm instruction with a reserved1 bit set to 0. The bit is ignored anyway and does not change acperm's result.

I think this case should be supported, the reserved bits should be WARL.

[jrtc27]

If software is asking to clear a bit that doesn’t exist then it is broken. Turning it into a nop could be dangerous (eg if software expects mutable load to exist and wants to clear it when delegating a capability to some other compartment, it should not silently degrade into handing out a capability that permits stores). It should tag clear because you’ve asked for something that is not supported.

[chrehrhardt]

I actually tried to prepare software (linux kernel and musl) for this change under the assumption that the tag is cleared and it is really horrible. You would have to probe for supported hardware features not only in the kernel but also in musl on every program startup. In fact each and every software component, that is doing something non-trivial with permission bits that may or may not be supported by hardware would have to probe. Otherwise, clearing a permission bits you do know about but that happens to be unsupported on the current hardware will invalidate your capability.

And the whole point of this entire change is to ensure that the same binary can run on hardware with different features.

Thus, even though I started out being in @jrtc27 's camp I don't think it will work and I tend to agree with @arichardson that software that depends on an optional feature should check for it during runtime and refuse to even start if the feature is missing.

So if we make the bits WARL it encourages software to adopt new security features because you can just pretend that the feature is there and your software will benefit from the feature if it is supported and continue to run if it is not.
On the other hand if the tag is cleared there is no easy path to adopt a new security feature because you would either do probing and replace constant bitmask with variables or you would have to ship different binaries on hardware that has the new feature in order to make use of it, i.e. break backward compatibility.

[jrtc27]

I would like to see evidence of that; I do not see how it would be as you describe.

[LawrenceEsswood]

I think if software understands more permissions than hardware, there are really two cases:

1. Software needed to clear that bit to be correct and will not function correctly if it cannot.
2. Software was clearing that bit as a "best effort", if it was possible to clear.

(1) would prefer tag clear, but could also check whether that bit was clearable at all as part of instantiation of the library and refuse to load if it wasn't.
(2) really wants to not tag clear. Otherwise you end up writing "if feature exists, clear, else don't attempt".

Because 1) can be fixed at load time, I think we should lean to not tag clearing.

[chrehrhardt]

Trying to illustrate my point with an example: Assume that we forgot to specify the "load mutable" bit and want to introduce it as part of an extension. I think it is a very good example because it subdivides read permission and thus would be allocated into one of the "Reserved 1" bits. You can make similar points with levels but the levels feature is more complicated which makes it harder to get the point across.

Now, software that does not know about load mutable will assume that the bit is "Reserved 1" and will continue to work whether the hardware supports the feature or not. So just ignoring the new feature is a possible sweet spot. But it is not where we want the sweet spot to be for software vendors.

Once you want to start supporting the feature how would you clear the load mutable bit in a backward compatible way, i.e. in a way that allows you to run the same software stack on hardware that supports "load mutable" and on hardware that doesn't?

As @LawrenceEsswood points out you would have to do different things depending on hardware features because trying to clear "load mutable" on a hardware that does not support the feature will render your capability invalid. So software will have to probe hardware features in order to determine if it can safely clear the "load mutable" bit.

It gets even worse if you want the compiler to generate the acperm that clears load mutable e.g. based on variable annotations because the compiler has no easy means to probe for the feature on startup. Instead people will end up doing an acperm followed by something like cbld to restore the tag from the original capability.

[arichardson]

Would also be good to get some input from CHERIoT here. @davidchisnall @nwf what is your position on reserved-one bits being ignored when set to 0 in ACPERM vs tag-clearing on such a request?

[nwf]

I confess I haven't been tracking this "reserved 1 [AG]CPERM bits" thread of conversation as closely as I perhaps should have been, sorry. I'll also preface this with "perhaps I've been in the embedded space too long", so please do feel free to remind me of Big CHERI / *NIX concerns I might be overlooking.

I think my broader position is that "which permissions your capabilities can express" is at least part of the ABI, because it pretty fundamentally changes the security of software designs built atop it. Thus, I think I'm really only interested in upwards compatibility: software compiled for ABIs with fewer permissions should run on systems that understand strictly more. From the narrow point of [AG]CPERM instructions, software shouldn't be surprised that clearing a permission it knows about might also clear bits it doesn't understand, in part because it shouldn't be looking at those bits (but more because we've already said that the result of ACPERM is a maximal expressible subset of the intersection of precursor and request).

I amn't champing at the bit to think about downwards or lateral compatibility, because it's not clear to me that one can meaningfully build software that wants refinements like load-mutable (or entirely new permissions like sealing) and yet could operate without them safely. Certainly trying to run CHERIoT programs on a platform where LM is implied by L and cannot be separately cleared is going to demolish compartment isolation guarantees predicated on LM.

All that said, I guess the position I'd take on this particular point is that an ACPERM with a 0 bit in a reserved-1 position ought to clear the tag in the result: having been asked to shed a permission we can't articulate, the maximal expressible subset of the intersection is no permissions. (Dually, ACPERM with a 1 bit in a reseved-0 position does not necessitate tag-clearing, as we're being asked to preserve a permission we can't articulate, and so is by definition absent in the precursor's set.)

[chrehrhardt]

If you have this software that can only really run on hardware that has optional extensions wouldn't you have to probe for the presence of these features anyway? Relying on tag clear will likely be insufficient in this case. Apart from that the result will be that your software starts and then fails in unpredictable and unexplained ways with CHERI faults at runtime. I fail to see how this is what you want.

And as you admit doing the tag clear basically ignores that someone might want to build software that runs with and without a particular feature/extension. Many of the extensions will provide additional mitigations if used and you still get the CHERI bounds checks and other benefits of if you don't use a missing feature.

[nwf]

I've yet to see an example of software that can run with(out) a particular permission and retain its intended security properties. If you'll forgive a bit of an acknowledged hard-line stance, CHERI is supposed to provide deterministic, well-founded memory safety; it is... distressing, perhaps, to contemplate proposals for running software built with a given set of assumptions in mind without said foundations in place.

More technically, if "set of expressible permissions" is part of the ABI, as I imagine it must be, then I'd expect program linkers and loaders to balk if given inputs not known to be compatible with each other or the running system, as if one tried to load a 686-requiring program on a 486, to pick a real-world example from my past.

[chrehrhardt]

Well, all the existing C-software out there is such a software. It's been designed without CHERI in mind and we promise to make it (more) secure if it is run on CHERI. This improves security simply by having the bounds checks it doesn't even need any permission bits to prevent a substantial class of exploits. I'm not arguing that we shouldn't have permissions. But I do claim that even if hardware didn't have any permissions the bounds checks alone would be beneficial for software security. Compared to the non-CHERI version of the software that would still increase security and not reduce it.
IMHO if you are relying on CHERI for the security of your software you are doing something wrong! Software should never even attempt to perform an operation that CHERI prevents. If this happens your software is buggy in the first place.
Thus the provable security properties your are talking about are only really relevant when a malicious actor has already gained control or is about to gain control it should not have. In this case CHERi can either prevent the exploit or if the exploit already happened it can limit its scope.
If some of the permissions are not available you may not be able to proof certain properties of these limits but the permissions that are present will still prevent some types of attacks.
So if you'll forgive a bit of a commercial argument: If we want CHERI to succeed we have to make it as easy as possible for people to adopt it and saying I don't care about downward compatibility is quite the opposite. It is already very unfortunate that we cannot build CHERI enabled software that runs on non-CHERI systems. However, we should at least make the adoption of new security features possible and as easy as possible.

Having said that, this discussion clearly shows that the spec need clarification one way or the other.

[jrtc27]

IMHO if you are relying on CHERI for the security of your software you are doing something wrong!

But that's the whole premise of CHERI compartmentalisation, and it's things like "hand out a restricted pointer to some other compartment" where the question of "what should happen if you try to clear a permission that doesn't exist?" starts to become a very sensitive question, and why Wes and I are pushing back on the idea of turning invalid requests into no-ops.

Also, what happens if you start running on a system that uses a permission bit for something other than the extension you think might exist? Then your software blows up (hopefully). You cannot avoid the fact that you need to check whether the thing you want to use actually exists, and if it doesn't you have no idea what it may do, so you must not do it, and thus it is completely reasonable, and the safest option, to make the hardware tag clear if you ask for something that isn't implemented.

[chrehrhardt]

So taking a step back: With the introduction of the "Reserved 1" bits we've suddenly introduced a surprising non-intuitive effect of ACPERM and GCPERM: It is possible that GCPERM returns permissions that cannot be cleared. Maybe this is actually not what we want. Basically what we want current software to do (if it cares about forward compatibility) is preserve certain permission bits unless it knows what they mean. Preserve generally implies a read-modify-write cycle but with ACPERM this is implicit because we can never set bits and pass in a mask of bits to keep.
So one solution might be to define the bits as "Reserved Preserve" instead of "Reserved 1". This would imply that the bits are _clear_on hardware that does not support them in the bitmask reported by GCPERM. However, software is required to set the bits to "1" in any mask used for ACPERM.
Sticking with the "load mutable" example from above this would have the slightly confusing effect that the combination "read is set" and "load mutable is clear" in GCPERM would mean different things on hardware that has load mutable. However, I don't think that is a problem.
If software is written without knowing about load mutable and runs on hardware that does have it it will never look a the load mutable bit and assume that it has load mutable permission anyway.
On the other hand software that is written with load mutable in mind running on hardware that doesn't have it is the case you don't care about. If you do anyway you will have to look at the infinite cap you are given and refuse to run if it does not have the load mutable bit set. Or you continue to run and accept the fact that all loads are mutable.
Is this a viable solution?