search

CTSRD-CHERI / cheri-specification

CHERI ISA Specification
Other
23 stars 7 forks source link

CHERI privilege level enable #70

Open tariqkurd-repo opened 1 year ago

tariqkurd-repo commented 1 year ago

A bit in Xenvcfg has recently been allocated in the CHERI spec to enable/disable CHERI at different privilege levels. Looking at https://github.com/CTSRD-CHERI/cheri-specification/issues/69 I think that it is correct not to add a bit into Xsmstateen following the model of the F and V extensions which add register file state, CSRs and instructions.

I agree that this is necessary for running (e.g.) user code which is not CHERI aware, so that it doesn't have any access to CHERI state or instructions. pcc/ddc checks remain active, and the trap handlers always use the full capability values in Xtcc/Xepcc.

I'm having a problem understanding this: Capability mode is always honored if enabled in PCC

I don't understand how you can be in capability mode and have CHERI disabled, and it's really not clear to me what this means for the operation of the machine.

To my mind, the combination of Xenvcfg.cheri_enable=0 for the current privilege level and pcc.flag=1 should be a PCC fault because you are in an illegal context, and should immediately except. Just like if the pcc has become untagged.

Therefore I would prefer a statement along the lines of it is illegal to be in capability mode when CHERI is disabled in Xenvcfg for the current privilege level

jrtc27 commented 1 year ago

With what exception? Illegal instruction?

tariqkurd-repo commented 1 year ago

Based on the table in https://github.com/CTSRD-CHERI/cheri-specification/issues/66 I'd like all PCC faults to be instruction access faults which are detected pre-translation, including this case.

tariqkurd-repo commented 1 year ago

Having Xenvcfg.cheri_enable control the mode of the CPU, and allowing PCC.flag=1 when CHERI is disabled causes a lot of issues, primarily for verification.

Without Xenvcfg.cheri_enable we have integer and cap mode - which already causes decoder complexity such as c.flw (integer mode) becoming c.clc (cap mode) - this new mode then adds another state so that presumably c.fld becomes illegal if Xenvcfg.cheri_enable=0 and PCC.flag=1? Therefore the decode for c.fld now has three options instead of 2. Similar for jalr/cjalr they now have the extra choice of jalr/cjalr/illegal.

The first three makes sense to me:

Xenvcfg.cheri_enable=1 && PCC.flag=0 - integer mode, allow CHERI instructions decoder mapping: (jalr -> jalr, c.fld -> c.fld, CRAM -> CRAM)

Xenvcfg.cheri_enable=1 && PCC.flag=1 - capability mode, allow CHERI instructions decoder mapping: (jalr -> cjalr, c.fld -> c.clc, CRAM -> CRAM)

Xenvcfg.cheri_enable=0 && PCC.flag=0 - integer mode, disallow CHERI instructions decoder mapping: (jalr -> jalr, c.fld -> c.fld, CRAM -> illegal)

but this one is problematic and has no obvious value:

Xenvcfg.cheri_enable=0 && PCC.flag=1 - integer mode, disallow CHERI instructions decoder mapping: (jalr -> illegal, c.fld -> illegal, CRAM -> illegal)

So my proposal is that the following cases detag the next PCC so there's a tag fault:

. Xret to a mode where cheri_enable=0 and Xepcc.flag=1 .cjalr/jalr.cap to a mode where cheri_enable=0 and cs1.flag=1

which I believe covers all the cases of entering that mode.

Additonally we wouldn't know what to expand c.mv, as we expand it to mv in integer mode and cmove in cap mode. Does that mean c.mv would be illegal?

bsdjhb commented 1 year ago

I'm a fan of making capmode illegal when cheri_enable=0 because I think it provides the best foot-shooting protection. I think when we had discussed this in the earlier PR the question turned on which was simpler to implement and at that time it was felt that permitting capmode was simpler to implement. I think the idea though was that you wouldn't change the meaning of capmode-specific instructions when CHERI was disabled. Disabling CHERI would be more about disabling new instructions such as csetbounds and capmode instructions would be decoded the same regardless. For the c.clc case, does this not follow the same path used for clc which would have to handle the two states (cheri_enable 0 vs 1), or do you have a dedicated path for the 16-bit instruction separate from the 32-bit?

andresag01 commented 1 year ago

As discussed before, it would be good to add an option in a CSR to enable/disable CHERI instructions for M-mode. If disabled, CHERI is effectively disable in the entire machine.