https://bugs.exim.org/show_bug.cgi?id=2509
--- Comment #3 from Zoltan Herczeg <hzmes...@freemail.hu> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
