[pcre-dev] [Bug 2509] JIT should emit Control-flow Enforceme…

Top Page
Delete this message
Author: admin
Date:  
To: pcre-dev
Subject: [pcre-dev] [Bug 2509] JIT should emit Control-flow Enforcement Technology (CET) instructions
https://bugs.exim.org/show_bug.cgi?id=2509

--- Comment #5 from Zoltan Herczeg <hzmester@???> ---
> 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.