You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#186 got fixed before I noticed, but I think we can safely fix it the other way, i.e. the "otherwise" case changes from "copy cs2 to cd and clear cd 's tag", to "copy cs2 to cd, leaving the tag unchanged". This is a behaviour we've referred to in the past as "CCBuildCap", i.e. conditional buildcap: try your best to tag the capability, but leave it as is if something goes wrong.
This could accelerate chains of buildcaps when you don't know which capability authorises the buildcap, e.g. if you want to restore tags on capabilities that could be from the stack or the heap, you can just buildcap by both in consecutive instructions without needing branches.
If software really wants to ensure the resulting cap is only tagged if it's a subset of the authorising cap, then it can clear the tag before running CBLD.
It wouldn't be the end of the world to leave things as is, but seems like a slight missed opportunity.
Note: As a side effect of this change, CBLD authorised by cnull would be safe to use as a CMV, so we could potentially get back an encoding (ccleartag?). However, that does complicate things slightly if an extension adds back in otypes, as then CBLD needs to clear the otype when setting the tag.
The text was updated successfully, but these errors were encountered:
I'm happy with the dest.tag = input.tag | <valid_cbld> semantics, if you really want to ensure you didn't get a valid capability but a subset, adding another ccleartag before seems reasonable to me. Maybe @jrtc27, @davidchisnall, @nwf or @LawrenceEsswood have opinions on this one?
However, I'm not sure if we would want those semantics for superset unsealing (#199), since you probably do want to check that you got the expected input in that case. I can see use-cases for both semantics, not sure which one results in faster code in general.
#186 got fixed before I noticed, but I think we can safely fix it the other way, i.e. the "otherwise" case changes from "copy cs2 to cd and clear cd 's tag", to "copy cs2 to cd, leaving the tag unchanged". This is a behaviour we've referred to in the past as "CCBuildCap", i.e. conditional buildcap: try your best to tag the capability, but leave it as is if something goes wrong.
This could accelerate chains of buildcaps when you don't know which capability authorises the buildcap, e.g. if you want to restore tags on capabilities that could be from the stack or the heap, you can just buildcap by both in consecutive instructions without needing branches.
If software really wants to ensure the resulting cap is only tagged if it's a subset of the authorising cap, then it can clear the tag before running
CBLD
.It wouldn't be the end of the world to leave things as is, but seems like a slight missed opportunity.
Note: As a side effect of this change,
CBLD
authorised bycnull
would be safe to use as aCMV
, so we could potentially get back an encoding (ccleartag
?). However, that does complicate things slightly if an extension adds back in otypes, as thenCBLD
needs to clear the otype when setting the tag.The text was updated successfully, but these errors were encountered: