Allowing delayed check for jump/branch instructions

[kliuMsft]

In the case of branch/jump instructions, would like to have the option to delay the PCC-based branch target checks (address bound/permission) to instruction fetch time (errors associated with the branch target instruction), rather than handling it at EX time (error associated with the branch/jump themselves).

The benefit is better performance (checking logic will not be in the critical instruction feth timing path, for example) and fewer changes to execution logic (espically branch instructions).

[rmn30]

I think I agree that delaying the bounds check until instruction fetch of the target PC makes sense, even though it potentially makes debugging harder. In many cases the link register will indicate the offending instruction, so hopefully this isn't too big a problem (certainly no worse the before CHERI!). The major exception to this is returns (cret) which will mostly target sealed capabilities. Can we keep the tagged and unsealed checks on the jump / branch? Other jumps / branches without link are likely to have immediate offsets which are much less likely to go out of bounds if linking and PCC are correct.

Note that removing the bounds check will also solve #18 .

[rmn30]

Note that @vmurali has in mind a JIT compiler / dynamic linker where trap at the destination may not be sufficient.

[kliuMsft]

@rmn30 for register-targeted jumps (jr/jalr) I don't see any issues with doing tag/unseal checks at EX time. The performance concerns are mostly with address bound checking. So we can,

• For c.JR/JALR, keep the tag/unsealed checking but defer address bound checking to fetching
• For all other PCC-based jump/branches (conditioanl branching and JAL), defer all checks to fetching

Does this sound right?

[vmurali]

One has to store the previous PC in case of taken branches/jumps in MEPCC (or have a different architectural register storing the previous PC) as suggested in #18, to make debugging simpler.

[vmurali]

I posted a comment on #18. Basically JALRs, JALs and Branches would now need a representability check :(.

[vmurali]

EDIT: I wrote a long comment with an alternative design, but realized that the alternative won't work. But I want to reiterate that we can't avoid checking for either bounds or representability for jumps/branches in execute.

[rmn30]

Closing due to #37 being merged.

[vmurali]

I am not sure how just clearing the tag bit in MEPCC is sufficient when a Branch/JAL/JALR target is unrepresentable (especially Branch and JAL). It could be unrepresentable in such a way that the bounds check with the new address would pass during instruction fetch.

If the tag for MEPCC is cleared, how would one recover from Instruction Bounds Violation exception? That is, when I run MRET after handling this exception (say by changing the address to point to the previous instruction which I just rewrite in the trap handler), how will it go back to that compartment/code block?

[vmurali]

If you really want to push all of Branch/JAL/JALR bound checks into fetch, the correct way to do it is to save the previous PCC in the case of Branch and JAL, and perform a bounds check based on the previous PCC; in case of JALR, save the target PCC in the previous PCC register and perform a bounds check based on that register.

And instead of complicating the behavior of MEPCC by clearing the tag, you can just store the previous PCC in a new SCR (MEPrevPCC). Write/Read legalization is orthogonal to this change (and I agree that clearing tag whenever legalization occurs is a simpler and sufficient design choice).

[davidchisnall]

I am not sure how just clearing the tag bit in MEPCC is sufficient when a Branch/JAL/JALR target is unrepresentable (especially Branch and JAL). It could be unrepresentable in such a way that the bounds check with the new address would pass during instruction fetch.

The bounds check will succeed, but the tag check will not.

If the tag for MEPCC is cleared, how would one recover from Instruction Bounds Violation exception? That is, when I run MRET after handling this exception (say by changing the address to point to the previous instruction which I just rewrite in the trap handler), how will it go back to that compartment/code block?

Currently, this kind of error will always invoke the error handler or force unwind. The error handler receives an untagged copy of the PCC (to preserve the control-flow-integrity properties of libraries and any secrecy that they enforce built atop those properties) and the switcher will rederive it form the compartment's PCC.

[rmn30]

There's an implicit assumption that the PCC bounds are stored expanded, so the representability issue only arises when we take the bounds exception on instruction fetch and need to construct something to put in MEPCC. In the Sail PC and PCC are separate and PCC never has its address set. The arch doc could make this clearer.

[rmn30]

The bounds check will succeed, but the tag check will not.

Not quite. It's still a bounds failure on instruction fetch. It's only MEPCC that has tag cleared.

[vmurali]

Currently, this kind of error will always invoke the error handler or force unwind. The error handler receives an untagged copy of the PCC (to preserve the control-flow-integrity properties of libraries and any secrecy that they enforce built atop those properties) and the switcher will rederive it form the compartment's PCC.

Okay, this looks fine.

There's an implicit assumption that the PCC bounds are stored expanded, so the representability issue only arises when we take the bounds exception on instruction fetch.

Can you clarify this in the ISA doc? Storing PCC bounds as expanded is part of the spec now. The spec should also state that JAL and Branch do not affect the expanded bounds/expanded meta cap data. It should only change the address. JALR should install a new expanded meta cap data.

[davidchisnall]

Storing PCC bounds as expanded is part of the spec now.

I think we need to be a bit careful here. I don’t want to require implementations to keep the bounds expanded, but I don’t mind if they need to act as if the bounds are expanded and handle PC-relative jumps that lead to unrepresentable values in a consistent and well-defined way.

[vmurali]

I think we need to be a bit careful here. I don’t want to require implementations to keep the bounds expanded, but I don’t mind if they need to act as if the bounds are expanded and handle PC-relative jumps that lead to unrepresentable values in a consistent and well-defined way.

If they are not stored expanded, the new PCC may not have any bearing to the previous PCC w.r.t. representability. A more complicated spec would be what I had outlined - compare the new PCC's address on JAL and Branch with the previous PCC's bounds. I believe both are equivalent (and storing the previous PCC in the spec is more complex in my opinion).