-
Notifications
You must be signed in to change notification settings - Fork 9
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
Consider weakening return sentries to support compiler outlining #85
Comments
If we made a non-cra link register provide an unsealed capability, then the following two sequences are equivalent: cjal {target}, ct0 0:
auipcc ct0, %cheriot_compartment_hi(1f)
cincoffset ct0, ct0, %cheriot_compartment_lo_i(0b)
j {target}
1: In both cases, you return with I believe this means that there is no security implication and the relaxation on |
As David points out this doesn't really weaken the current model at all. It really just fixes an anomaly in the above table where row three is not currently that useful: it can be used for making a function call with a non-standard link register but the called function has to move that register into |
Attempt at capturing #85 Co-authored-by: Robert Norton <[email protected]>
Another thing to note is that, in a call to a library, if a caller compartment wishes to sanitize the arguments and force the library to only use the correct return entry points (i.e. not trust the library), it can always use |
Attempt at capturing #85 Co-authored-by: Robert Norton <[email protected]>
I did a measurement with and without outlining disabled. Re-enabling MachineOutliner will save us approximately 4.4% code size (according to |
Attempt at capturing #85 Co-authored-by: Robert Norton <[email protected]>
As per CHERIoT-Platform/llvm-project#46 the current restrictions on return sentries cause difficulties for compiler outlining because it may use a non-standard link register. Currently
cjal
/cjalr
always produce a return sentry in the link register which can only be used to return viacret
(i.ecjalr
withcd == $cnull
andcs1 == $cra
).For reference here is the relevant table for
cjalr
from the ISA doc:We could relax the ISA to permit using a non-standard link register by modifying
cjal
/cjalr
wherecd
is not$cra
such that they produce either 1) an unsealed capability or 2) a forward interrupt-inheriting sentry in the link register. This would permit a return usingcjalr
withcd == $cnull
andcs1 != $cra
. Of these 1) is preferable as it does not introduce the ability to create forward sentries, which is not currently possible without a capability with the appropriate sealing permission. It is already possible to create unsealed capabilities derived from PCC.The text was updated successfully, but these errors were encountered: