Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 672918 - sys-apps/sandbox segfaults in sb_check_exec() for programs compiled with sys-devel/clang-7.0.1, >=sys-libs/glibc-2.28, -fuse-ld=lld and -Wl,--hash-style=gnu
Summary: sys-apps/sandbox segfaults in sb_check_exec() for programs compiled with sys-...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sandbox Maintainers
URL:
Whiteboard:
Keywords: PATCH
: 640174 677210 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-12-11 09:50 UTC by Dennis Schridde
Modified: 2021-10-22 04:26 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,43.47 KB, text/plain)
2018-12-11 09:50 UTC, Dennis Schridde
Details
config.log (config.log,149.79 KB, text/plain)
2018-12-14 13:48 UTC, Dennis Schridde
Details
diff -u conftest-mwe.clang.readelf conftest-mwe.gcc.readelf (conftest-mwe.readelf.diff,19.86 KB, patch)
2018-12-29 21:24 UTC, Dennis Schridde
Details | Diff
readelf -a conftest-mwe.clang (conftest-mwe.clang.readelf,14.56 KB, text/plain)
2018-12-29 21:25 UTC, Dennis Schridde
Details
readelf -a conftest-mwe.gcc (conftest-mwe.gcc.readelf,8.50 KB, text/plain)
2018-12-29 21:25 UTC, Dennis Schridde
Details
sandbox-2.14-fix-parse-elf.patch (sandbox-2.14-fix-parse-elf.patch,657 bytes, patch)
2018-12-29 21:27 UTC, Dennis Schridde
Details | Diff
sandbox-2.14-fix-parse-elf.patch (sandbox-2.14-fix-parse-elf.patch,816 bytes, patch)
2018-12-29 21:29 UTC, Dennis Schridde
Details | Diff
readelf -a build-script-build (build-script-build.readelf,224.21 KB, text/plain)
2018-12-29 22:26 UTC, Dennis Schridde
Details
sandbox-2.14-fix-parse-elf.patch (0001-Fix-a-segfault-in-PARSE_ELF-on-binaries-generated-by.patch,1.36 KB, patch)
2018-12-29 22:48 UTC, Dennis Schridde
Details | Diff
0001-exec-wrapper-add-support-for-GNU_HASH-parser.patch (0001-exec-wrapper-add-support-for-GNU_HASH-parser.patch,7.53 KB, patch)
2019-03-02 19:39 UTC, Sergei Trofimovich (RETIRED)
Details | Diff
trivial prebuilt binary (bug-672918.tar.xz,1.89 KB, application/x-xz)
2019-03-07 00:11 UTC, Andreas K. Hüttel
Details
0002-configure.ac-add-lld-detection-support.patch (0002-configure.ac-add-lld-detection-support.patch,1.54 KB, patch)
2019-03-07 23:48 UTC, Sergei Trofimovich (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Schridde 2018-12-11 09:50:27 UTC
Created attachment 557560 [details]
build.log

0:27.79 checking for sqlite3 >= 3.25.1... yes
 0:27.79 checking SQLITE_CFLAGS...
 0:27.80 checking SQLITE_LIBS... -lsqlite3                         
 0:28.19 checking for SQLITE_SECURE_DELETE support in system SQLite... no
 0:28.19 configure: error: System SQLite library is not compiled with SQLITE_SECURE_DELETE.
 0:28.22 DEBUG: <truncated - see config.log for full output>
 0:28.22 DEBUG: /usr/include/features.h:381:4: warning: _FORTIFY_SOURCE requires compiling with optimization (-O) [-W#warnings]
 0:28.22 DEBUG: #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
 0:28.22 DEBUG:    ^    
 0:28.22 DEBUG: 1 warning generated.                              
 0:28.22 DEBUG: configure:12010: checking for wget
 0:28.22 DEBUG: configure:12311: checking for sqlite3 >= 3.25.1
 0:28.22 DEBUG: configure:12318: checking SQLITE_CFLAGS                                        
 0:28.22 DEBUG: configure:12323: checking SQLITE_LIBS                                         
 0:28.22 DEBUG: configure:12354: checking for SQLITE_SECURE_DELETE support in system SQLite    
 0:28.22 DEBUG: configure:12377: /usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -o conftest -pipe -march=znver1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread  -Qunused-arguments  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -lpthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-rpa
th=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc conftest.c -ldl  -lsqlite3 1>&5
 0:28.22 DEBUG: configure: failed program was:               
 0:28.22 DEBUG: #line 12368 "configure"
 0:28.22 DEBUG: #include "confdefs.h"       
 0:28.22 DEBUG:
 0:28.22 DEBUG:             #include "sqlite3.h"
 0:28.22 DEBUG:
 0:28.22 DEBUG:             int main(int argc, char **argv){
 0:28.22 DEBUG:               return !sqlite3_compileoption_used("SQLITE_SECURE_DELETE");
 0:28.22 DEBUG:             }
 0:28.23 DEBUG: configure: error: System SQLite library is not compiled with SQLITE_SECURE_DELETE.
 0:28.23 ERROR: old-configure failed
Comment 1 Dennis Schridde 2018-12-11 09:51:55 UTC
Portage 2.3.52 (python 2.7.13-final-42, default/linux/amd64/17.1/desktop/plasma/systemd, gcc-8.2.0, glibc-2.28-r2, 4.19.6-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.19.6-gentoo-x86_64-AMD_Ryzen_5_2400G_with_Radeon_Vega_Graphics-with-gentoo-2.6
KiB Mem:    15191044 total,    692176 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Tue, 11 Dec 2018 08:45:01 +0000
Head commit of repository gentoo: 7bbd4434026212ff0f98a1b130745948ddab3438
Head commit of repository flatpak-overlay: aa2e187b97bb33ff8839e5abc2636af1e1db9a6f

Timestamp of repository gnome: Mon, 10 Dec 2018 22:11:23 +0000
Head commit of repository gnome: 00842d9b6c093b7a77a406237eee45511e75fad6

Timestamp of repository steam-overlay: Mon, 03 Dec 2018 21:43:54 +0000
Head commit of repository steam-overlay: 512103e56aef51f78b7bc89734b942ca706cd224

Head commit of repository local: f30fcb840c5e5a15fc69b39cffce758e3735ceb7

sh bash 4.4_p23
ld GNU ld (Gentoo 2.31.1 p4) 2.31.1
ccache version 3.5 [disabled]
app-shells/bash:          4.4_p23::gentoo
dev-java/java-config:     2.2.0-r4::gentoo
dev-lang/perl:            5.26.2::gentoo
dev-lang/python:          2.7.15::gentoo, 3.6.6::gentoo, 3.7.0::gentoo
dev-util/ccache:          3.5-r1::gentoo
dev-util/cmake:           3.13.1::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/sandbox:         2.14::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo
sys-devel/binutils:       2.31.1-r2::gentoo
sys-devel/gcc:            8.2.0-r5::gentoo
sys-devel/gcc-config:     2.0::gentoo
sys-devel/libtool:        2.4.6-r5::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers)
sys-libs/glibc:           2.28-r2::gentoo
Repositories:

gentoo
    location: /var/cache/portage/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.de.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-extra-opts: 
    sync-rsync-verify-jobs: 1
    sync-rsync-verify-max-age: 24
    sync-rsync-verify-metamanifest: yes

flatpak-overlay
    location: /var/db/repos/flatpak-overlay
    sync-type: git
    sync-uri: https://github.com/fosero/flatpak-overlay.git
    masters: gentoo

gnome
    location: /var/db/repos/gnome
    sync-type: git
    sync-uri: https://github.com/gentoo-mirror/gnome.git
    masters: gentoo

steam-overlay
    location: /var/db/repos/steam-overlay
    sync-type: git
    sync-uri: https://github.com/gentoo-mirror/steam-overlay.git
    masters: gentoo

local
    location: /var/cache/portage/local
    sync-type: git
    sync-uri: https://github.com/devurandom/gentoo-overlay.git
    masters: gentoo gnome
    priority: 1000

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-pipe -O2 -march=znver1"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /etc/grs/systems.conf /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.5/conf"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.2/ext-active/ /etc/php/cgi-php7.2/ext-active/ /etc/php/cli-php7.2/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-pipe -O2 -march=znver1"
DISTDIR="/var/cache/portage/distfiles"
EMERGE_DEFAULT_OPTS="--keep-going --nospinner --verbose-conflicts"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildsyspkg cgroup compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_GB.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu"
MAKEOPTS="-j6 -l4"
PKGDIR="/var/cache/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/tmp"
USE="X a52 aac aacplus aacs acl acpi activities aio alsa amd64 appindicator appstream archive audit avahi ayatana bash-completion bdplus berkdb bluetooth bluray branding brotli bs2b btrfs bzip2 cairo caps cdda cddb cdio cdr celt chromaprint cjk clang cli colord colorio conntrack crypt cups cxx d3d9 dbus declarative device-mapper dirac djvu dri drm dts dvb dvd dvdr editorconfig egl elf emboss encode epub exif fam fax fbcon ffmpeg fftw filecaps firefox firewalld fish-completion fits flac fontconfig fontforge fortran fribidi gbm gdbm geoclue geolocation gif git glamor gles gmp google googledrive gpg gps graphicsmagick gstreamer gtk gtk3 gzip harfbuzz hdf5 heif http2 ibus iconv icu idn imlib inotify introspection ipv6 jemalloc jpeg jpeg2k json kde kipi kms kwallet ladspa latex lcms ldap libatomic libidn2 libinput libnotify libproxy libsecret libsoxr libtirpc libvirt lm_sensors lv2 lvm lz4 lzma lzo mad markdown mbim mercurial metis mjpeg mng mobi modemmanager modplug mp3 mp4 mpeg mplayer mpris mtp multilib mysql ncurses netlink networkmanager nls nptl office ogg openal opencl opencv openexr opengl openh264 openmax openmp opus pam pango pcap pch pcre pcre2 pdf pgo phonon pixman plasma png policykit postscript ppds prison pulseaudio python qml qt5 raw readline redfish samba sasl scanner schroedinger sctp sdl sdl2 seccomp semantic-desktop share snappy sparse speech speex spell ssl startup-notification steamruntime stemmer svg systemd tbb tcpd teamd telepathy tga theora threads tiff timezone truetype tslib udev udisks unicode unwind upnp upnp-av upower usb utempter v4l v4l2 vaapi vdpau vkd3d vorbis vpx vulkan wasm wavpack wayland webchannel webengine webkit webp widgets wmf wps x264 x265 xattr xcb xcomposite xinerama xkb xml xmp xrandr xscreensaver xv xvid xwayland xz yaml zeroconf zeromq zlib zstd" ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon plan sheets stage words" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" ELIBC="glibc" ENLIGHTENMENT_MODULES="*" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="joystick libinput" KERNEL="linux" L10N="de de-DE en en-GB ar fa tr ja ko zh zh-CN zh-TW" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LIRC_DEVICES="devinput" LLVM_TARGETS="AMDGPU BPF" LUA_TARGET="lua5-2" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6 pypy pypy3" QEMU_SOFTMMU_TARGETS="riscv32 riscv64 x86_64" QEMU_USER_TARGETS="riscv32 riscv64" RUBY_TARGETS="ruby23 ruby24" STEAMGAMES="dirt_rally dont_starve portal source_engine te120 trine2 witcher2" USERLAND="GNU" VIDEO_CARDS="amdgpu virgl" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

=================================================================
                        Package Settings
=================================================================

www-client/firefox-63.0.3::gentoo was built with the following:
USE="clang dbus geckodriver gmp-autoupdate hwaccel lto pulseaudio screenshot startup-notification system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-sqlite wifi -bindist -custom-cflags -custom-optimization -debug -eme-free -hardened -jack (-neon) (-selinux) -test" ABI_X86="(64)" L10N="ar de en-GB fa ja ko tr zh-CN zh-TW -ach -af -an -as -ast -az -bg -bn-BD -bn-IN -br -bs -ca -cak -cs -cy -da -dsb -el -en-ZA -eo -es-AR -es-CL -es-ES -es-MX -et -eu -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -id -is -it -ka -kab -kk -km -kn -lij -lt -lv -mai -mk -ml -mr -ms -nb -nl -nn -or -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -uk -uz -vi -xh"
CFLAGS="-pipe -march=znver1"
CXXFLAGS="-pipe -march=znver1"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags"


dev-db/sqlite-3.25.3::gentoo was built with the following:
USE="icu readline secure-delete -debug -doc -static-libs -tcl -test -tools" ABI_X86="32 (64) (-x32)"
Comment 2 Dennis Schridde 2018-12-11 10:02:50 UTC
(In reply to Dennis Schridde from comment #1)
> dev-db/sqlite-3.25.3::gentoo was built with the following:
> USE="icu readline secure-delete -debug -doc -static-libs -tcl -test -tools"

Please note that according to USE-flags sqlite *was* build with secure-delete.
Comment 3 Arfrever Frehtes Taifersar Arahesis 2018-12-11 10:32:55 UTC
Please show:

$ gcc -o test -x c - <<< $'#include "sqlite3.h"\nint main(){return !sqlite3_compileoption_used("SQLITE_SECURE_DELETE");}' -lsqlite3
$ ./test ; echo $?
Comment 4 Dennis Schridde 2018-12-11 10:49:14 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #3)
> Please show:
> 
> $ gcc -o test -x c - <<< $'#include "sqlite3.h"\nint main(){return
> !sqlite3_compileoption_used("SQLITE_SECURE_DELETE");}' -lsqlite3
> $ ./test ; echo $?

$ gcc -o test-sqlite-secure-delete -x c - <<< $'#include "sqlite3.h"\nint main(){return !sqlite3_compileoption_used("SQLITE_SECURE_DELETE");}' -lsqlite3
$ ./test-sqlite-secure-delete ; echo $?
0
Comment 5 Thomas Deutschmann (RETIRED) gentoo-dev 2018-12-11 11:02:17 UTC
Cannot reproduce here.
Comment 6 Dennis Schridde 2018-12-11 20:43:02 UTC
(In reply to Thomas Deutschmann from comment #5)
> Cannot reproduce here.

# cat test.c
 #include "sqlite3.h"
  int main(int argc, char **argv){
           return !sqlite3_compileoption_used("SQLITE_SECURE_DELETE");
            }

# /usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -o conftest -pipe -march=znver1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread  -Qunused-arguments  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -lpthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc test.c -ldl  -lsqlite3

# ./conftest ; echo $?
0

Any idea how I can debug this further?
Comment 7 Thomas Deutschmann (RETIRED) gentoo-dev 2018-12-12 22:47:08 UTC
I see you have ABI="32 64" enabled for sqlite. Try emerging dev-db/sqlite without multilib, e.g. only for you native ABI. Maybe Firefox is using wrong libs...
Comment 8 Arfrever Frehtes Taifersar Arahesis 2018-12-12 23:22:23 UTC
dev-db/sqlite ebuilds do not build non-native-ABI libsqlite3 library in any less featureful way than native-ABI libsqlite3 library.
Comment 9 Ian Stakenvicius (RETIRED) gentoo-dev 2018-12-13 17:29:43 UTC
This is a head-scratcher.  Your system sqlite has secure-delete , confirmed by both your use flags as well as the compile-test.  Why firefox's configure test (which is exactly the same) is NOT deciding you have it, is unknown.

There definitely isn't another copy of sqlite on your system someplace (/usr/local/lib or anywhere else) that firefox's configure might be picking up, right?  It SHOULDNT be using libsqlite3 outside of LDPATH, but...
Comment 10 Dennis Schridde 2018-12-13 18:50:34 UTC
(In reply to Ian Stakenvicius from comment #9)
> This is a head-scratcher.  Your system sqlite has secure-delete , confirmed
> by both your use flags as well as the compile-test.  Why firefox's configure
> test (which is exactly the same) is NOT deciding you have it, is unknown.
> 
> There definitely isn't another copy of sqlite on your system someplace
> (/usr/local/lib or anywhere else) that firefox's configure might be picking
> up, right?  It SHOULDNT be using libsqlite3 outside of LDPATH, but...

# locate libsqlite | grep -v '^/snapshots' | grep -v '^/home' | grep -v '^/var/lib/flatpak'
/usr/lib/libsqlite3.so
/usr/lib/libsqlite3.so.0
/usr/lib/libsqlite3.so.0.8.6
/usr/lib64/libsqlite3.so
/usr/lib64/libsqlite3.so.0
/usr/lib64/libsqlite3.so.0.8.6

Do you have an idea where I might find that `conftest` binary Firefox's configure is building?  Maybe I can figure something out by inspecting that.  And are we sure the binary returns a non-zero exit code, or could it also be that building it fails for some reason?  config.log is so empty from clues that I have no idea where to start searching...
Comment 11 Ian Stakenvicius (RETIRED) gentoo-dev 2018-12-13 19:08:23 UTC
'conftest' is compiled and run for every single check that ./configure does.  You can see the code that is compiled and then run in your first comment.

The code was (saved to 'conftest.c'):

  #include "confdefs.h"       
  #include "sqlite3.h"

  int main(int argc, char **argv){
    return !sqlite3_compileoption_used("SQLITE_SECURE_DELETE");
  }


And it was compiled with:

/usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -o conftest -pipe -march=znver1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread  -Qunused-arguments  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -lpthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc conftest.c -ldl  -lsqlite3 conftest.c
Comment 12 Ian Stakenvicius (RETIRED) gentoo-dev 2018-12-13 19:09:21 UTC
(In reply to Ian Stakenvicius from comment #11)
> /usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -o conftest -pipe
> -march=znver1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing
> -ffunction-sections -fdata-sections -fno-math-errno -pthread 
> -Qunused-arguments  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -lpthread -Wl,-O1
> -Wl,--as-needed -Wl,--hash-style=gnu
> -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld
> -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc conftest.c
> -ldl  -lsqlite3 


Maybe this is a clang issue -- can you try Arfrever's test but using clang (with a subset of the above flags) and see if it returns zero?
Comment 13 Arfrever Frehtes Taifersar Arahesis 2018-12-13 23:10:44 UTC
Please attach config.log.
You can also add some debugging code in old-configure file...
Comment 14 Dennis Schridde 2018-12-14 13:48:04 UTC
Created attachment 557770 [details]
config.log
Comment 15 Dennis Schridde 2018-12-14 13:50:33 UTC
(In reply to Ian Stakenvicius from comment #12)
> (In reply to Ian Stakenvicius from comment #11)
> > /usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -o conftest -pipe
> > -march=znver1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing
> > -ffunction-sections -fdata-sections -fno-math-errno -pthread 
> > -Qunused-arguments  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -lpthread -Wl,-O1
> > -Wl,--as-needed -Wl,--hash-style=gnu
> > -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld
> > -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc conftest.c
> > -ldl  -lsqlite3 
> 
> 
> Maybe this is a clang issue -- can you try Arfrever's test but using clang
> (with a subset of the above flags) and see if it returns zero?

You mean like in comment #6?
Comment 16 Dennis Schridde 2018-12-16 22:10:23 UTC
I patched away `2> /dev/null` in the line executing conftest:
  sed -i -e '/configure:12401:/s,2>/dev/null,,' old-configure || die

This revealed:
  0:26.92 checking for SQLITE_SECURE_DELETE support in system SQLite... /var/tmp/portage/www-client/firefox-64.0/work/firefox-64.0/old-configure: line 12658: 15392 Segmentation fault      (core dumped) ./conftest

Kernel logs say:
Dec 16 23:05:14 ernie kernel: sh[14731]: segfault at 7f3e32d33e29 ip 00007f3e29d269e3 sp 00007ffcb57778d0 error 4 in libsandbox.so[7f3e29d22000+c000]

Systemd adds:
                                               Stack trace of thread 14731:
                                               #0  0x00007f3e29d269e3 n/a (libsandbox.so)
                                               #1  0x00007f3e29d28adf execve (libsandbox.so)
                                               #2  0x0000562cc21e46d2 n/a (bash)
[...]


Portage 2.3.52 (python 2.7.13-final-42, default/linux/amd64/17.1/desktop/plasma/systemd, gcc-8.2.0, glibc-2.28-r3, 4.19.8-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-4.19.8-gentoo-x86_64-AMD_Ryzen_5_2400G_with_Radeon_Vega_Graphics-with-gentoo-2.6
KiB Mem:    15191076 total,    193100 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Sun, 16 Dec 2018 21:15:01 +0000
Head commit of repository gentoo: fad8415f7c9b2f9d626ac6b2b23d1a238def1763
Head commit of repository flatpak-overlay: aa2e187b97bb33ff8839e5abc2636af1e1db9a6f

Timestamp of repository gnome: Fri, 14 Dec 2018 12:23:50 +0000
Head commit of repository gnome: 19dde3288edb83b6093c2096df710191dc80a063

Timestamp of repository steam-overlay: Mon, 03 Dec 2018 21:43:54 +0000
Head commit of repository steam-overlay: 512103e56aef51f78b7bc89734b942ca706cd224

Head commit of repository local: e1b78b455685ce006aa4f05681e2c59b6664419d

sh bash 4.4_p23
ld GNU ld (Gentoo 2.31.1 p4) 2.31.1
ccache version 3.5 [disabled]
app-shells/bash:          4.4_p23::gentoo
dev-java/java-config:     2.2.0-r4::gentoo
dev-lang/perl:            5.26.2::gentoo
dev-lang/python:          2.7.15::gentoo, 3.6.6::gentoo, 3.7.0::gentoo
dev-util/ccache:          3.5-r1::gentoo
dev-util/cmake:           3.13.2::gentoo
dev-util/pkgconfig:       0.29.2::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/sandbox:         2.14::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r4::gentoo
sys-devel/automake:       1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo
sys-devel/binutils:       2.31.1-r2::gentoo
sys-devel/gcc:            8.2.0-r5::gentoo
sys-devel/gcc-config:     2.0::gentoo
sys-devel/libtool:        2.4.6-r5::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers)
sys-libs/glibc:           2.28-r3::gentoo
Repositories:

gentoo
    location: /var/cache/portage/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.de.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-extra-opts: 
    sync-rsync-verify-jobs: 1
    sync-rsync-verify-max-age: 24
    sync-rsync-verify-metamanifest: yes

flatpak-overlay
    location: /var/db/repos/flatpak-overlay
    sync-type: git
    sync-uri: https://github.com/fosero/flatpak-overlay.git
    masters: gentoo

gnome
    location: /var/db/repos/gnome
    sync-type: git
    sync-uri: https://github.com/gentoo-mirror/gnome.git
    masters: gentoo

steam-overlay
    location: /var/db/repos/steam-overlay
    sync-type: git
    sync-uri: https://github.com/gentoo-mirror/steam-overlay.git
    masters: gentoo

local
    location: /var/cache/portage/local
    sync-type: git
    sync-uri: https://github.com/devurandom/gentoo-overlay.git
    masters: gentoo gnome
    priority: 1000

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-pipe -O2 -march=znver1"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /etc/grs/systems.conf /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.5/conf"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.2/ext-active/ /etc/php/cgi-php7.2/ext-active/ /etc/php/cli-php7.2/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-pipe -O2 -march=znver1"
DISTDIR="/var/cache/portage/distfiles"
EMERGE_DEFAULT_OPTS="--keep-going --nospinner --verbose-conflicts"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildsyspkg cgroup compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_GB.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu"
MAKEOPTS="-j6 -l4"
PKGDIR="/var/cache/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/tmp"
USE="7z 7zip X a52 aac aacplus aacs acl acpi activities aio alsa amd64 appindicator appstream archive audit avahi ayatana bash-completion bdplus berkdb bluetooth bluray branding brotli bs2b btrfs bzip2 cairo caps cdda cddb cdio cdr celt chromaprint cjk clang cli colord colorio conntrack crypt cups cxx d3d9 dbus declarative device-mapper dirac djvu dri drm dts dvb dvd dvdr editorconfig egl elf emboss encode epub exif fam fax fbcon ffmpeg fftw filecaps firefox firewalld fish-completion fits flac fontconfig fontforge fortran fribidi gbm gdbm geoclue geolocation gif git glamor gles gmp google googledrive gpg gps graphicsmagick gstreamer gtk gtk3 gzip harfbuzz hdf5 heif http2 ibus iconv icu idn imlib inotify introspection ipv6 jemalloc jpeg jpeg2k json kde kipi kms kwallet ladspa latex lcms ldap libatomic libidn2 libinput libnotify libproxy libsecret libsoxr libtirpc libvirt lm_sensors lrz lv2 lvm lz4 lzma lzo mad markdown mbim mercurial metis mjpeg mng mobi modemmanager modplug mp3 mp4 mpeg mplayer mpris mtp multilib mysql ncurses netlink networkmanager nls nptl office ogg openal opencl opencv openexr opengl openh264 openmax openmp opus pam pango pcap pch pcre pcre2 pdf pgo phonon pixman plasma png policykit postscript ppds prison pulseaudio python qml qt5 rar raw readline redfish samba sasl scanner schroedinger sctp sdl sdl2 seccomp semantic-desktop share snappy sparse speech speex spell ssl startup-notification steamruntime stemmer svg systemd tbb tcpd teamd telepathy tga theora threads tiff timezone truetype tslib udev udisks unicode unwind upnp upnp-av upower usb utempter v4l v4l2 vaapi vdpau vkd3d vorbis vpx vulkan wasm wavpack wayland webchannel webengine webkit webp widgets wmf wps x264 x265 xattr xcb xcomposite xinerama xkb xml xmp xrandr xscreensaver xv xvid xwayland xz yaml zeroconf zeromq zlib zstd" ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon plan sheets stage words" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3" ELIBC="glibc" ENLIGHTENMENT_MODULES="*" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="joystick libinput" KERNEL="linux" L10N="de de-DE en en-GB ar fa tr ja ko zh zh-CN zh-TW" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LIRC_DEVICES="devinput" LLVM_TARGETS="AMDGPU BPF" LUA_TARGET="lua5-2" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6 pypy pypy3" QEMU_SOFTMMU_TARGETS="riscv32 riscv64 x86_64" QEMU_USER_TARGETS="riscv32 riscv64" RUBY_TARGETS="ruby23 ruby24" STEAMGAMES="dirt_rally dont_starve portal source_engine te120 trine2 witcher2" USERLAND="GNU" VIDEO_CARDS="amdgpu virgl" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

=================================================================
                        Package Settings
=================================================================

sys-apps/sandbox-2.14::gentoo was built with the following:
USE="" ABI_X86="(32) (64) (-x32)"
Comment 17 Thomas Deutschmann (RETIRED) gentoo-dev 2018-12-17 01:42:26 UTC
So does it work with FEATURES=-usersandbox for you?
For now you are still the only one experiencing this problem...

Did you reinstall sqlite with ABI_X86="64" _only_ like I asked to test to verify the problems aren't caused by build system which is for some reason picking up wrong libs?
Comment 18 Arfrever Frehtes Taifersar Arahesis 2018-12-17 02:53:35 UTC
(In reply to Thomas Deutschmann from comment #17)
> Did you reinstall sqlite with ABI_X86="64" _only_ like I asked to test to
> verify the problems aren't caused by build system which is for some reason
> picking up wrong libs?

Linker (either BFD or GOLD) would not allow it:

$ gcc -c -o main.o -x c - <<< "int main(){}"
$ gcc -fuse-ld=bfd -o test_linking_with_wrong_library main.o /usr/lib32/libsqlite3.so
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: /usr/lib32/libsqlite3.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
$ gcc -fuse-ld=gold -o test_linking_with_wrong_library main.o /usr/lib32/libsqlite3.so
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: error: /usr/lib32/libsqlite3.so: incompatible target
collect2: error: ld returned 1 exit status


Most likely the correct library is chosen, but libsandbox.so happens to cause segmentation fault when executing conftest.
Segmentation fault results in exit status 139, and any non-0 exit status is interpreted by build system as "System SQLite library is not compiled with SQLITE_SECURE_DELETE"...
Comment 19 Dennis Schridde 2018-12-19 23:26:53 UTC
I can easily reproduce this by building the program as described in comment #6 and then executing `sandbox ./conftest`.

Running `gdb sandbox` and from there `run ./conftest` yields the following:
```
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7dbbcb7 in kill () from /lib64/libc.so.6
(gdb) bt full
#0  0x00007ffff7dbbcb7 in kill () from /lib64/libc.so.6
No symbol table info available.
#1  0x000055555555840d in main (argc=<optimized out>, argv=<optimized out>) at /tmp/portage/sys-apps/sandbox-2.14/work/sandbox-2.14/src/sandbox.c:346
        signum = <optimized out>
        sandbox_log_presence = <optimized out>
        sandbox_info = {sandbox_log = "/var/log/sandbox/sandbox-25790.log", '\000' <repeats 8157 times>, sandbox_debug_log = "/var/log/sandbox/sandbox-debug-25790.log", '\000' <repeats 8151 times>, sandbox_message_path = "/proc/25790/fd/2", '\000' <repeats 8175 times>, sandbox_lib = "libsandbox.so", '\000' <repeats 8178 times>, sandbox_rc = "/usr/share/sandbox/sandbox.bashrc", '\000' <repeats 8158 times>, work_dir = "/home/$USER/test", '\000' <repeats 8171 times>, tmp_dir = "/tmp/.private/$USER", '\000' <repeats 8168 times>, home_dir = 0x7fffffffdce0 "/home/$USER"}
        sandbox_environ = 0x0
        argv_bash = 0x0
        run_str = 0x55555555f40a "-c"
        __func__ = "main"
        sigs = {1, 2, 3, 15, 10}
        act_new = {__sigaction_handler = {sa_handler = 0x55555555a470 <usr1_handler>, sa_sigaction = 0x55555555a470 <usr1_handler>}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 268435460, sa_restorer = 0x0}
        act_old = {{__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 207118349618, 11, 140737488345147, 93824992279053, 265, 140737352123466, 48, 9815765468983753216, 93824992279053, 140737488345147, 93824992278144, 93824992262875, 93824992332528, 93824992332624, 93824992332624}}, sa_flags = 0, sa_restorer = 0x0}, {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 207118349618, 11, 140737488345147, 93824992279053, 265, 140737352123466, 48, 9815765468983753216, 93824992279053, 140737488345147, 93824992278144, 93824992262875, 93824992332528, 93824992332624, 93824992332624}}, sa_flags = 0, sa_restorer = 0x0}, {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 207118349618, 11, 140737488345147, 93824992279053, 265, 140737352123466, 48, 9815765468983753216, 93824992279053, 140737488345147, 93824992278144, 93824992262875, 93824992332528, 93824992332624, 93824992332624}}, sa_flags = 0, sa_restorer = 0x0}, {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 207118349618, 11, 140737488345147, 93824992279053, 265, 140737352123466, 48, 9815765468983753216, 93824992279053, 140737488345147, 93824992278144, 93824992262875, 93824992332528, 93824992332624, 93824992332624}}, sa_flags = 0, sa_restorer = 0x0}, {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 207118349618, 11, 140737488345147, 93824992279053, 265, 140737352123466, 48, 9815765468983753216, 93824992279053, 140737488345147, 93824992278144, 93824992262875, 93824992332528, 93824992332624, 93824992332624}}, sa_flags = 0, sa_restorer = 0x0}}
        si = <optimized out>
        shell_exit = <optimized out>
```

$USER is a placeholder for my username.

sandbox.c:346 is: `kill(getpid(), signum);`, with `int signum = WTERMSIG(shell_exit);`, `shell_exit` being either `1` (sandbox.c:192) or the exit status as set by `waitpid(child_pid, &status, 0);` (sandbox.c:198) or `0` (sandbox.c:201).

The manpage for `getpid` claims that it will never fail, so I am concentrating on `signum` and wonder whether 1 is a legal value for `status` and how it interacts with the status inspection macros `WIFSIGNALED` and `WTERMSIG`.
Comment 20 Dennis Schridde 2018-12-19 23:53:34 UTC
An `-O0` build yields:
```
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7dbbcb7 in kill () from /lib64/libc.so.6
(gdb) bt full
#0  0x00007ffff7dbbcb7 in kill () from /lib64/libc.so.6
No symbol table info available.
#1  0x000055555555a590 in main (argc=2, argv=0x7fffffffd3b8) at /tmp/portage/sys-apps/sandbox-2.14/work/sandbox-2.14/src/sandbox.c:346
        signum = 11
        sandbox_log_presence = 0
        sandbox_info = {sandbox_log = "/var/log/sandbox/sandbox-25191.log", '\000' <repeats 8157 times>, sandbox_debug_log = "/var/log/sandbox/sandbox-debug-25191.log", '\000' <repeats 8151 times>, sandbox_message_path = "/proc/25191/fd/2", '\000' <repeats 8175 times>, sandbox_lib = "libsandbox.so", '\000' <repeats 8178 times>, sandbox_rc = "/usr/share/sandbox/sandbox.bashrc", '\000' <repeats 8158 times>, work_dir = "/home/$USER/test", '\000' <repeats 8171 times>, tmp_dir = "/tmp/.private/$USER", '\000' <repeats 4034 times>..., home_dir = 0x7fffffffdcdf "/home/$USER"}
        sandbox_environ = 0x0
        argv_bash = 0x0
        run_str = 0x55555556080d "-c"
        __func__ = "main"
        sigs = {1, 2, 3, 15, 10}
        act_new = {__sigaction_handler = {sa_handler = 0x555555559033 <usr1_handler>, sa_sigaction = 0x555555559033 <usr1_handler>}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 268435460, sa_restorer = 0x0}
        act_old = {{__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 140737488345146, 93824992240928, 140737488343984, 140737352123466, 140737488343984, 12123788846670348800, 0, 0, 140737488285216, 93824992265050, 265, 93824992283460, 93824992283016, 140737488345146, 0}}, sa_flags = 0, sa_restorer = 0x0}, {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 140737488345146, 93824992240928, 140737488343984, 140737352123466, 140737488343984, 12123788846670348800, 0, 0, 140737488285216, 93824992265050, 265, 93824992283460, 93824992283016, 140737488345146, 0}}, sa_flags = 0, sa_restorer = 0x0}, {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}
, sa_mask = {__val = {0, 140737488345146, 93824992240928, 140737488343984, 140737352123466, 140737488343984, 12123788846670348800, 0, 0, 140737488285216, 93824992265050, 265, 93824992283460, 93824992283016, 140737488345146, 0}}, sa_flags = 0, sa_restorer = 0x0}, {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 140737488345146
, 93824992240928, 140737488343984, 140737352123466, 140737488343984, 12123788846670348800, 0, 0, 140737488285216, 93824992265050, 265, 93824992283460, 93824992283016, 140737488345146, 0}}, sa_flags = 0, sa_restorer = 0x0}, {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {0, 140737488345146, 93824992240928, 140737488343984, 140737352123466, 140737488343984, 12123788846670348800, 0, 0, 140737488285216, 93824992265050, 265, 93824992283460, 93824992283016, 140737488345146, 0}}, sa_flags = 0, sa_restorer = 0x0}}
        si = 5
        shell_exit = 139
(gdb) call (int)getpid()
$1 = 25191
```

I guess what we learn from that (and studying the code) is that sandbox works as intended and kills itself with the signal its child was killed with. And we're back to square one.

`env USE=-abi_x86_32 emerge -1av --nodeps dev-db/sqlite` preserves `/usr/lib/libsqlite3.so.0` and `/usr/lib/libsqlite3.so.0.8.6` and does not change a thing about conftest segfaulting.
Comment 21 Dennis Schridde 2018-12-19 23:58:49 UTC
Interesting enough `sandbox gdb ./conftest` followed by `run` does not make `conftest` segfault: [Inferior 1 (process 10021) exited normally].  But `sandbox ./conftest` does segfault: Sandboxed process killed by signal: Segmentation fault

Is there a way to make sandbox give me a coredump of the application it was running, so I can avoid the intermediary invocation of gdb?
Comment 22 Arfrever Frehtes Taifersar Arahesis 2018-12-20 00:22:20 UTC
Please try with sys-apps/sandbox-2.12 and sys-apps/sandbox-2.13.
You might also try with sys-libs/glibc-2.27-r*.
Comment 23 Arfrever Frehtes Taifersar Arahesis 2018-12-20 00:33:49 UTC
You can enable writing core files using 'ulimit -c unlimited'.
With systemd, core files are probably stored in /var/lib/systemd/coredump directory.
You can use 'gdb --core ${core_file}' and then check backtrace.
Comment 24 Dennis Schridde 2018-12-20 09:14:26 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #23)
> You can enable writing core files using 'ulimit -c unlimited'.
> With systemd, core files are probably stored in /var/lib/systemd/coredump
> directory.
> You can use 'gdb --core ${core_file}' and then check backtrace.

Sorry, I did not see that systemd logs two stacktraces for each crash, one for the sandbox process and one for the process that actually crashed.  This is a stacktrace of the latter:
```
Stack trace of thread 8336:
#0  0x00007f6323de3a8b sb_check_exec (libsandbox.so)
#1  0x00007f6323de3e07 execve_DEFAULT (libsandbox.so)
#2  0x0000560aedb1f6d2 n/a (bash)
#3  0x0000560aedb083f2 n/a (bash)
#4  0x0000560aedb2079e n/a (bash)
#5  0x0000560aedb69528 n/a (bash)
#6  0x0000560aedb06985 n/a (bash)
#7  0x0000560aedb0a5ac n/a (bash)
#8  0x00007f63239d14eb __libc_start_main (libc.so.6)
#9  0x0000560aedb0b26a n/a (bash)
```

I would like to examine the coredump with gdb in order to get some details (sb_check_exec is not really short), but find no way to make it load libsandbox.so and use that to resolve 0x00007f6323de3a8b.  Any ideas?


(In reply to Arfrever Frehtes Taifersar Arahesis from comment #22)
> Please try with sys-apps/sandbox-2.12 and sys-apps/sandbox-2.13.
> You might also try with sys-libs/glibc-2.27-r*.

The issue persists with sandbox-2.12 and glibc cannot be downgraded:
 * Sanity check to keep you from breaking your system:
 *  Downgrading glibc is not supported and a sure way to destruction.
 * ERROR: sys-libs/glibc-2.27-r6::gentoo failed (pretend phase):
 *   Aborting to save your system.
Comment 25 Dennis Schridde 2018-12-20 09:57:06 UTC
I am able to reproduce this without SQLite:

$ cat conftest-mwe.c
#include <stdio.h>
  int main(int argc, char **argv){
printf("TEST\n");
           return 0;
            }

$ /usr/lib/llvm/7/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -o conftest-mwe -pipe -march=znver1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread  -Qunused-arguments  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -lpthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc conftest-mwe.c -g
In file included from conftest-mwe.c:1:
In file included from /usr/include/stdio.h:27:
In file included from /usr/include/bits/libc-header-start.h:33:
/usr/include/features.h:381:4: warning: _FORTIFY_SOURCE requires compiling with optimization (-O) [-W#warnings]
#  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
   ^
1 warning generated.

$ sandbox ./conftest-mwe
Sandboxed process killed by signal: Segmentation fault
fish: “sandbox ./conftest-mwe” terminated by signal SIGSEGV (Address boundary error)

Stack trace of thread 4451:
#0  0x00007f76bdaeba8b sb_check_exec (libsandbox.so)
#1  0x00007f76bdaebe07 execve_DEFAULT (libsandbox.so)
#2  0x000055f5b425d6d2 n/a (bash)
#3  0x000055f5b42463f2 n/a (bash)
#4  0x000055f5b425e79e n/a (bash)
#5  0x000055f5b42a7528 n/a (bash)
#6  0x000055f5b4244985 n/a (bash)
#7  0x000055f5b42485ac n/a (bash)
#8  0x00007f76bd6d94eb __libc_start_main (libc.so.6)
#9  0x000055f5b424926a n/a (bash)


Not reproducible with GCC 8.2.0:
$ gcc -std=gnu99 -o conftest-mwe -pipe -march=znver1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -lpthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc conftest-mwe.c -g
In file included from /usr/include/bits/libc-header-start.h:33,
                 from /usr/include/stdio.h:27,
                 from conftest-mwe.c:1:
/usr/include/features.h:381:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
 #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
    ^~~~~~~

(Same commandline as above, minus -Qunused-arguments -fuse-ld=lld.)

$ sandbox ./conftest-mwe
TEST
Comment 26 Dennis Schridde 2018-12-20 10:04:08 UTC
(In reply to Dennis Schridde from comment #25)
> I am able to reproduce this without SQLite:
> [...]

The repro vanishes when I remove -fuse-ld=lld from clang's argument list.
Comment 27 Arfrever Frehtes Taifersar Arahesis 2018-12-21 03:06:48 UTC
Please check if any of the other CFLAGS / LDFLAGS are necessary for reproducing this problem.

Please check if this problem is reproducible with versions 6.0.1 and 7.0.1 of sys-devel/lld and sys-devel/clang.
Comment 28 Dennis Schridde 2018-12-21 06:38:24 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #27)
> Please check if any of the other CFLAGS / LDFLAGS are necessary for
> reproducing this problem.

It also vanishes when I remove -Wl,--hash-style=gnu, but leave -fuse-ld=lld.  Which would explain why no one else is seeing this.
Comment 29 Dennis Schridde 2018-12-21 06:40:30 UTC
I would assume the bug is in sys-apps/sandbox-2.14, since it should IMO never segfault, no matter how bad its input is.
Comment 30 Dennis Schridde 2018-12-21 19:27:58 UTC
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #27)
> Please check if this problem is reproducible with versions 6.0.1 and 7.0.1
> of sys-devel/lld and sys-devel/clang.

Reproducible with LLVM 7.0.1 and also 6.0.1:

$ /usr/lib/llvm/6/bin/x86_64-pc-linux-gnu-clang -std=gnu99 -o conftest-mwe -pipe -march=znver1 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread  -Qunused-arguments  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -lpthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-rpath=/usr/lib64/firefox,--enable-new-dtags -fuse-ld=lld -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc conftest-mwe.c -g
In file included from conftest-mwe.c:1:
In file included from /usr/include/stdio.h:27:
In file included from /usr/include/bits/libc-header-start.h:33:
/usr/include/features.h:381:4: warning: _FORTIFY_SOURCE requires compiling with optimization (-O) [-W#warnings]
#  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
   ^
1 warning generated.

$ sandbox ./conftest-mwe
Sandboxed process killed by signal: Segmentation fault
fish: “sandbox ./conftest-mwe” terminated by signal SIGSEGV (Address boundary error)
Comment 31 Dennis Schridde 2018-12-29 21:24:42 UTC
Created attachment 558892 [details, diff]
diff -u conftest-mwe.clang.readelf conftest-mwe.gcc.readelf

What I see when comparing the output of `readelf -a` from the binaries Clang and GCC generate:
* Clang inserts an INTERP program header, which sets `dynamic` in __wrapper_exec.c `PARSE_ELF(n)`, which completest the symbol table parsing path in `PARSE_ELF(n)`
* Clang generates a .symtab that is quite a bit larger than what GCC generates: 35 vs 6 entries
* In the Clang .symtab there are quite a few symbols starting with `__`, while with GCC there are none at all
* None of the double underscore symbols are from the `libc_alloc_syms` list
* Several of these double underscore symbols are not of type `FUNC`
Comment 32 Dennis Schridde 2018-12-29 21:25:11 UTC
Created attachment 558894 [details]
readelf -a conftest-mwe.clang
Comment 33 Dennis Schridde 2018-12-29 21:25:33 UTC
Created attachment 558896 [details]
readelf -a conftest-mwe.gcc
Comment 34 Dennis Schridde 2018-12-29 21:27:43 UTC
Created attachment 558898 [details, diff]
sandbox-2.14-fix-parse-elf.patch

Attached patch fixes the issue for me.  I confirmed that it is effective by removing it again, which makes the issue reappear.

Please review.
Comment 35 Dennis Schridde 2018-12-29 21:29:07 UTC
Created attachment 558900 [details, diff]
sandbox-2.14-fix-parse-elf.patch

Fix patch header to include sign-off.
Comment 36 Dennis Schridde 2018-12-29 21:39:21 UTC
(In reply to Dennis Schridde from comment #35)
> Created attachment 558900 [details, diff] [details, diff]
> sandbox-2.14-fix-parse-elf.patch
> 
> Fix patch header to include sign-off.

This patch also fixes the original build failure with firefox.
Comment 37 Dennis Schridde 2018-12-29 22:26:37 UTC
Created attachment 558906 [details]
readelf -a build-script-build

(In reply to Dennis Schridde from comment #36)
> (In reply to Dennis Schridde from comment #35)
> > Created attachment 558900 [details, diff] [details, diff] [details, diff]
> > sandbox-2.14-fix-parse-elf.patch
> > 
> > Fix patch header to include sign-off.
> 
> This patch also fixes the original build failure with firefox.

i.e. fixes the configure issue.

But there is another segfault, in the same libsandbox function:
 5:05.84 error: failed to run custom build command for `khronos_api v2.2.0`                                                                                                                                                                                                                                                                                                 
 5:05.84 process didn't exit successfully: `/var/tmp/portage/www-client/firefox-64.0/work/firefox-64.0/ff/release/build/khronos_api-1e156cda16f04b1c/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)                                                                                                                                                    

kernel: cargo[31185]: segfault at 7f0e494de080 ip 00007f0e33b5babf sp 00007f0e21d9d8f0 error 4 in libsandbox.so[7f0e33b52000+10000]
kernel: Code: 00 48 8b 85 d8 fe ff ff 0f b7 40 06 66 3d ff fe 0f 87 87 00 00 00 48 8b 85 d8 fe ff ff 8b 00 85 c0 74 7a 48 8b 85 58 ff ff ff <0f> b6 00 66 98 66 83 f8 5f 75 68 48 8b 85 58 ff ff ff 48 ff c0 0f
systemd[1]: Started Process Core Dump (PID 31186/UID 0).     
systemd-coredump[31192]: Process 31185 (cargo) of user 250 dumped core.

Stack trace of thread 31185:
#0  0x00007f0e33b5babf sb_check_exec (libsandbox.so)
#1  0x00007f0e33b5c0f8 execvp_DEFAULT (libsandbox.so)
#2  0x00005642de4a15f1 n/a (cargo-1.31.1)
#3  0x00005642de4a0c61 n/a (cargo-1.31.1)
#4  0x00005642de4bcefa n/a (cargo-1.31.1)
#5  0x00005642de0470aa n/a (cargo-1.31.1)
#6  0x00005642ddf927ef n/a (cargo-1.31.1)
#7  0x00005642ddff60ff n/a (cargo-1.31.1)
#8  0x00005642ddff61dc n/a (cargo-1.31.1)
#9  0x00005642ddf55c5c n/a (cargo-1.31.1)
#10 0x00005642de4cd1fa n/a (cargo-1.31.1)
#11 0x00005642ddf5560d n/a (cargo-1.31.1)
#12 0x00005642de4ba20e n/a (cargo-1.31.1)
#13 0x00005642de4a6266 n/a (cargo-1.31.1)
#14 0x00007f0e335a74f3 start_thread (libpthread.so.0)
#15 0x00007f0e334b5fbf __clone (libc.so.6)

This time we again have several double underscore symbols, and the `libc_alloc_syms` also appear in the list.  I must assume that my previous patch did not actually fix the cause of the segfault, but just restricted the condition enough that it did not trigger a segfault for the simple `conftest` case anymore.

It is noteworthy that my previous patch is also slightly wrong, because the `__*_hook` symbols are of type `OBJECT` (with bind `GLOBAL` and visibility `DEFAULT`) and not of type `FUNC` (with bind `LOCAL` and visibility `HIDDEN`) as the `__libc_*` symbols and thus are not detected anymore after my patch.

Since it is not possible to compile this code with GCC (it is Rust code) and hence I cannot continue by simply comparing the output of `readelf`, and since gdb does not pick up debug symbols for libsandbox.so [1] and hence I cannot examine the value of variables in the core dump, I am not sure how to continue debugging this.

[1]: For an unknown reason I just get the following output for `bt full`, even when I load the libsandbox.so.debug symbol file explicitly:

(gdb) symbol-file /usr/lib/debug/usr/lib/libsandbox.so.debug
Load new symbol table from "/usr/lib/debug/usr/lib/libsandbox.so.debug"? (y or n) y
Reading symbols from /usr/lib/debug/usr/lib/libsandbox.so.debug...done.
(gdb) bt full
#0  0x00007fe31295eabf in ?? () from /lib64/libsandbox.so
No symbol table info available.
#1  0x00007fe31295f0f8 in execvp () from /lib64/libsandbox.so
No symbol table info available.
[...]
Comment 38 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-12-29 22:33:19 UTC
Could you please make it into a proper git patch, with nice explanatory commit message?  I think I get what you did there but I really think it would be nice to say that explicitly for future readers.
Comment 39 Dennis Schridde 2018-12-29 22:38:50 UTC
Something I noticed when comparing the output of gdb `bt full` when examining the coredump and systemd-coredump: GDB reports frame 0 at 0x00007fe31295eabf, while systemd-coredump reports it at 0x00007f0e33b5babf.

I tried loading the `...so.debug` file at 0x7f0e33b52000+0x10000, the address libsandbox.so was loaded at as indicated by the kernel message, but that did not change anything about the output of `bt full`:
kernel: cargo[31185]: segfault at 7f0e494de080 ip 00007f0e33b5babf sp 00007f0e21d9d8f0 error 4 in libsandbox.so[7f0e33b52000+10000]                                                                                                                                                                                                                  

(gdb) add-symbol-file /usr/lib/debug/usr/lib64/libsandbox.so.debug 0x7f0e33b52000+0x10000

https://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#Files
Comment 40 Dennis Schridde 2018-12-29 22:48:44 UTC
Created attachment 558908 [details, diff]
sandbox-2.14-fix-parse-elf.patch

(In reply to Michał Górny from comment #38)
> Could you please make it into a proper git patch, with nice explanatory
> commit message?  I think I get what you did there but I really think it
> would be nice to say that explicitly for future readers.

Attached patch contains a better commit messages, but still does not fix the root cause of the segfault (see comment #37).  Since I have trouble debugging this further (comment #39), I hope that someone can help me to get more information out of the core dump.
Comment 41 Arfrever Frehtes Taifersar Arahesis 2018-12-30 13:19:31 UTC
Build-time version of sys-libs/glibc is also relevant.
Segmentation fault does not occur if program has been built with sys-libs/glibc-2.27-r6.
Segmentation fault occurs if program has been built with sys-libs/glibc-2.28-r4.
Run-time version of sys-libs/glibc does not matter.
(Build-time version of sys-libs/glibc for building of sys-apps/sandbox does not matter.)
(sys-devel/clang-7.0.1, sys-devel/lld-7.0.1)
Comment 42 Andreas K. Hüttel archtester gentoo-dev 2019-02-02 15:11:53 UTC
OK so could anyone who knows this better than I do please summarize

* what's the status here
* what needs to be done
* and does it in any way affect glibc-2.28 stabilization?
Comment 43 Thomas Deutschmann (RETIRED) gentoo-dev 2019-02-04 16:36:12 UTC
*** Bug 677210 has been marked as a duplicate of this bug. ***
Comment 44 Dennis Schridde 2019-02-04 21:47:08 UTC
(In reply to Andreas K. Hüttel from comment #42)
> OK so could anyone who knows this better than I do please summarize
> 
> * what's the status here

The issue persists with sys-libs/glibc-2.28-r5, sys-devel/clang-7.0.1, sys-apps/sandbox-2.15 and still materialises when building www-client/firefox-65.0.
Comment 45 tt_1 2019-02-05 10:46:31 UTC
May I ask, is sandbox-2.13 also affected?
Comment 46 Arfrever Frehtes Taifersar Arahesis 2019-02-05 17:45:51 UTC
All available versions of sys-apps/sandbox (2.12, 2.13, 2.14, 2.15) are affected.
Comment 47 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-02-24 08:44:14 UTC
(In reply to Dennis Schridde from comment #40)
> Created attachment 558908 [details, diff] [details, diff]
> sandbox-2.14-fix-parse-elf.patch
> 
> (In reply to Michał Górny from comment #38)
> > Could you please make it into a proper git patch, with nice explanatory
> > commit message?  I think I get what you did there but I really think it
> > would be nice to say that explicitly for future readers.
> 
> Attached patch contains a better commit messages, but still does not fix the
> root cause of the segfault (see comment #37).  Since I have trouble
> debugging this further (comment #39), I hope that someone can help me to get
> more information out of the core dump.

Is this patch good enough to be applied?  If so, I'd like to make a release with the fix.
Comment 48 Dennis Schridde 2019-02-24 13:03:21 UTC
(In reply to Michał Górny from comment #47)
> (In reply to Dennis Schridde from comment #40)
> > Created attachment 558908 [details, diff] [details, diff] [details, diff]
> > sandbox-2.14-fix-parse-elf.patch
> > 
> > (In reply to Michał Górny from comment #38)
> > > Could you please make it into a proper git patch, with nice explanatory
> > > commit message?  I think I get what you did there but I really think it
> > > would be nice to say that explicitly for future readers.
> > 
> > Attached patch contains a better commit messages, but still does not fix the
> > root cause of the segfault (see comment #37).  Since I have trouble
> > debugging this further (comment #39), I hope that someone can help me to get
> > more information out of the core dump.
> 
> Is this patch good enough to be applied?  If so, I'd like to make a release
> with the fix.

The patch limits the segfault to fewer cases (because less symbols match), but it does not actually fix the segfault itself.  With the patch I can still reproduce the segfault, but iirc it does not anymore happen when building firefox.
Comment 49 Dennis Schridde 2019-03-01 08:31:53 UTC
(In reply to Dennis Schridde from comment #48)
> The patch limits the segfault to fewer cases (because less symbols match),
> but it does not actually fix the segfault itself.  With the patch I can
> still reproduce the segfault, but iirc it does not anymore happen when
> building firefox.

Correction: Firefox still does not build reliably (www-client/firefox-64.0 built at least once here, for unknown reasons).  The patch as it is only prevents segfaults in SQLite detection, but later bash or cargo (which one appears to be random) crashes during the build process.  So the patch definitely does not fix the root cause, or there are multiple issues in the sb_check_exec code.
Comment 50 Thomas Deutschmann (RETIRED) gentoo-dev 2019-03-01 18:15:59 UTC
@ Dennis:

Looks like you are the only one active in this bug. Could you please try to answer Andreas' question from comment #42?
Comment 51 Dennis Schridde 2019-03-01 19:36:32 UTC
(In reply to Thomas Deutschmann from comment #50)
> @ Dennis:
> 
> Looks like you are the only one active in this bug. Could you please try to
> answer Andreas' question from comment #42?

I tried to do that in comment #44, as far as I could.

* what's the status here
  - The issue persists (comment #44)
* what needs to be done
  - sb_check_exec needs to be debugged.
* and does it in any way affect glibc-2.28 stabilization?
  - According to Arfrever: Yes (comment #41), but I personally have not tried to confirm that.
Comment 52 Sergei Trofimovich (RETIRED) gentoo-dev 2019-03-01 23:06:43 UTC
sandbox iterates through dynamic symbols. The problem is that it iterates past the boundary of symbol section size:

$ LD_LIBRARY_PATH=/tmp/z/lib/ ./bin/sandbox ./mwe.lld 
  0: 
  1: __libc_start_main
  2: __gmon_start__
  3: _ITM_deregisterTMCloneTable
  4: _ITM_registerTMCloneTable
  5: printf
  6: __stack_chk_fail
  7: 
  8: nux-x86-64.so.2
  Sandboxed process killed by signal: Segmentation fault

$ LANG=C readelf --dyn-syms mwe.lld

Symbol table '.dynsym' contains 7 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
     4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (2)
     6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (3)

Note: it crashes into invalid offset with index 7 and below. It happens because sandbox assumes that symbol table section goes right before string table section:

https://gitweb.gentoo.org/proj/sandbox.git/tree/libsandbox/wrapper-funcs/__wrapper_exec.c#n164 :

    symend = (void *)(elf + stroff);

It happens to be true for ld.bfd:

$ readelf --sections mwe.ld
  [31] .symtab           SYMTAB           0000000000000000  00003918
       0000000000000648  0000000000000018          32    49     8
  [32] .strtab           STRTAB           0000000000000000  00003f60
       00000000000001d8  0000000000000000           0     0     1
  [33] .shstrtab         STRTAB           0000000000000000  00004138
       000000000000013b  0000000000000000           0     0     1

But not for ld.lld as extra '.shstrtab' is in the way:

  [33] .symtab           SYMTAB           0000000000000000  00003af0
       0000000000000348  0000000000000018          35    22     8
  [34] .shstrtab         STRTAB           0000000000000000  00003e38
       000000000000015f  0000000000000000           0     0     1
  [35] .strtab           STRTAB           0000000000000000  00003f97
       0000000000000201  0000000000000000           0     0     1

Existing code comes from glibc's symbol table loader:

    https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-addr.c;h=9d285d76a728a1c378d9f202e31bdc816e16f665;hb=HEAD#l26

glibc knows how to load .gnu.hash section to determine symbol count. But not sandbox.
Comment 53 Sergei Trofimovich (RETIRED) gentoo-dev 2019-03-02 19:39:57 UTC
Created attachment 567468 [details, diff]
0001-exec-wrapper-add-support-for-GNU_HASH-parser.patch

0001-exec-wrapper-add-support-for-GNU_HASH-parser.patch is a fix to implement GNU_HASH symbol walking. Fixes lld binary failure for me.
Comment 54 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-03-02 19:57:00 UTC
Thanks.  Could you include a test case for it?

I'll also look if we can change LLD's behavior to improve compatibility with the old version.
Comment 55 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-03-02 19:59:24 UTC
Hm, the relevant LLD code has:

  if (In.SymTab)
    Add(In.SymTab);
  if (In.SymTabShndx)
    Add(In.SymTabShndx);
  Add(In.ShStrTab);
  if (In.StrTab)
    Add(In.StrTab);

Do you have any clue what SymTabShndx is, and whether it would also be in the way?
Comment 56 Sergei Trofimovich (RETIRED) gentoo-dev 2019-03-02 21:13:14 UTC
(In reply to Michał Górny from comment #54)
> Could you include a test case for it?

Not easily. Test would need to run lld-linked binary. Sounds like a lot of autoconf hackery to make one execve test run twice.

Perhaps it would be more useful to make the following just work:
    ./configure CC=clang LDFLAGS='-fuse-ld=lld -Wl,--hash-style=gnu'
But it needs some work:
    checking libc path... configure: error: Unable to determine LIBC PATH ()

(In reply to Michał Górny from comment #55)
> Hm, the relevant LLD code has:
> 
>   if (In.SymTab)
>     Add(In.SymTab);
>   if (In.SymTabShndx)
>     Add(In.SymTabShndx);
>   Add(In.ShStrTab);
>   if (In.StrTab)
>     Add(In.StrTab);
> 
> Do you have any clue what SymTabShndx is, and whether it would also be in
> the way?

Must be a SHT_SYMTAB_SHNDX section (.symtab_shndx). It has the same format as SYMTAB (.symtab) but contains section addresses. Should not cause immediate breakage.

Section header order only indirectly affects data order loaded in program. I would not be surprised if lld is able to reorder sections to fill gaps within loadable segment of the same type.

For example in case of buggy binary GNU_HASH is between SYMTAB and STRTAB:

    $ LANG=C readelf -a mwe.lld
    Dynamic section at offset 0x3010 contains 25 entries:
    ...
     0x0000000000000006 (SYMTAB)             0x200290
     0x000000000000000b (SYMENT)             24 (bytes)
     0x0000000000000005 (STRTAB)             0x200394
     0x000000000000000a (STRSZ)              165 (bytes)
     0x000000006ffffef5 (GNU_HASH)           0x200378

Or sorted by "address":

     0x0000000000000006 (SYMTAB)             0x200290
     0x000000006ffffef5 (GNU_HASH)           0x200378
     0x0000000000000005 (STRTAB)             0x200394
Comment 57 Arfrever Frehtes Taifersar Arahesis 2019-03-03 01:18:26 UTC
All 3 linkers support --section-start=${section_name}=${address} option.
It allows to specify custom location of some sections (e.g. -Wl,--section-start=.init=0x3000000), but unfortunately it does not work for .symtab or .strtab sections.
Comment 58 Dennis Schridde 2019-03-03 07:37:21 UTC
(In reply to Sergei Trofimovich from comment #53)
> Created attachment 567468 [details, diff] [details, diff]
> 0001-exec-wrapper-add-support-for-GNU_HASH-parser.patch
> 
> 0001-exec-wrapper-add-support-for-GNU_HASH-parser.patch is a fix to
> implement GNU_HASH symbol walking. Fixes lld binary failure for me.

Thanks for the patch.  Applied to sys-apps/sandbox-2.15 it makes www-client/firefox-65.0.2 build.
Comment 59 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-03-03 07:41:04 UTC
(In reply to Sergei Trofimovich from comment #56)
> (In reply to Michał Górny from comment #54)
> > Could you include a test case for it?
> 
> Not easily. Test would need to run lld-linked binary. Sounds like a lot of
> autoconf hackery to make one execve test run twice.
> 
> Perhaps it would be more useful to make the following just work:
>     ./configure CC=clang LDFLAGS='-fuse-ld=lld -Wl,--hash-style=gnu'
> But it needs some work:
>     checking libc path... configure: error: Unable to determine LIBC PATH ()

Maybe you could just add a trivial prebuilt amd64 binary (plus source for license reasons) for this.  Having it tested on one platform is better than none.

Or maybe you could achieve the same result with GNU ld via ldscripts.
Comment 60 Arfrever Frehtes Taifersar Arahesis 2019-03-04 09:25:08 UTC
Probably relevant change in glibc found by Slyfox:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3a885c1f51b18852869a91cf59a1b39da1595c7a


Difference between libc_nonshared.a from glibc 2.27 and 2.29 contains:
"""
 Disassembly of section .text:
 
 0000000000000000 <__libc_csu_init>:
    0:  41 57                   push   %r15
    2:  49 89 d7                mov    %rdx,%r15
    5:  41 56                   push   %r14
    7:  49 89 f6                mov    %rsi,%r14
    a:  41 55                   push   %r13
    c:  41 89 fd                mov    %edi,%r13d
    f:  41 54                   push   %r12
   11:  4c 8d 25 00 00 00 00    lea    0x0(%rip),%r12        # 18 <__libc_csu_init+0x18>
                        14: R_X86_64_PC32       __init_array_start-0x4
   18:  55                      push   %rbp
   19:  48 8d 2d 00 00 00 00    lea    0x0(%rip),%rbp        # 20 <__libc_csu_init+0x20>
                        1c: R_X86_64_PC32       __init_array_end-0x4
   20:  53                      push   %rbx
   21:  4c 29 e5                sub    %r12,%rbp
-  24:  48 83 ec 08             sub    $0x8,%rsp
-  28:  e8 00 00 00 00          callq  2d <__libc_csu_init+0x2d>
-                       29: R_X86_64_PLT32      _init-0x4
-  2d:  48 c1 fd 03             sar    $0x3,%rbp
-  31:  74 20                   je     53 <__libc_csu_init+0x53>
-  33:  31 db                   xor    %ebx,%ebx
-  35:  0f 1f 00                nopl   (%rax)
-  38:  49 8b 04 dc             mov    (%r12,%rbx,8),%rax
-  3c:  48 83 c3 01             add    $0x1,%rbx
-  40:  4c 89 fa                mov    %r15,%rdx
-  43:  4c 89 f6                mov    %r14,%rsi
-  46:  44 89 ef                mov    %r13d,%edi
-  49:  e8 00 00 00 00          callq  4e <__libc_csu_init+0x4e>
-                       4a: R_X86_64_PLT32      __x86_indirect_thunk_rax-0x4
-  4e:  48 39 dd                cmp    %rbx,%rbp
-  51:  75 e5                   jne    38 <__libc_csu_init+0x38>
-  53:  48 83 c4 08             add    $0x8,%rsp
-  57:  5b                      pop    %rbx
-  58:  5d                      pop    %rbp
-  59:  41 5c                   pop    %r12
-  5b:  41 5d                   pop    %r13
-  5d:  41 5e                   pop    %r14
-  5f:  41 5f                   pop    %r15
-  61:  e9 00 00 00 00          jmpq   66 <__libc_csu_init+0x66>
-                       62: R_X86_64_PLT32      __x86_return_thunk-0x4
-  66:  66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
-  6d:  00 00 00 
-
-0000000000000070 <__libc_csu_fini>:
-  70:  e9 00 00 00 00          jmpq   75 <__libc_csu_fini+0x5>
-                       71: R_X86_64_PLT32      __x86_return_thunk-0x4
+  24:  48 83 ec 18             sub    $0x18,%rsp
+  28:  64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
+  2f:  00 00 
+  31:  48 89 44 24 08          mov    %rax,0x8(%rsp)
+  36:  31 c0                   xor    %eax,%eax
+  38:  e8 00 00 00 00          callq  3d <__libc_csu_init+0x3d>
+                       39: R_X86_64_PLT32      _init-0x4
+  3d:  48 c1 fd 03             sar    $0x3,%rbp
+  41:  74 20                   je     63 <__libc_csu_init+0x63>
+  43:  31 db                   xor    %ebx,%ebx
+  45:  0f 1f 00                nopl   (%rax)
+  48:  49 8b 04 dc             mov    (%r12,%rbx,8),%rax
+  4c:  48 83 c3 01             add    $0x1,%rbx
+  50:  4c 89 fa                mov    %r15,%rdx
+  53:  4c 89 f6                mov    %r14,%rsi
+  56:  44 89 ef                mov    %r13d,%edi
+  59:  e8 00 00 00 00          callq  5e <__libc_csu_init+0x5e>
+                       5a: R_X86_64_PLT32      __x86_indirect_thunk_rax-0x4
+  5e:  48 39 dd                cmp    %rbx,%rbp
+  61:  75 e5                   jne    48 <__libc_csu_init+0x48>
+  63:  48 8b 44 24 08          mov    0x8(%rsp),%rax
+  68:  64 48 33 04 25 28 00    xor    %fs:0x28,%rax
+  6f:  00 00 
+  71:  75 13                   jne    86 <__libc_csu_init+0x86>
+  73:  48 83 c4 18             add    $0x18,%rsp
+  77:  5b                      pop    %rbx
+  78:  5d                      pop    %rbp
+  79:  41 5c                   pop    %r12
+  7b:  41 5d                   pop    %r13
+  7d:  41 5e                   pop    %r14
+  7f:  41 5f                   pop    %r15
+  81:  e9 00 00 00 00          jmpq   86 <__libc_csu_init+0x86>
+                       82: R_X86_64_PLT32      __x86_return_thunk-0x4
+  86:  e8 00 00 00 00          callq  8b <__libc_csu_init+0x8b>
+                       87: R_X86_64_PLT32      __stack_chk_fail-0x4
+  8b:  0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
+
+0000000000000090 <__libc_csu_fini>:
+  90:  48 83 ec 18             sub    $0x18,%rsp
+  94:  64 48 8b 04 25 28 00    mov    %fs:0x28,%rax
+  9b:  00 00 
+  9d:  48 89 44 24 08          mov    %rax,0x8(%rsp)
+  a2:  31 c0                   xor    %eax,%eax
+  a4:  48 8b 44 24 08          mov    0x8(%rsp),%rax
+  a9:  64 48 33 04 25 28 00    xor    %fs:0x28,%rax
+  b0:  00 00 
+  b2:  75 09                   jne    bd <__libc_csu_fini+0x2d>
+  b4:  48 83 c4 18             add    $0x18,%rsp
+  b8:  e9 00 00 00 00          jmpq   bd <__libc_csu_fini+0x2d>
+                       b9: R_X86_64_PLT32      __x86_return_thunk-0x4
+  bd:  e8 00 00 00 00          callq  c2 <__libc_csu_fini+0x32>
+                       be: R_X86_64_PLT32      __stack_chk_fail-0x4
"""


This increases size of .symtab table by one symbol: __stack_chk_fail


$ diff -u <(readelf --syms executable_built_with_glibc_2.27) <(readelf --syms executable_built_with_glibc_2.29)
--- /dev/fd/63
+++ /dev/fd/62
@@ -1,5 +1,5 @@
 
-Symbol table '.dynsym' contains 6 entries:
+Symbol table '.dynsym' contains 7 entries:
    Num:    Value          Size Type    Bind   Vis      Ndx Name
      0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
      1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
@@ -7,8 +7,9 @@
      3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
      4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
      5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (2)
+     6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail@GLIBC_2.4 (3)
 
-Symbol table '.symtab' contains 36 entries:
+Symbol table '.symtab' contains 37 entries:
    Num:    Value          Size Type    Bind   Vis      Ndx Name
      0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
      1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
@@ -25,24 +26,25 @@
     12: 0000000000202008     0 OBJECT  LOCAL  HIDDEN    17 __dso_handle
     13: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test.c
     14: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
-    15: 0000000000200498     0 OBJECT  LOCAL  DEFAULT   12 __FRAME_END__
+    15: 00000000002004f8     0 OBJECT  LOCAL  DEFAULT   12 __FRAME_END__
     16: 0000000000202010     0 OBJECT  LOCAL  HIDDEN    18 __TMC_END__
-    17: 0000000000203008     0 NOTYPE  LOCAL  HIDDEN    21 __init_array_start
-    18: 0000000000203010     0 NOTYPE  LOCAL  HIDDEN    21 __init_array_end
-    19: 0000000000202010     0 NOTYPE  LOCAL  HIDDEN    19 _GLOBAL_OFFSET_TABLE_
-    20: 0000000000203010     0 NOTYPE  LOCAL  HIDDEN    22 _DYNAMIC
-    21: 00000000002011b0     5 FUNC    GLOBAL DEFAULT   13 __libc_csu_fini
-    22: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __gentoo_check_ldflags__
-    23: 0000000000201000    43 FUNC    GLOBAL DEFAULT   13 _start
-    24: 0000000000201140   102 FUNC    GLOBAL DEFAULT   13 __libc_csu_init
-    25: 0000000000201100    52 FUNC    GLOBAL DEFAULT   13 main
-    26: 0000000000202000     0 NOTYPE  WEAK   DEFAULT   17 data_start
-    27: 0000000000200460     4 OBJECT  GLOBAL DEFAULT   10 _IO_stdin_used
-    28: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main
-    29: 0000000000202000     0 NOTYPE  GLOBAL DEFAULT   17 __data_start
-    30: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
-    31: 00000000002011b8     0 FUNC    GLOBAL DEFAULT   14 _init
-    32: 00000000002011d0     0 FUNC    GLOBAL DEFAULT   15 _fini
+    17: 0000000000201204     0 FUNC    LOCAL  HIDDEN    14 _init
+    18: 000000000020121c     0 FUNC    LOCAL  HIDDEN    15 _fini
+    19: 0000000000203008     0 NOTYPE  LOCAL  HIDDEN    21 __init_array_start
+    20: 0000000000203010     0 NOTYPE  LOCAL  HIDDEN    21 __init_array_end
+    21: 0000000000202010     0 NOTYPE  LOCAL  HIDDEN    19 _GLOBAL_OFFSET_TABLE_
+    22: 0000000000203010     0 NOTYPE  LOCAL  HIDDEN    22 _DYNAMIC
+    23: 00000000002011d0    50 FUNC    GLOBAL DEFAULT   13 __libc_csu_fini
+    24: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  ABS __gentoo_check_ldflags__
+    25: 0000000000201000    43 FUNC    GLOBAL DEFAULT   13 _start
+    26: 0000000000201140   139 FUNC    GLOBAL DEFAULT   13 __libc_csu_init
+    27: 0000000000201100    52 FUNC    GLOBAL DEFAULT   13 main
+    28: 0000000000202000     0 NOTYPE  WEAK   DEFAULT   17 data_start
+    29: 00000000002004c0     4 OBJECT  GLOBAL DEFAULT   10 _IO_stdin_used
+    30: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main
+    31: 0000000000202000     0 NOTYPE  GLOBAL DEFAULT   17 __data_start
+    32: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     33: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
     34: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
     35: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf
+    36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail
$ diff -u <(readelf --sections executable_built_with_glibc_2.27) <(readelf --sections executable_built_with_glibc_2.29)
--- /dev/fd/63
+++ /dev/fd/62
...
@@ -56,11 +56,11 @@
   [25] .comment          PROGBITS         0000000000000000  000031b0
        0000000000000040  0000000000000001  MS       0     0     1
   [26] .symtab           SYMTAB           0000000000000000  000031f0
-       0000000000000360  0000000000000018          28    21     8
-  [27] .shstrtab         STRTAB           0000000000000000  00003550
+       0000000000000378  0000000000000018          28    23     8
+  [27] .shstrtab         STRTAB           0000000000000000  00003568
        0000000000000105  0000000000000000           0     0     1
-  [28] .strtab           STRTAB           0000000000000000  00003655
-       000000000000022b  0000000000000000           0     0     1
+  [28] .strtab           STRTAB           0000000000000000  0000366d
+       000000000000023c  0000000000000000           0     0     1
 Key to Flags:
   W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
   L (link order), O (extra OS processing required), G (group), T (TLS),
Comment 61 Andreas K. Hüttel archtester gentoo-dev 2019-03-07 00:11:54 UTC
Created attachment 568076 [details]
trivial prebuilt binary

> Maybe you could just add a trivial prebuilt amd64 binary (plus source for
> license reasons) for this.  Having it tested on one platform is better than
> none.

Here you are. Built with clang-6 and lld-6, on glibc-2.28. Sorry, I dont have any system with older glibc anymore.

huettel@pinacolada ~/Gentoo/bug-672918 $ ./test-bug-672918
TEST
huettel@pinacolada ~/Gentoo/bug-672918 $ # sandbox-2.13 with slyfox' patch
huettel@pinacolada ~/Gentoo/bug-672918 $ sandbox ./test-bug-672918
TEST
huettel@pinacolada ~/Gentoo/bug-672918 $ # sandbox-2.13, no patch
huettel@pinacolada ~/Gentoo/bug-672918 $ sandbox ./test-bug-672918
Sandboxed process killed by signal: Segmentation fault
Comment 62 tt_1 2019-03-07 07:34:31 UTC
I happen to have the same clang installed, but with older glibc-2.27, plus I haven't yet made the update to gcc-8.2, so clang-6 is built with gcc-7.3

The binary doesn't segfault within sandbox with that setup, but it does for the prebuilt binary from glibc-2.28, which is expected behavior I guess.
Comment 63 Sergei Trofimovich (RETIRED) gentoo-dev 2019-03-07 07:53:18 UTC
(In reply to Michał Górny from comment #59)
> Maybe you could just add a trivial prebuilt amd64 binary (plus source for
> license reasons) for this.  Having it tested on one platform is better than
> none.

Figuring out in the testsuite if test is failing legitimately or just due to platform mismatch will not be straightforward. For example on prefix INTERPRETER might not exist at embedded location and fail with NO_SUCH_FILE. Source file would not be enough to refresh a binary after minor toolchain changes.

> Or maybe you could achieve the same result with GNU ld via ldscripts.

Even if it's possible (by embedding explicit relative ordering into sections) linker scripts differ between arches and compilation modes. Up to the point that -pie linker script differs from -no-pie.
Comment 64 Sergei Trofimovich (RETIRED) gentoo-dev 2019-03-07 23:48:17 UTC
Created attachment 568154 [details, diff]
0002-configure.ac-add-lld-detection-support.patch

0002-configure.ac-add-lld-detection-support.patch adds lld detection support

With this change
    $ ./configure CC=clang LDFLAGS='-Wl,--hash-style=gnu -fuse-ld=lld'
    $ make check
exposes 36 test failures.

0001-exec-wrapper-add-support-for-GNU_HASH-parser.patch fixes all of them.


## ------------------------ ##
## sandbox 2.15 test suite. ##
## ------------------------ ##

  4: execv/1                                         ok
  1: access/1                                        FAILED (access.at:1)
  8: futimesat/1                                     ok
  3: chown/1                                         FAILED (chown.at:1)
  2: chmod/1                                         FAILED (chmod.at:1)
  6: fchownat/1                                      ok
  7: fchownat/2                                      ok
  5: fchmodat/1                                      ok
  9: futimesat/2                                     ok
 10: futimesat/3                                     ok
 12: link/1                                          FAILED (link.at:1)
 13: linkat/1                                        ok
 11: lchown/1                                        FAILED (lchown.at:1)
...
## ------------- ##
## Test results. ##
## ------------- ##

ERROR: All 87 tests were run,
35 failed unexpectedly.
## -------------------------- ##
## testsuite.log was created. ##
## -------------------------- ##

Please send `tests/testsuite.log' and all information you think might help:

   To: <sandbox@gentoo.org>
   Subject: [sandbox 2.15] testsuite: 1 2 3 11 12 17 18 19 20 21 26 27 29 31 32 33 34 35 36 37 38 39 40 46 47 48 52 53 62 71 75 81 82 83 84 failed
Comment 65 Larry the Git Cow gentoo-dev 2019-03-09 19:21:39 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=3c001036637930152c038d084334d9a7311ffc6e

commit 3c001036637930152c038d084334d9a7311ffc6e
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-03-07 23:41:54 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-03-08 07:35:55 +0000

    configure.ac: add lld detection support
    
    With this change
        $ ./configure CC=clang LDFLAGS='-Wl,--hash-style=gnu -fuse-ld=lld'
        $ make check
    exposes 35 test failures
    
    Bug: https://bugs.gentoo.org/672918
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 configure.ac | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=c8146cfbcd36f9be4a447bf057811fe2f6c543b2

commit c8146cfbcd36f9be4a447bf057811fe2f6c543b2
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-03-02 19:15:14 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-03-02 19:37:11 +0000

    exec wrapper: add support for GNU_HASH parser
    
    In bug #672918 exec's ELF parser was going out of symbol table
    range. It happened to trigger on a binary linked by LLVM's lld.
    
    sandbox has no precise way to determine symbol table size and
    uses the heuristic of detecting SYMTAB dynamic section size:
    STRTAB (or GNU_LIBLIST for prelinked binaries).
    
    This is a weak assumption and does not hold for lld-linked
    binaries where the ordering is SYMTAB->GNU_HASH->STRTAB.
    As a result sandbox SIGSEGVs when parses GNU_HASH as SYMTAB
    entries.
    
    The change adds GNU_HASH parser to iterate exactly through
    exported symbols. That way we avoid heuristic code completely.
    
    While at it repobe GNU_LIBLIST hack as we should not rely
    on size heuristics anymore.
    
    This has a nice side-effect of speeding up ELF parsing as
    GHU_HASH only iterates through exported symbols. HASH
    comparison has all dynamic symbols: both exported and
    imported.
    
    Reported-by: Dennis Schridde
    Bug: https://bugs.gentoo.org/672918
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 libsandbox/wrapper-funcs/__wrapper_exec.c | 108 ++++++++++++++++++++----------
 1 file changed, 71 insertions(+), 37 deletions(-)
Comment 66 Dennis Schridde 2019-03-09 20:22:06 UTC
(In reply to Larry the Git Cow from comment #65)
> The bug has been referenced in the following commit(s):
> 
> https://gitweb.gentoo.org/proj/sandbox.git/commit/
> ?id=3c001036637930152c038d084334d9a7311ffc6e
> 
> commit 3c001036637930152c038d084334d9a7311ffc6e
> Author:     Sergei Trofimovich <slyfox@gentoo.org>
> AuthorDate: 2019-03-07 23:41:54 +0000
> Commit:     Sergei Trofimovich <slyfox@gentoo.org>
> CommitDate: 2019-03-08 07:35:55 +0000
> [...]

Thanks!
Comment 67 Larry the Git Cow gentoo-dev 2019-03-10 10:38:24 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3446bb7f246a25f19b00403a9e9ffe3d87db9b16

commit 3446bb7f246a25f19b00403a9e9ffe3d87db9b16
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2019-03-10 10:36:42 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2019-03-10 10:38:05 +0000

    sys-apps/sandbox: Version bump
    
    No keywords yet, please test.
    
    Bug: https://bugs.gentoo.org/672918
    Package-Manager: Portage-2.3.62, Repoman-2.3.12
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 sys-apps/sandbox/Manifest            |  1 +
 sys-apps/sandbox/sandbox-2.16.ebuild | 76 ++++++++++++++++++++++++++++++++++++
 2 files changed, 77 insertions(+)
Comment 68 Larry the Git Cow gentoo-dev 2019-03-11 12:51:08 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=541e96f90d3ff61c4cf1424028c102d0a3737e50

commit 541e96f90d3ff61c4cf1424028c102d0a3737e50
Author:     Andreas K. Hüttel <dilfridge@gentoo.org>
AuthorDate: 2019-03-11 12:50:34 +0000
Commit:     Andreas K. Hüttel <dilfridge@gentoo.org>
CommitDate: 2019-03-11 12:50:34 +0000

    sys-apps/sandbox: Restore keywords; drop obsolete pch handling
    
    Bug: https://bugs.gentoo.org/672918
    Package-Manager: Portage-2.3.62, Repoman-2.3.12
    Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

 sys-apps/sandbox/sandbox-2.16.ebuild | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
Comment 69 Andreas K. Hüttel archtester gentoo-dev 2019-03-13 10:42:46 UTC
Since this is a) fixed in ~arch sandbox, and b) only affects a hand-tweaked configuration, I'm removing it as glibc-2.28-stable blocker.

Please upgrade to newest sandbox if you encounter this problem.
Comment 70 tt_1 2019-03-15 20:51:32 UTC
Everyone who's got the same issue as in the first post, which is that firefox can't properly detect SQLITE_SECURE_DELETE in systems sqlite package - I had the same error when attempting to cross-compile and got it fixed by getting rid of dev-util/pkgconf and going back to dev-util/pkgconfig. 

I may open a new bug for this.
Comment 71 Andreas K. Hüttel archtester gentoo-dev 2021-07-01 21:22:30 UTC
Going to close this as obsolete. If you still have similar issues, please file a new bug with recent logs.
Comment 72 SpanKY gentoo-dev 2021-10-22 04:26:40 UTC
*** Bug 640174 has been marked as a duplicate of this bug. ***