https://bugs.exim.org/show_bug.cgi?id=2509
--- Comment #5 from Zoltan Herczeg <[email protected]> --- > 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. > 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 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. > 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. > 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)? -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
