https://bugs.exim.org/show_bug.cgi?id=2509
--- Comment #4 from H.J. Lu <hjl.tools@???> ---
(In reply to Zoltan Herczeg from comment #3)
> Thank you for the patch. I would like to understand it a bit more deeply, so
> I have some questions about it.
>
> 1)
> https://gitlab.com/cet-software/pcre2/commit/
> b97bfe2be77ff7cb9f9c8a697d92d3038e8edee1#caf6c627944ec1e09c784eaf2cfa4888a3dc
> c24f_2537_2686
>
> If I understand correctly, a prefix is emitted before the jump instruction
> which effectively disables the CET protection and this could be exploited by
> attackers. Shouldn't we emit ENDBR64/ENDBR32 after the indirect branch
> targets instead of this prefix? Perhaps we could create a new op0
> instruction for this purpose (emits nothing if no such protection is needed)
> or emit the instruction bytes directly by sljit_emit_op_custom. PCRE-JIT
> uses as few indirect branches as possible, because it is hard to predict
> them by the CPU.
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?
> 2) It seems the patch performs a "shadow stack adjustment" before each
> return. Isn't this unsafe as well? Shouldn't we only do this in case of
> exceptions? As for JIT, callouts returned with negative value or match limit
> reaches are those types of exceptions.
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?
> 3) The patch seems to fix the invalid code generation for ebp. That is
> intentional because we only use ebp to store temporary values, and never as
> base register. If ebp is only used at function return, perhaps we could use
> some scratch registers such as ecx instead of ebp.
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.
> 3) There are some maintenance questions as well. How can we test the code
> before a release? Do we need an emulated environment? The first comment
> mentioned that no hardware implements CET, but is it planned in the close
> future?
Tiger Lake
https://en.wikipedia.org/wiki/Tiger_Lake_(microarchitecture)
should be available later this year.
--
You are receiving this mail because:
You are on the CC list for the bug.
