PTE permission requirements for CMOs are not clear

[Timmmm]

The privileged spec says:

Attempting to fetch an instruction from a page that does not have execute permissions raises a fetch page-fault exception. Attempting to execute a load or load-reserved instruction whose effective address lies within a page without read permissions raises a load page-fault exception. Attempting to execute a store, store-conditional, or AMO instruction whose effective address lies within a page without write permissions raises a store page-fault exception.

However it says nothing for CMOs. The unprivileged spec says:

A cache-block zero instruction is permitted to access the specified cache block whenever a store instruction is permitted to access the corresponding physical addresses...

and

A cache-block management instruction is permitted to access the specified cache block whenever a load instruction or store instruction is permitted to access the corresponding physical addresses....

But it's very ambiguous whether that applies to PTE checks. As I understand it, the unprivileged spec doesn't really know about the address translation process at all so in theory this can't really be saying anything about PTE checks. Which means the PTE checks for CMOs are not specified.

Presumably we want:

Attempting to fetch an instruction from a page that does not have execute permissions raises a fetch page-fault exception. Attempting to execute a load, load-reserved, or cache-block management instruction whose effective address lies within a page without read permissions raises a load page-fault exception. Attempting to execute a store, store-conditional, AMO, or cache-block zero instruction whose effective address lies within a page without write permissions raises a store page-fault exception.

I think it's ok to only require read for cbo.flush/inval/clean even though it says read or write is required, because write-only PTEs are reserved (similarly to how an AMO only requires write permission).

(I don't know why cbo.inval doesn't require write permission, seeing as it can actually modify the observable memory contents, but there we go.)

[gfavor]

As noted, the unpriv spec is unaware of any and all protection/permission mechanisms managed by the execution environment. So when the CMO spec, for example, requires "load and/or store permission" (i.e. read and/or write permission), that encompasses all mechanisms that factor into whether a load or store instruction has permission to read/write a memory location. In other words, for example, "load and/or store permission" reflects not just MMU page tables, but also PMP and PMA. (Or in a system with SPMP, or ePMP, or one of the newer memory protection mechanisms being developed in RVI - these would also factor into the bottom-line "load and/or store permission".

Btw, changing the permission semantics for the cbom instructions is not an option, i.e. RVI does not allow ratified extensions to be changed. And another recent github issue against the CMO spec touched on why the CMO spec is the way that it is.

Regarding cbo.inval permission requirements, note that a cbo.flush can also potentially change the contents of main memory, e.g. a non-coherent DMA has written to memory while a "now stale" cached copy exists - which if flushed out to memory will overwite the newer data with older stale data. "Correct" software should use cbom instructions to manage and avoid this situation, but then again "correct" software should also not try to access memory that it doesn't have permission to access.

In any case, "why cbo.inval doesn't require write permission" is something to ask people that were more intimately involved in the development of the CMO spec (e.g. inquire on the tech-cmo email list).

[Timmmm]

Hmm it still feels a little ambiguous unless you already know the answer. Can't hurt to be specific in a specification right? (Except on verbosity grounds; but this is only 9 extra words.) Would you accept a PR for that suggestion?

Btw, changing the permission semantics for the cbom instructions is not an option, i.e. RVI does not allow ratified extensions to be changed.

Agreed, but I don't think my suggestion does change the semantics?

note that a cbo.flush can also potentially change the contents of main memory

Sure, but not from the perspective of the hart that performs that operation. cbo.inval is crazier because it effectively allows you to write to read-only memory, even in a system with only one hart and no other memory agents. I guess that is why they made it possible to configure it to actually perform a flush. Sorry getting a bit off-topic here!

[gfavor]

To minimize your effort to start with, can you post here what your "9 word" clarification be. Or create a PR if you prefer. That will provide something concrete for Andrew (and me and if need be the ARC) to evaluate.