Yes absolutely, CSE needs to be avoided. I made memory access volatile because the change was easier to do. Also on Arm Thumb-1 computing the guard's address itself takes several loads so had to modify some more patterns. Anyway, regardless of the proper fix, do you have any objection to raising a CVE for that issue?
Best regards, Thomas On 27 April 2018 at 14:38, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Apr 27, 2018 at 02:31:25PM +0100, Thomas Preudhomme wrote: > > On x86 yes, it's actually done in the same instruction that's doing the > > comparison if I'm not mistaken. That is not the case for arm and aarch64 > > though where loading the canari is done separately from the comparison > and > > does not involve an offset. Computing the address from which to do the > load > > is yet again done in a separate instruction. Since these are extra > > instructions and the address of the canari does not change between the > > prologue and epilogue, CSE is done on the address (only on arm backend > > though) and due to register pressure the address is spilled on the stack. > > So just add some UNSPEC around to prevent the CSE (with different number on > the prologue and epilogue load, so that the two are considered > different). Even > when it isn't spilled in the current function, it might be saved and > restored in > function's it calls and again, an attacker could modify it there. > > Jakub >
