Write note about traps for capability stores #528
Conversation
andresag01
changed the title
| for software to discover and/or control the behavior# | ||
| NOTE: Future extensions to {cheri_base_ext_name} may add mechanisms that cause | ||
| stores to raise exceptions when the authorizing capability does not grant both | ||
| <<w_perm>> and <<c_perm>>. |
There was a problem hiding this comment.
I think this needs an “if the tag of the capability being stored to memory is set” somewhere?
There was a problem hiding this comment.
We could add that to be extra clear but I since this is a note underneath "what happens when you don't have "C+W" I think it's probably fine to omit this clarification.
There was a problem hiding this comment.
I see nothing that states this any of this isn't for SC as a whole. The paragraph above just says the tag is cleared. C says "Allow reading capability data from memory if the authorizing capability also grants R-permission. Allow writing capability data to memory if the authorizing capability also grants W-permission." We don't define capability data anywhere, so a completely reasonable, if false, interpretation would be that any LC/SC counts as a load/store of capability data. 3.2.1 Tag talks about valid and invalid capabilities. I would in fact argue that capability data is both valid and invalid capabilities. Similarly, we have "Missing LM-permission does not affect untagged values since this could result in surprising bit patterns when copying non-capability data. Similarly, sealed capabilities are not modified as they are not directly dereferenceable." in various places, which is assuming a definition that only encompasses valid capabilities. This is all quite loose, making implicit assumptions and, I would argue, using the wrong definition.
There was a problem hiding this comment.
I imagine a future extension could have at least two options: 1) trap for tagged data missing W|C, 2) trap for any cap store missing W|C (even if that is less useful.
I do agree that we should make sure to be explicit about anything defined in the spec but since this is about some hypothetical future thing being vague until that extension actually exists seems ok?
There was a problem hiding this comment.
Well my point is the latter is something that should not be permitted, because it breaks memcpy
There was a problem hiding this comment.
Fair, would you be willing to fix this note?
Add a note indicating that capability stores may trap in future extensions when the authorizing capability does not grant capability write permissions. Also remove outdated TODO. Fixes riscv#476
Add a note indicating that capability stores may trap in future extensions when the authorizing capability does not grant capability write permissions. Also remove outdated TODO.
Fixes #476