Clarify behaviour of scss with malformed bounds #279
Conversation
This clarifies that malformed capabilities have bounds of [0,0) for the purposes of SCSS. I think their bounds don't affect any other instructions except GCBASE and GCLEN which already specify 0. CBLD is unaffect because it checks for malformed capabilities explicitly. This behaviour can almost be inferred from GCBASE and GCLEN, but I think it's better to be explicit rather than to depend on the assumption that SCSS behaves the same as those instructions.
|
Agreed. You could imagine saying that |
|
LGTM. @Timmmm can you file an issue to match? |
|
late in adding this, but I think from a HW perspective it's much better to always return
It's the case that |
|
Do you think all hardware would be implemented like that? I mean I would have thought you just have some kind of "bounds decoder" unit and then always do the comparison, so your SCSS unit doesn't actually care about whether the bounds are malformed or not (basically how the Sail code works). That "bounds decoder" would already output 0s for malformed caps because that's what GCBASE/GCLEN require. (I'm not a hardware designer though so maybe it's not that simple?) |
|
It's certainly simpler to say "just return zero" because that way it's just a single AND gate on the result if either input is malformed. So I'm in favour of simplifying it. Cheaper hardware, and a defined output. |
|
Sounds reasonable. The only issue I can imagine is that it's a bit inconsistent with |
|
How much is it really simplifying though? And I don’t think you can say it’s always simplifying for every uarch. I much prefer being consistent in the architecture to adding potential warts that may minorly improve the size of some uarches. |
|
Eh, on the architectural consistency front this could go either way: you might expect that |
|
That's a fair point |
|
While we're at it, are there any other instructions which need additional definition for malformed inputs? It would be good to fix them all at once |
|
Going through all the Zcheripurecap instructions: It's important to make sure Then just To cover the rest of the instructions, I can then see four different reasonable strategies:
Architecturally, I think 2, 3 and 4 are indistinguishable, so the spec doesn't have to clarify. 1 is observably different from the others only if you're worried about what to do if the memory can contain things that weren't written by the core. All that to say, I don't think we need extra clarification, though the current wording of "Capabilities with malformed bounds are always invalid anywhere in the system i.e. their tags are always 0." could be read to mean 1 (i.e. it's telling you they can't exist tagged so the core doesn't have to worry about it), or (2, 3 or 4), i.e. this is something the design should make sure is true. |
|
Just a quick comment, although we need to go through them all thoroughly. All the others actually require execution, although modifying load data is undesirable (although we already plan to tag clear on LC on some occasions - but that's not dependant on the loaded data). |
|
Good point! Sounds like 4. may be the way to go in practice then. |
|
maybe - although that adds more data dependant logic to stores. |
|
To clarify from the meeting, maybe it makes sense to just make any bounds check fail given a malformed cap. That probably wants to be explicit (there's a weirdness that a malformed cap would let you setBounds a real cap with bounds [0, 0) if you decide to legalise it that way). To redo the list: 7.1.1. CMV Doesn't care That probably makes much more sense: you only do the malformed check when you're already doing the much more expensive bounds check anyway, and only things that care about the bounds check for them being a reserved encoding, just like permissions. Sorry for overcomplicating it! |
|
"Capabilities with malformed bounds are always invalid anywhere in the system i.e. their tags are always 0." should probably be changed to something like "Bounds checks always fail if the authorising capability has malformed bounds. The core will never construct a tagged capability with malformed bounds." |
|
Some thoughts: We need to define:
I think that covers it.... |
I think this is not necessary because the address of a malformed cap doesn't matter since its bounds are 0? |
I suspect it will actually be cheaper to just detag: otherwise hardware will have to wait for the mux on the bounds to resolve before feeding it into the representability check? |
I agree that should be the effect. I don't think this needs to litter the spec too much though? Hopefully we can specify that malformed caps fail all bounds and representability checks, and people can look at the sail to make fully sure? The current notes on |
|
I would say that the page for every instruction which writes a capability should have a malformed cap handling statement so it's unambiguous. Which will be a small number of include files, and pull the correct one into each page. I'll give that a go..... |
|
Just been discussing tagged malformed permissions with Tariq and what to do with them when dereferencing. Keeping in line with the GCPERM and ACPERM behaviour, if ACPERM could not have created the permissions, all permissions should be treated as 0. For instance, a tagged cap with ASR + load + store (and no execute) will cause a permissions violation if you try to dereference it. |
|
Yes, sorry, I was imagining that behaviour, but I guess we didn't really define it anywhere. I think the idea of malformed caps is a little confusing because it covers {malformed bounds, reserved permissions encodings, reserved bits set}. It sounds like we're converging on the behaviour that {malformed bounds => read as zero and fail all bounds checks, reserved perms => read as zero and fail all perm checks, reserved bits => don't let the tag become set (with CBLD) but otherwise ignore} |
More clarification on malformed capability handling, following the discussion in #279 cmv, lc, sc, amoswap.c propagate malformed caps caddi, cadd, scaddr, scbnds* de-tag gchi, gcperm ignore gcbase, gclen return 0 also if the permission can't be created by ACPERM then clear _all_ permissions, which affect load/store/cbo/amo dereferencing and also the target capability for JALR --------- Signed-off-by: Tariq Kurd <[email protected]> Co-authored-by: Alexander Richardson <[email protected]>
This clarifies that malformed capabilities have bounds of [0,0) for the purposes of SCSS. I think their bounds don't affect any other instructions except GCBASE and GCLEN which already specify 0. CBLD is unaffect because it checks for malformed capabilities explicitly.
This behaviour can almost be inferred from GCBASE and GCLEN, but I think it's better to be explicit rather than to depend on the assumption that SCSS behaves the same as those instructions.
Fixes #281