Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve tag if CBLD checks fail #298

Open
PRugg-Cap opened this issue Jun 30, 2024 · 3 comments
Open

Preserve tag if CBLD checks fail #298

PRugg-Cap opened this issue Jun 30, 2024 · 3 comments
Labels
question Further information is requested

Comments

@PRugg-Cap
Copy link
Contributor

#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.

@tariqkurd-repo
Copy link
Collaborator

opinions on this one?

@tariqkurd-repo tariqkurd-repo added the question Further information is requested label Jul 1, 2024
@arichardson
Copy link
Collaborator

arichardson commented Jul 1, 2024

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?

@arichardson
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants