Proposed relaxing of cjalr sealing

[nwf]

Attempt at capturing #85

[rmn30]

You need to make a similar change in CJAL.

[rmn30]

Looks fine except for comments. I may slightly prefer inverting the if so that the common cd==ra case is handled first but it does not matter.

[vmurali]

Lgtm. As Robert pointed out, can you fix the commentary in the JAL case

[nwf]

Copy-paste errors fixed, conditions flipped, and archdoc prose updated to explain the changes.

[vmurali]

Is there a security issue if cjal links an unsealed cap even for link register of cra? That means cjr cra should be relaxed to allow unsealed caps in cra. I don't see a problem with that though - if it's sealed, it has to be a backwards sentry, and if it's unsealed, I can jump anywhere with it.

[rmn30]

Is there a security issue if cjal links an unsealed cap even for link register of cra? That means cjr cra should be relaxed to allow unsealed caps in cra. I don't see a problem with that though - if it's sealed, it has to be a backwards sentry, and if it's unsealed, I can jump anywhere with it.

I think it would be fine in that the interrupt disabling DoS attack that pushed us to add return sentries would still be mitigated (because you have to use cra as link when jumping to an interrupt disabling sentry), but it is a weakening of the "psuedo-CFI" we have now and isn't necessary to support non-standard link register as desired.

Specifically, most code will use cret to return and relaxing this to accept unsealed caps would allow an attacker more scope to substitute other capabilities in ROP attacks. This may not be a great risk given we have bounds checking and unforgeable capabilities but if we don't need to then why do it?

[vmurali]

Specifically, most code will use cret to return and relaxing this to accept unsealed caps would allow an attacker more scope to substitute other capabilities in ROP attack. This may not be a great risk given we have bounds checking and unforgeable capabilities

My rationale is that when cra is linked with cjal instead of cjalr, you are within your own code that you could have done the ROP anyway, hence not increasing the attack surface.

but if we don't need to then why do it?

Slight hardware simplification and in line with the design principle that if you want protection of the caller, use cjalr cra

[rmn30]

My rationale is that when cra is linked with cjal instead of cjalr, you are within your own code that you could have done the ROP anyway, hence not increasing the attack surface.

But ROP is a code reuse attack which uses the victims own code against them. I agree that we need to articulate the threat model more clearly: it's difficult to imagine a scenario on CHERIoT where this would make a difference. I think it would be something like: the attacker finds a vulnerability that allows them to store a capability at an arbitrary offset in the victim's stack. They use this to overwrite the victim's return address with a capability of their choosing. If cret requires a return sentry this limits the attacker's choice of destination to those for which they can obtain a return sentry. This may seem far-fetched but attackers do tend to find a way if you let them, and I don't see a compelling reason to allow it.

Slight hardware simplification and in line with the design principle that if you want protection of the caller, use cjalr cra

I don't think it simplifies hardware to make return address generation different between cjal and cjalr. If they are the same then the hardware can be shared between them, though I defer to @kliuMsft .

[vmurali]

But ROP is a code reuse attack which uses the victims own code against them.

the attacker finds a vulnerability that allows them to store a capability at an arbitrary offset in the victim's stack. They use this to overwrite the victim's return address with a capability of their choosing. If cret requires a return sentry this limits the attacker's choice of destination to those for which they can obtain a return sentry.

If they are all in the same PCC, you are not gaining much.

The invariant I am maintaining is, the return is protected only if the call is. cjal creates an unprotected call (i.e. it can jump to anywhere in the code), so the return can also jump to anywhere in the code.

But I agree it's not necessary to weaken things.

[rmn30]

It might be clearer to have another column for the output otype or maybe even a separate (smaller) table? We should make clear that the same behaviour applies to cjal.

[rmn30]

Suggested change

	In this case, the \insnriscvref{CJALR} used to enter the outlined code
	In this case, the \insnriscvref{CJAL} or \insnriscvref{CJALR} used to enter the outlined code

[rmn30]

Looks fine. Suggested clarifications in arch doc optional.