https://bugs.exim.org/show_bug.cgi?id=2509
--- Comment #9 from H.J. Lu <hjl.tools@???> ---
(In reply to Zoltan Herczeg from comment #8)
> - I would not add a new function (sljit_emit_ijump_target_start) to emit
> ENDBR instructions, I would add a new constant to sljit_emit_op0:
>
> https://github.com/zherczeg/sljit/blob/master/sljit_src/sljitLir.h#L844
Will do.
> The other cpus should emit no instruction when this constant is passed.
> Furthermore, if we want to add this to the sljit project, we need to make
> its tests compatible with it as well.
>
> https://github.com/zherczeg/sljit/blob/master/test_src/sljitTest.c
Will do.
> - If I understand correctly, we don't need the ebp specific changes anymore.
Yes.
> - I would like to understand the shadow stack a bit more. Isn't it dangerous
> to update the return address all the time? For example, how should it
> prevent the following attack in theory:
>
> Somebody overwrites the callout function of a pattern in memory, and
> indirectly call this function using a custom pattern. Then he destroys the
> stack with random values, because he knows that if he jumps back the
> compiled pattern, it will restore the shadow stack for him. Can this be
> prevented at all? Normal functions generated by GCC has such cleanup code as
> well?
Shadow stack is a read-only stack parallel to normal stack. It contains
just return addresses. "RET" checks the return address against the value
at the top of shadow stack. If they don't match, you get a CP fault.
You can destroy stack and pop shadow stack. But you can only jump back to
callers of the JIT code. The key is you can't restore shadow stack. You
can only pop shadow stack.
> How does CET affect fast calls?
> https://github.com/zherczeg/sljit/blob/master/sljit_src/sljitLir.h#L681
If I understand it correctly, when you enter the fast call, you pop the
return address from stack. Now top of shadow stack differs from the
return address on stack. When you return from the fast call, you push
the return address onto stack. Now top of shadow stack matches the return
address of stack. But when exception happens during the fast call, you
don't push the return address onto stack and you get a shadow stack
mismatch on RET. My change pops shadow stack until top of shadow stack
matches the return address of stack.
--
You are receiving this mail because:
You are on the CC list for the bug.
