[PATCH v2] Don't run personality syscall at configure time; don't check it at all

[Simon Marchi]

On 2021-05-06 6:47 p.m., Pedro Alves wrote:
> v2: whoops, fixed commit log.
> 
> Currently, in order to tell whether support for disabling address
> space randomization on Linux is available, GDB checks if the
> personality syscall works, at configure time.  I.e., it does a run
> test, instead of a compile/link test:
> 
>   AC_RUN_IFELSE([PERSONALITY_TEST],
> 		[have_personality=true],
> 		[have_personality=false],
> 
> This is a bit bogus, because the machine the build is done on may not
> (and is when you consider distro gdbs) be the machine that eventually
> runs gdb.  It would be better if this were a compile/link test
> instead, and then at runtime, GDB coped with the personality syscall
> failing.  Actually, GDB already copes.
> 
> One environment where this is problematic is building GDB in a Docker
> container -- by default, Docker runs the container with seccomp, with
> a profile that disables the personality syscall.  You can tell Docker
> to use a less restricted seccomp profile, but I think we should just
> fix it in GDB.
> 
> "man 2 personality" says:
> 
>        This system call first appeared in Linux 1.1.20 (and thus first
>        in a stable kernel release with Linux 1.2.0); library support
>        was added in glibc 2.3.
> 
> ...
> 
>        ADDR_NO_RANDOMIZE (since Linux 2.6.12)
>               With this flag set, disable address-space-layout randomization.
> 
> glibc 2.3 was released in 2002.
> Linux 2.6.12 was released in 2005.
> 
> The original patch that added the configure checks was submitted in
> 2008.  The first version of the patch that was submitted to the list
> called personality from common code:
> 
>  https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html
> 
> and then was moved to Linux-specific code:
> 
>  https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html
> 
> Since HAVE_PERSONALITY is only checked in Linux code, and
> ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely
> removing the configure checks.
> 
> If for some odd reason, some remotely modern system still needs a
> configure check, then we can revert this commit but drop the
> AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE
> cross-compile fallback.
> 
> gdb/ChangeLog:
> 
> 	* linux-nat.c (linux_nat_target::supports_disable_randomization):
> 	Remove references to HAVE_PERSONALITY.
> 	* nat/linux-personality.c: Remove references to HAVE_PERSONALITY.
> 	(maybe_disable_address_space_randomization)
> 	(~maybe_disable_address_space_randomizatio): Remove references to
> 	HAVE_PERSONALITY.
> 	* config.in, configure: Regenerate.
> 
> gdbserver/ChangeLog:
> 
> 	* linux-low.cc: Remove references to HAVE_PERSONALITY.
> 	(linux_process_target::supports_disable_randomization): Remove
> 	reference to HAVE_PERSONALITY.
> 	* config.in, configure: Regenerate.
> 
> gdbsupport/ChangeLog:
> 
> 	* common.m4 (personality test): Remove.

Hi Pedro,

The patch LGTM.

However, I have some trouble re-generating gdb/configure, so I can't
verify that I get the same result as you, I'd like if we could quickly
fix that first.  With current master, I get:

    gdb/ $ autoreconf -vf
    autoreconf: Entering directory `.'
    autoreconf: configure.ac: not using Gettext
    autoreconf: running: aclocal --force 
    autoreconf: configure.ac: tracing
    autoreconf: configure.ac: adding subdirectory testsuite to autoreconf
    autoreconf: Entering directory `testsuite'
    autoreconf: configure.ac: not using aclocal
    autoreconf: configure.ac: subdirectory gdb.gdbtk not present
    autoreconf: configure.ac: not using Libtool
    autoreconf: running: /opt/autostuff/2.69/bin/autoconf --force
    autoreconf: configure.ac: not using Autoheader
    autoreconf: configure.ac: not using Automake
    autoreconf: Leaving directory `testsuite'
    autoreconf: configure.ac: subdirectory gdbtk not present
    configure.ac:161: error: possibly undefined macro: AC_MSG_ERROR
          If this token and others are legitimate, please use m4_pattern_allow.
          See the Autoconf documentation.
    configure.ac:329: error: possibly undefined macro: AC_MSG_WARN
    configure.ac:409: error: possibly undefined macro: AC_DEFINE
    autoreconf: /opt/autostuff/2.69/bin/autoconf failed with exit status: 1

This happens since commit adeab0c5b33f ("config/debuginfod: do not
include pkg.m4 directly").  The commit message hints that we should run
autoconf with -I ../config, and indeed it works:

    gdb/ $ autoreconf -vf -I ../config
    autoreconf: Entering directory `.'
    autoreconf: configure.ac: not using Gettext
    autoreconf: running: aclocal -I ../config --force 
    autoreconf: configure.ac: tracing
    autoreconf: configure.ac: adding subdirectory testsuite to autoreconf
    autoreconf: Entering directory `testsuite'
    autoreconf: configure.ac: not using aclocal
    autoreconf: configure.ac: subdirectory gdb.gdbtk not present
    autoreconf: configure.ac: not using Libtool
    autoreconf: running: /opt/autostuff/2.69/bin/autoconf --include=../config --force
    autoreconf: configure.ac: not using Autoheader
    autoreconf: configure.ac: not using Automake
    autoreconf: Leaving directory `testsuite'
    autoreconf: configure.ac: subdirectory gdbtk not present
    autoreconf: running: /opt/autostuff/2.69/bin/autoheader --include=../config --force
    autoreconf: Leaving directory `.'

However, I never needed to use -I ../config before, so I don't know why
it would be needed now (and we use plenty of other macros from config/).
Do we need to list ../config/pkg.m4 in our acinclude.m4?  Or, isn't
there a way in our configure.ac to say that we always want to include
../config?

Simon