[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