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