https://bugs.exim.org/show_bug.cgi?id=2509
--- Comment #6 from H.J. Lu <hjl.tools@???> ---
(In reply to Zoltan Herczeg from comment #5)
> > Yes, we should emit ENDBR64/ENDBR32 after all indirect branch targets.
> > Is there a way to tell that a label is an indirect branch target?
>
> A label is a label so there is no way to detect it. But I think if you emit
> this instruction after sljit_set_put_label(...) in pcre2_jit_compile.c it
> should work. There are four calls of this function in the code.
I will take a look.
> > Is there a way to tell how many stack frames will be skipped in JIT
> > return either when generating JIT return and when changing normal stack
> > for JIT return?
>
> I think the only thing you can tell is whether you need stack frame skipping
> or not. Normally you don't need it, but some exceptions triggers it. Please
> check the use of the following variables:
>
> struct sljit_label *abort_label;
> jump_list *abort;
> jump_list *calllimit;
I will take a look.
> I think some of their uses could be changed to use quit_label or quit
> jumplist, but I wasn't that strict about their usage in the past because I
> didn't need to worry about CET.
>
> How can we be sure that these shadow stack updates cannot be exploited by
> attackers? An indirect call from anywhere in the code to this code path
> could revert (hide) function calls done by attackers since it will nicely
> clean up the shadow stack for them.
Popping shadow stack is needed to unwind call stacks. If we don't know
how many stack frames are skipped, we need to pop shadow stack one at a
time. It is safe since shadow stack is read-only, you can only skip stack
frame, not jump to anywhere else.
> > We need a scratch register to adjust shadow stack. I don't know enough
> > about JIT to say which register can be used to adjust shadow stack. I
> > picked TMP_REG1 which happens to be ebp.
>
> I suspected such. Since it is a function return, all scratch registers are
> free to use except eax and edx since they hold the return value. I recommend
> to use ecx, because it is a scratch register in all ABIs I am aware of.
I will define ECX_REG to use it as scratch register when returning from JIT.
> > Tiger Lake
> >
> > https://en.wikipedia.org/wiki/Tiger_Lake_(microarchitecture)
> >
> > should be available later this year.
>
> This is great! Will you do the testing before each release (I might do
> speculative changes)?
Yes, I can.
--
You are receiving this mail because:
You are on the CC list for the bug.
