[PATCH] add support for -fcf-protection
Jakub Martisko
jamartis at redhat.com
Mon Jun 3 07:50:59 UTC 2019
Hi Niels,
thanks for the feedback, I'll be happy to send an updated version of the
patch, but there are some possible issues that I would like to address
first:
On Sat, Jun 01, 2019 at 10:08:33AM +0200, Niels Möller wrote:
> Jakub Martisko <jamartis at redhat.com> writes:
>
> > Hello,
> >
> > attached patch modifies the x86_64 assembly files, to support
> > -fcf-protection/intel CET [1,2] controls. Modifications are done via the
> > m4 macros, so it should be quite easy to modify the patch to use the
> > changes only conditionaly druing the compilation.
> > --- a/mpn/x86_64/coreibwl/addmul_1.asm
> > +++ b/mpn/x86_64/coreibwl/addmul_1.asm
> > @@ -107,33 +107,39 @@ L(tab): JMPENT( L(f0), L(tab))
> > JMPENT( L(f7), L(tab))
> > TEXT
> >
> > -L(f0): mulx( (up), %r10, %r8)
> > +L(f0): CFPROT_ENDBR
> > + mulx( (up), %r10, %r8)
>
> This looks a bit intrusive. Maybe better to split the L macro into two,
> one for code labels and one for data labels, and have the expansion of
> the former include an endbr instructin, when appropriate?
>
This might be a bit problematic with some files (e.g.
k8/mullo_basecase.asm) which contain "fall through" labels like:
L1:
L2:
L3: some_instruction
In this case you would have to:
a) add the ENDBR instruction to all 3 labels which to me seems a bit
suboptimal (even if the ENDBR would be treated just as nop, it's 2 extra
uselless instructions for L1)
b) use different macros for L1/L2 and L3, which at least to me, seems
even more intrusive, than the original approach
> > diff --git a/mpn/x86_64/coreihwl/mul_basecase.asm b/mpn/x86_64/coreihwl/mul_basecase.asm
> > index b2656c8..e4a8381 100644
> > --- a/mpn/x86_64/coreihwl/mul_basecase.asm
> > +++ b/mpn/x86_64/coreihwl/mul_basecase.asm
> > @@ -439,3 +439,4 @@ L(ret2):pop %rbp
> > FUNC_EXIT()
> > ret
> > EPILOGUE()
> > +CF_PROT
>
> Adn this should perhaps go into ASM_END. Not sure how consistently
> ASM_END is used, though. Another alternative is to use m4 divert to get the
> note added at the end of each assembly file.
>
Using ASM_END was my original plan, but as you mention, it is used very
rarely in the x86_64 sources, so I decided to use my own macro which has
the benefit of being a bit more stand alone.
As for the divert approach, how would that work with files like
atom/aors_n.asm? I am not really that familiar with m4 and the whole
macro expansion process, so correct me if I am wrong, but I assume that
this would lead to having two notes in this file (one from divert and one
from the include).
> Regards,
> /Niels
>
Thank you,
Jakub
> --
> Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
> Internet email is subject to wholesale government surveillance.
More information about the gmp-devel
mailing list