https://bugs.exim.org/show_bug.cgi?id=2509
--- Comment #3 from Zoltan Herczeg <hzmester@???> ---
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#caf6c627944ec1e09c784eaf2cfa4888a3dcc24f_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.
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.
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.
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?
--
You are receiving this mail because:
You are on the CC list for the bug.
