Extend access type to cache accesses

[KotorinMinami]

Added an implementation for #787, but I was wondering how to implement this TODO in the comment

// TODO: This is incorrect since CHERI only requires at least one byte
// to be in bounds here, whereas ext_data_get_addr() checks that all bytes
// are in bounds. We will need to add a new function, parameter or access type.

[github-actions]

Test Results

396 tests  ±0   396 ✅ ±0   1m 19s ⏱️ ±0s
  1 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit aaf0b57. ± Comparison against base commit 4f3907e.

[arichardson]

Isn't zeroing just a write?

[Timmmm]

It behaves slightly differently because the address of a CBO zero is aligned to the cache block size.

[Timmmm]

I'm getting pretty close to pushing our latest code (just trying to get it to build) so give me a couple of days and then I can point you at it.

[Timmmm]

Here's how we are doing it for CBOs:

https://github.com/CHERI-Alliance/sail-riscv/blob/de9279755a2fbce96314083bff884f21e6937992/model/riscv_insts_zicboz.sail#L34

https://github.com/CHERI-Alliance/sail-riscv/blob/de9279755a2fbce96314083bff884f21e6937992/model/riscv_insts_zicbom.sail#L48-L53

Basically you just have to make sure to pass in the correct access type, and for cbom it is based on the original access type rather than the modified one.

@tomaird that bit isn't super clear in the CHERI spec. Do you know where it came from?

[tomaird]

Not sure I understand which bit isn't clear so I'll just explain the full rationale behind all this code...

The CHERI spec describes the following checks for the CBO instructions (amongst others):

CBO   | Bounds    | Permissions
--------------------------------
CLEAN | Any byte  | W+R
FLUSH | Any byte  | W+R
INVAL | Any byte  | W+R+ASR
ZERO  | All bytes | W

So for the bounds check, CLEAN/FLUSH/INVAL all behave the same - it only needs a single byte to be in bounds.

But for the permissions checks it's a bit different, with CBO.INVAL requiring more permissions than the others.

The RISC-V spec describes that CBO.INVAL can also do a flush depending on xenvcfg.cbie, which in the model we treat as executing a CBO.FLUSH. But from the table above you can see that CBO.FLUSH has a looser permissions requirement than CBO.INVAL, so we need to make sure we do the permissions check based on what instruction actually executed, i.e. the CBO.INVAL, rather than what we're effectively executing in the model. Hence the need to pass in the "original" access type.

Does that answer your question?

[Timmmm]

Yeah I think my question is do you definitely still need ASR permission if INVAL executes as FLUSH. My understanding was that INVAL needs the extra permission because it's "unsafe" - you can resurrect capabilities that should have died. But if it's actually doing a FLUSH then it's safe.

Although now that I check the spec again it does actually explicitly mention this:

The CBIE bit in menvcfg and senvcfg indicates whether CBO.INVAL performs cache block flushes instead of invalidations for less privileged modes. The instruction checks shown in the table below remain unchanged regardless of the value of CBIE and the privilege mode.