Skip to content

Prove finaliseCap_ccorres#962

Open
michaelmcinerney wants to merge 2 commits intortfrom
michaelm-finaliseCap
Open

Prove finaliseCap_ccorres#962
michaelmcinerney wants to merge 2 commits intortfrom
michaelm-finaliseCap

Conversation

@michaelmcinerney
Copy link
Contributor

Test with seL4/seL4#1474

Signed-off-by: Michael McInerney <michael.mcinerney@proofcraft.systems>
@michaelmcinerney michaelmcinerney self-assigned this Feb 12, 2026
@michaelmcinerney michaelmcinerney added the MCS related to `rt` branch and mixed-criticality systems label Feb 12, 2026
Comment on lines 1591 to 1594
lemma option_to_ctcb_ptr_canonical:
"\<lbrakk>pspace_canonical' s; tcb_at' tcb s\<rbrakk>
\<Longrightarrow> option_to_ctcb_ptr (Some tcb)
= tcb_Ptr (sign_extend canonical_bit (ptr_val (tcb_ptr_to_ctcb_ptr tcb)))"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surprised we don't have this yet, it looks like something we'd want all over the place.

In AARCH64 we introduced make_canonical for similar things (just the sign_extend part) -- the definition from AARCH64 doesn't fit here, because AARCH64 doesn't sign extend, for RISCV64 it'd probably be exactly make_canonical = sign_extend canonical_bit. I'm not sure it makes sense to introduce that here now into RISCV64, because it would probably introduce a bit of noise for not too much gain, but if you find yourself having to do slots of things about sign_extend canonical_bit then maybe consider it.

In any case, we should move this lemma somewhere high up in the hierarchy, at least TcbAcc_C, so that it is visible to earlier proofs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was just moved up in this file, but I can put it in TcbAcc_C.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly not even from MCS, but it would still be good to move it up to make sure it's visible.

Comment on lines -3772 to -3773
lemma cancelIPC_ccorres1:
assumes cteDeleteOne_ccorres:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice to see this disappear.

Comment on lines 1699 to 1702
lemma obj_at_cslift_ntfn:
"\<lbrakk>obj_at' P ntfn s; (s, s') \<in> rf_sr\<rbrakk>
\<Longrightarrow> \<exists>ko ko'. ko_at' ko ntfn s \<and> P ko \<and> cslift s' (Ptr ntfn) = Some ko'
\<and> cnotification_relation (cslift s') ko ko'"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this one moved from somewhere? It should be moved high up, to wherever we have basic lemmas about notifications (not sure if PSpace_C is too high, maybe TcbAcc_C. We should resurrect that tool that tells us the highest theory something can go into.).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style nitpick: the indentation of the /\ looks off by one

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is new, but I can move it. It's just the notification version of other lemmas like this that we have.

And there's no meta for-all here. Did you mean another lemma?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh that's a conjunction, sorry. It looks OK to me in jedit. In the second line of the conclusion, the /\ is aligned with the ko_at' because it's all part of the unquantified bit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I meant that conjunction. Perfectly possible that it just looks off because of the GitHub symbol rendering.

Copy link
Member

@lsf37 lsf37 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good, only very minor comments/queries. Nice to see how adding the assertions simplifies a lot of the preconditions!

Signed-off-by: Michael McInerney <michael.mcinerney@proofcraft.systems>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

MCS related to `rt` branch and mixed-criticality systems

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants