Permute ACPERMS integer operand's bits

[nwf-msr]

As discussed on the mailing list (here, here, and here) and as part of #294 and #324, we should permute the current bit pattern used by ACPERM (https://github.com/riscv/riscv-cheri/blob/main/src/img/acperm_bit_field.edn) to leave the bottom-most bits available for extensions.

In RISC-V, an arbitrary value for the least significant four bits of an otherwise all-1s XLEN-length word, n in 0xF...Fn, can be synthesized with a single compressed instruction. That is, these bits are somewhat more precious than the others.

In more detail, presently, ACPERM's bit pattern's least significant bits are C, R, W, and X. Experience (between big-CHERI and CHERIoT) suggests that C, R, and X are relatively rarely modified, while W and non-base-specification permissions (load-global, load-mutable) are more often changed as part of exchanging data and structures across trust boundaries.

Therefore, it would be nice for C, R, and X to be moved up to higher bits in the ACPERM bit pattern, with their prior locations left reserved for further extensions (such as the as-yet hypothetical Zcheriot).

[andresag01]

@nwf-msr : Which instruction(s) do you have in mind for producing the arbitrary 4-bit value you mentioned here? I am guessing is c.andi, but that has a 6-bit immediate out of which bit 5 is the sign (i.e. 5 useful bits).

In RISC-V, an arbitrary value for the least significant four bits of an otherwise all-1s XLEN-length word

We currently have these architectural permissions defined:

• Bit 0: C
• Bit 1: W
• Bit 2: R
• Bit 3: X
• Bit 4: ASR
• Bit 5: LM
• Bit 6 to XLEN-1: Reserved

How about something like this instead? (I am assuming that LM and ASR do not change very often either)

• Bit 0: Reserved
• Bit 1: Reserved
• Bit 2: Reserved
• Bit 3: W
• Bit 4: LM
• Bit 5: C
• Bit 6: ASR
• Bit 7: X
• Bit 8: R
• Bit 9 to XLEN-1: Reserved

[nwf-msr]

@nwf-msr : Which instruction(s) do you have in mind for producing the arbitrary 4-bit value you mentioned here? I am guessing is c.andi, but that has a 6-bit immediate out of which bit 5 is the sign (i.e. 5 useful bits).

Oh, indeed, I just can't count. Even better. :)

How about something like this instead? (I am assuming that LM and ASR do not change very often
either)

ASR changes roughly never, yes.

• Bit 0: Reserved
• Bit 1: Reserved
• Bit 2: Reserved
• Bit 3: W
• Bit 4: LM
• Bit 5: C
• Bit 6: ASR
• Bit 7: X
• Bit 8: R
• Bit 9 to XLEN-1: Reserved

I think that's a perfectly sensible order and, FWIW, is pretty close to the CHERIoT one.

• CHERIoT defined our bottom five bits as, up to spelling, SL LM W LG GL; the three of SL, LG, and GL don't exist in Zcheri, but would slot nicely into those three reserved bits. I don't see any reason to prefer CHERIoT's current order over, say, a LM W SL LG GL order that'd be compatible with your proposal above.

• The upper bits of CHERIoT's ACPERM operand equivalent were U0 SE US X ASR C R. U0, SE, and US also don't exist in Zcheri. Again, I don't see any huge significance to the difference between CHERIoT's current order and your proposed R X ASR C, since andi has a 12-bit immediate, so all those are within reach anyway.

@davidchisnall might recall something I'm overlookng, tho'.

[andresag01]

@nwf-msr : Thanks for the info. I will prepare a PR.

@jonwoodruff also pointed out that we would ideally put the software-defined permissions within the 12 LSBs because these are often (perhaps in the allocator? I cannot remember exactly were!), so I will shift those around as well.

[arichardson]

I agree that it makes sense to keep the user perms within the 12-bit immediate so that allocators/the kernel can check for them using one instruction less. Not a huge performance improvement, but probably worth doing anyway. The only awkward thing we might need to consider is that the user-perms are "variable length" so any new permissions might need to end up quite high up unless we say "uperm 0/1 go at the low offset, later user-perms start at 32 (since they are rv64 only).

It would be worth checking if the allocator/kernel check any bits in addition to the user bits.