Re: [Xen-devel] tools/fuzz fails due build, osstest did not notice

[Christopher Clark <christopher.w.clark@xxxxxxxxx>]

On Tue, Sep 4, 2018 at 2:07 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>
> >>> On 04.09.18 at 09:32, <olaf@xxxxxxxxx> wrote:
> > Am Mon, 03 Sep 2018 06:35:42 -0600
> > schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:
> >
> >> what is the actual problem? The mere
> >> listing of compiler flags passed does not make clear to me where the clash
> >> is, or how it would surface.
> >
> > As I noticed just now, it fails to build only in Tumbleweed. So in this
> > specific case osstest would have caught it only in a few years from now.
> >
> > [   38s] make -C x86_instruction_emulator install
> > [   38s] make[6]: Entering directory
> > '/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> > s/fuzz/x86_instruction_emulator'
> > [   38s] [ -L x86-emulate.h ] || ln -sf
> > /home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tools
> > /fuzz/x86_instruction_emulator/../../../tools/tests/x86_emulator/x86-emulate.h
> > [   38s] [ -L x86_emulate ] || ln -sf
> > /home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tools
> > /fuzz/x86_instruction_emulator/../../../xen/arch/x86/x86_emulate
> > [   38s] /usr/bin/gcc  -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall
> > -Wstrict-prototypes -Wdeclaration-after-statement 
> > -Wno-unused-but-set-variable
> > -Wno-unused-local-typedefs   -O0 -fno-omit-frame-pointer
> > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> > .fuzz-emul.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -O2 -Wall
> > -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
> > -fasynchronous-unwind-tables -fstack-clash-protection
> > -I/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> > s/fuzz/x86_instruction_emulator/../../../tools/include -D__XEN_TOOLS__ -I.  
> > -c -o
> > fuzz-emul.o fuzz-emul.c
> > [   38s] In file included from /usr/include/features.h:428,
> > [   38s]                  from /usr/include/assert.h:35,
> > [   38s]                  from fuzz-emul.c:1:
> > [   38s] fuzz-emul.c: In function 'input_read':
> > [   38s] /usr/include/bits/string_fortified.h:31:1: error: inlining failed
> > in call to always_inline 'memcpy': target specific option mismatch
> > [   38s]  __NTH (memcpy (void *__restrict __dest, const void *__restrict
> > __src,
> > [   38s]  ^~~~~
> > [   38s] fuzz-emul.c:67:5: note: called from here
> > [   38s]      memcpy(dst, &s->corpus->data[s->data_index], size);
> > [   38s]      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > [   38s] In file included from /usr/include/features.h:428,
> > [   38s]                  from /usr/include/assert.h:35,
> > [   38s]                  from fuzz-emul.c:1:
> > [   38s] /usr/include/bits/string_fortified.h:31:1: error: inlining failed
> > in call to always_inline 'memcpy': target specific option mismatch
> > [   38s]  __NTH (memcpy (void *__restrict __dest, const void *__restrict
> > __src,
> > [   38s]  ^~~~~
> > [   38s] fuzz-emul.c:67:5: note: called from here
> > [   38s]      memcpy(dst, &s->corpus->data[s->data_index], size);
> > [   38s]      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > [   38s] make[6]: ***
> > [/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> > s/fuzz/x86_instruction_emulator/../../../tools/Rules.mk:225: fuzz-emul.o]
> > Error 1
> >
> > Appending -U_FORTIFY_SOURCE in tools/fuzz fixes it. Not sure why fuzz is
> > different from the rest of tools.
>
> No idea here either, for the moment, even after looking at gcc's
> ix86_can_inline_p() (which apparently is the function triggering the
> diagnostic).

I've just encountered this problem, building with the master branch of
OpenEmbedded and Yocto's poky, with compiler flags that include
    _FORTIFY_SOURCE=2 -msse3
with gcc 8.2.0.

Xen's x86_emulator header file does:
    #pragma GCC target("no-sse")

The pragma was introduced in Xen commit 79136f26, to prevent the compiler from
using registers otherwise used by inline memset and memcpy.

Setting _FORTIFY_SOURCE causes the use of always_inline variants of memset and
memcpy which use those instructions, which is now causing the inline to fail.

The behaviour is described in the GCC bugzilla here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71991

{quote}
    cat fuzz-emul.i
    __attribute__((__always_inline__)) a() {}
    #pragma GCC target "no-sse"
    b() { a(); }

    Where 'a' is 'memcpy' and 'b' is a function in xen.

    Can you Honza also take a look r251333 where we started to reject such code?
{quote}

links to this GCC change:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=251333

Would the below Xen patch, which adds undefs for _FORTIFY_SOURCE just for the
two binaries which are affected be acceptable? It allows for use of
_FORTIFY_SOURCE with the rest of the build.

Christopher

diff --git a/tools/tests/x86_emulator/Makefile
b/tools/tests/x86_emulator/Makefile
index dec81c3..f7b9e58 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -133,7 +133,7 @@ x86_emulate/%: x86_emulate ;

 HOSTCFLAGS-x86_64 := -fno-PIE
 $(call cc-option-add,HOSTCFLAGS-x86_64,HOSTCC,-no-pie)
-HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
+HOSTCFLAGS += $(CFLAGS_xeninclude) -I.
$(HOSTCFLAGS-$(XEN_COMPILE_ARCH)) -U_FORTIFY_SOURCE

 x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
                      x86-vendors.h x86-defns.h msr-index.h)
diff --git a/tools/fuzz/x86_instruction_emulator/Makefile
b/tools/fuzz/x86_instruction_emulator/Makefile
index eb88f94..83e5633 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -16,7 +16,7 @@ x86_emulate/%: x86_emulate ;
 x86-emulate.c x86-emulate.h wrappers.c: %:
    [ -L $* ] || ln -sf $(XEN_ROOT)/tools/tests/x86_emulator/$*

-CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -I.
+CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -I. -U_FORTIFY_SOURCE

 GCOV_FLAGS := --coverage
 %-cov.o: %.c

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel