Re: [PATCH v2 4/5] x86/boot: use -fno-builtin-bcmp

From: Nick Desaulniers
Date: Wed Aug 19 2020 - 16:11:35 EST


On Wed, Aug 19, 2020 at 12:29 PM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote:
>
> On Wed, Aug 19, 2020 at 12:16:53PM -0700, Nick Desaulniers wrote:
> > We're reverting
> > commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
> > in favor of -fno-builtin-bcmp. Remove the additional definition here,
> > too.
> >
> > arch/x86/purgatory/Makefile uses -ffreestanding, so there's no risk of
> > this libcall optimization occurring for arch/x86/boot/purgatory.ro.
> >
> > arch/x86/boot/Makefile resets KBUILD_CFLAGS, so make sure to reset this
> > flag that was set for the top level Makefile.
> >
> > Fixes: 4ce97317f41d ("x86/purgatory: Do not use __builtin_memcpy and __builtin_memset")
> > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
> > ---
> > arch/x86/boot/Makefile | 1 +
> > arch/x86/boot/string.c | 8 --------
> > 2 files changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
> > index fe605205b4ce..ef7f15bfceab 100644
> > --- a/arch/x86/boot/Makefile
> > +++ b/arch/x86/boot/Makefile
> > @@ -70,6 +70,7 @@ KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP
> > KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
> > KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
> > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
> > +KBUILD_CFLAGS += -fno-builtin-bcmp
> > GCOV_PROFILE := n
> > UBSAN_SANITIZE := n
> >
>
> This should be unnecessary: KBUILD_CFLAGS in arch/x86/boot/Makefile is
> set to REALMODE_CFLAGS (defined in arch/x86/Makefile), which includes
> -ffreestanding.

I triple checked by grepping the disassemblies of
./arch/x86/purgatory/purgatory.ro, arch/x86/purgatory/*.o, and
arch/x86/boot/*.o for bcmp; should be fine to drop that hunk. Will
wait a bit to see if there's other feedback, and whether folks are on
board with the plan to merge the series proposed in the cover letter
or not.

--
Thanks,
~Nick Desaulniers