Skip to content

Misleading/incorrect text surrounding temporal safety #13

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

Open
jrtc27 opened this issue Oct 12, 2020 · 2 comments
Open

Misleading/incorrect text surrounding temporal safety #13

jrtc27 opened this issue Oct 12, 2020 · 2 comments

Comments

@jrtc27
Copy link

jrtc27 commented Oct 12, 2020

In "Security analysis of CHERI ISA.pdf", the "Temporal safety" section says:

however there have been architectural extension proposals such as CHERIvoke and MarkUs which allow temporal safety enforcement built upon hardware capabilities

Firstly, CHERIvoke is just an algorithm that works on CHERI without any additional architectural extensions. Whilst the paper does propose both CLoadTags and CapDirty as extensions, they are both merely optimisations, with the former allowing capability-free cache lines to be skipped over more efficiently, and the latter removing the need to emulate CapDirty emulation in software (as is done with normal dirty tracking on architectures that only have a W bit with no corresponding D bit). Notably, the follow-up Cornocopia paper, which is to a first approximation just implementing CHERIvoke on CHERI-MIPS+CheriBSD, did not use hardware CapDirty tracking and just emulated it in software (but did make use of CLoadTags to help performance).

Secondly, MarkUs does not build upon hardware capabilities. It was written to be conservative like BDW is as a GC. Like BDW it can of course be made precise in the presence of CHERI due to no longer needing to guess whether an integer is a pointer or not, but the paper targeted a plain Intel Core i5-4570.

@jrtc27
Copy link
Author

jrtc27 commented Oct 12, 2020

Moreover, it includes the following:

Those techniques aim to deterministically mitigate the vast majority of use-after-free vulnerabilities, aside from some edge cases where pointers are ‘hidden’ such as being XORed against a key, or residing in kernel memory.

That is true of MarkUs, but not for CHERI. With CHERI, you cannot XOR pointers against a key (unless you just XOR the address and the result is still within the representable region, but even then you can still reliably tell which allocation the capability is within). Whilst CHERIvoke didn't discuss capabilities being held by the kernel, the Cornucopia work does fully address this and ensure that all "hoarded" capabilities are also revoked. Barring any implementation bugs, there should be no such edge cases.

@jrtc27
Copy link
Author

jrtc27 commented Oct 12, 2020

The final paragraph of the section also talks about Cornucopia like it's a distinct thing, but it's just an implementation of the ideas modelled in the CHERIvoke paper. Talking about them like they're different will just mislead people.

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

No branches or pull requests

1 participant