|
Description
Nick
2009-09-02 02:18:22 UTC
Exactly the same problem here. My workaround to this was that I performed the luksFormat operation on a non-hardened system and copied the contents of the block device in it's encrypted form to my hardened system. Opening the encrypted partition works just fine on hardened.. the only issue is that formatting crashes. ha-backup ~ # emerge --info Portage 2.1.6.13 (hardened/linux/amd64/10.0, gcc-4.3.4, glibc-2.10.1-r0, 2.6.28-hardened-r9 x86_64) ================================================================= System uname: Linux-2.6.28-hardened-r9-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4000+-with-gentoo-1.12.11.1 Timestamp of tree: Mon, 09 Nov 2009 12:30:02 +0000 app-shells/bash: 4.0_p28 dev-lang/python: 2.6.2-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=k8" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -march=k8" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://trumpetti.atm.tut.fi/gentoo/ http://trumpetti.atm.tut.fi/gentoo/ ftp://ftp.linux.ee/pub/gentoo/distfiles/" LDFLAGS="-Wl,-O1" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/etc/utils/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl amd64 berkdb bzip2 cli cracklib crypt dri gdbm gpm hardened iconv ipv6 justify mmx modules mudflap multilib ncurses nls nptl nptlonly openmp pam pcre perl pic pppd python readline reflection samba session spl sse sse2 ssl sysfs tcpd urandom usb xorg zeroconf zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="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 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Actually, this is a duplicate of bug #163803 Check also http://bugs.gentoo.org/show_bug.cgi?id=163803#c21 sys-fs/cryptsetup-1.0.7-r1 doesn't segfault like sys-fs/cryptsetup-1.0.6-r2 did :-) same here...it also segfaulted when adding new passphrase to an existing encrypted volume: "cryptsetup[24273] general protection ip:414546 sp:7ce812e04d38 error:0 in cryptsetup[400000+132000]" However, as per bug 163803 setting USE="dynamic" solved the issue! Should this flag be enforced on hardened? Created attachment 223227 [details]
emerge --info
(In reply to comment #4) > > However, as per bug 163803 setting USE="dynamic" solved the issue! > Should this flag be enforced on hardened? > Right, there's a problem with this approach though if one's using an encrypted root partition - genkernel requires cryptsetup to be build as static in order to include it in initramfs...which require cryptsetup to be rebuild with 'static' which prevents it from being able to run (change password), which again... :( (In reply to comment #21) > USE="dynamic" works for me too. > USE="dynamic" also allows me to use luksFormat on luffy (described in the original report) but this not a viable solution for me as luffy uses an encrypted root. I've tested both: Test setup: dd if=/dev/zero of=luksfs bs=1k count=10k 10240+0 records in 10240+0 records out 10485760 bytes (10 MB) copied, 0.0368618 s, 284 MB/s losetup /dev/loop/0 luksfs cryptsetup luksFormat /dev/loop/0 sys-fs/cryptsetup-1.0.7-r1: This produces the following output: cryptsetup luksFormat /dev/loop/0 WARNING! ======== This will overwrite data on /dev/loop/0 irrevocably. Are you sure? (Type uppercase yes): YES Segmentation fault strace -s 4096 cryptsetup luksFormat /dev/loop/0 execve("/sbin/cryptsetup", ["cryptsetup", "luksFormat", "/dev/loop/0"], [/* 25 vars */]) = 0 uname({sys="Linux", node="luffy", ...}) = 0 brk(0) = 0x2167000 brk(0x2167f90) = 0x2167f90 arch_prctl(ARCH_SET_FS, 0x2167890) = 0 brk(0x2188f90) = 0x2188f90 brk(0x2189000) = 0x2189000 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(2, "\nWARNING!\n========\n", 19 WARNING! ======== ) = 19 write(2, "This will overwrite data on /dev/loop/0 irrevocably.\n\nAre you sure? (Type uppercase yes): ", 90This will overwrite data on /dev/loop/0 irrevocably. Are you sure? (Type uppercase yes): ) = 90 fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb0d64c000 read(0, YES "YES\n", 1024) = 4 mlockall(MCL_CURRENT|MCL_FUTURE) = 0 open("/proc/devices", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb0d64b000 read(3, "Character devices:\n 1 mem\n 4 /dev/vc/0\n 4 tty\n 4 ttyS\n 5 /dev/tty\n 5 /dev/console\n 5 /dev/ptmx\n 7 vcs\n 10 misc\n 13 input\n 14 sound\n 21 sg\n 29 fb\n116 alsa\n128 ptm\n136 pts\n180 usb\n189 usb_device\n202 cpu/msr\n203 cpu/cpuid\n226 drm\n251 hidraw\n252 usbmon\n253 bsg\n254 rtc\n\nBlock devices:\n 1 ramdisk\n259 blkext\n 7 loop\n 8 sd\n 9 md\n 11 sr\n 65 sd\n 66 sd\n 67 sd\n 68 sd\n 69 sd\n 70 sd\n 71 sd\n128 sd\n129 sd\n130 sd\n131 sd\n132 sd\n133 sd\n134 sd\n135 sd\n253 device-mapper\n254 mdp\n", 1024) = 473 close(3) = 0 munmap(0x7feb0d64b000, 4096) = 0 open("/proc/misc", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb0d64b000 read(3, " 59 network_throughput\n 60 network_latency\n 61 cpu_dma_latency\n 62 device-mapper\n144 nvram\n228 hpet\n 63 autofs\n184 microcode\n227 mcelog\n", 1024) = 136 close(3) = 0 munmap(0x7feb0d64b000, 4096) = 0 stat("/dev/mapper/control", {st_mode=S_IFCHR|0660, st_rdev=makedev(10, 62), ...}) = 0 open("/dev/mapper/control", O_RDWR) = 3 uname({sys="Linux", node="luffy", ...}) = 0 open("/proc/devices", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feb0d64b000 read(4, "Character devices:\n 1 mem\n 4 /dev/vc/0\n 4 tty\n 4 ttyS\n 5 /dev/tty\n 5 /dev/console\n 5 /dev/ptmx\n 7 vcs\n 10 misc\n 13 input\n 14 sound\n 21 sg\n 29 fb\n116 alsa\n128 ptm\n136 pts\n180 usb\n189 usb_device\n202 cpu/msr\n203 cpu/cpuid\n226 drm\n251 hidraw\n252 usbmon\n253 bsg\n254 rtc\n\nBlock devices:\n 1 ramdisk\n259 blkext\n 7 loop\n 8 sd\n 9 md\n 11 sr\n 65 sd\n 66 sd\n 67 sd\n 68 sd\n 69 sd\n 70 sd\n 71 sd\n128 sd\n129 sd\n130 sd\n131 sd\n132 sd\n133 sd\n134 sd\n135 sd\n253 device-mapper\n254 mdp\n", 1024) = 473 close(4) = 0 munmap(0x7feb0d64b000, 4096) = 0 ioctl(3, DM_VERSION, 0x2168c90) = 0 ioctl(3, DM_LIST_VERSIONS, 0x2168be0) = 0 stat("/dev/loop/0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0 open("/dev/loop/0", O_RDWR|O_EXCL|O_SYNC|O_DIRECT) = 4 close(4) = 0 open("/dev/urandom", O_RDONLY) = 4 read(4, "\251.\240\232!A\221\2\343_$\251\261u\177\304", 16) = 16 read(4, "\4L\267-d\234\35\275%\252$ST:\252q\tB\n\275\344\202\34\203\272\26)\23)\223\277H", 32) = 32 open("/dev/urandom", O_RDONLY) = 5 fcntl(5, F_GETFD) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 getpid() = 19410 getuid() = 0 read(5, "0\21\220\204)\262\20\337\374\234\2152 \236)\235", 16) = 16 rt_sigaction(SIGVTALRM, {0x40b0c0, [VTALRM], SA_RESTORER|SA_RESTART, 0xf0000000fc0c748}, {SIG_DFL, [], 0}, 8) = 0 setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={1, 0}}, NULL) = 0 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Segmentation fault sys-fs/cryptsetup-1.1.0: cryptsetup luksFormat /dev/loop/0 WARNING! ======== This will overwrite data on /dev/loop/0 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Segmentation fault strace -s 4096 cryptsetup luksFormat /dev/loop/0 execve("/sbin/cryptsetup", ["cryptsetup", "luksFormat", "/dev/loop/0"], [/* 25 vars */]) = 0 uname({sys="Linux", node="luffy", ...}) = 0 brk(0) = 0x22ee000 brk(0x22eef90) = 0x22eef90 arch_prctl(ARCH_SET_FS, 0x22ee890) = 0 brk(0x230ff90) = 0x230ff90 brk(0x2310000) = 0x2310000 mlockall(MCL_CURRENT|MCL_FUTURE) = 0 getpriority(PRIO_PROCESS, 0) = 20 setpriority(PRIO_PROCESS, 0, 4294967278) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6eb020a000 write(1, "\n", 1 ) = 1 write(1, "WARNING!\n", 9WARNING! ) = 9 write(1, "========\n", 9======== ) = 9 write(1, "This will overwrite data on /dev/loop/0 irrevocably.\n\n", 54This will overwrite data on /dev/loop/0 irrevocably. ) = 54 fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6eb0209000 write(1, "Are you sure? (Type uppercase yes): ", 36Are you sure? (Type uppercase yes): ) = 36 read(0, YES "YES\n", 1024) = 4 stat("/dev/loop/0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0 open("/dev/loop/0", O_RDONLY|O_SYNC|O_DIRECT) = 3 ioctl(3, BLKSSZGET, 0x7fffed9a2604) = 0 fstatfs(3, {f_type=0x1021994, f_bsize=4096, f_blocks=2560, f_bfree=2494, f_bavail=2494, f_files=503289, f_ffree=501259, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 fstat(3, {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0 open("/proc/mounts", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6eb0208000 read(4, "rootfs / rootfs rw 0 0\n/dev/mapper/system-root / ext3 rw,noatime,errors=continue,data=ordered 0 0\nproc /proc proc rw,nosuid,nodev,noexec,relatime 0 0\nsysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0\nudev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0\ndevpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0\n/dev/mapper/system-usr /usr ext3 rw,noatime,errors=continue,data=ordered 0 0\n/dev/mapper/system-tmp /tmp ext3 rw,noatime,errors=continue,data=ordered 0 0\n/dev/mapper/system-var /var ext3 rw,noatime,errors=continue,data=ordered 0 0\n/dev/mapper/system-home /home ext3 rw,noatime,errors=continue,data=ordered 0 0\nshm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0\nusbfs /proc/bus/usb usbfs rw,nosuid,noexec,relatime,devgid=85,devmode=664 0 0\nbinfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0\n/dev/mapper/lvm0-data /data xfs rw,noatime,attr2,noquota 0 0\n/dev/mapper/backup /mnt/backup ext3 rw,relatime,errors=continue,data=ordered 0 0\n", 1024) = 1001 stat("/dev", {st_mode=S_IFDIR|0755, st_size=4000, ...}) = 0 close(4) = 0 munmap(0x7f6eb0208000, 4096) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 512) = 512 close(3) = 0 open("/proc/devices", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6eb0208000 read(3, "Character devices:\n 1 mem\n 4 /dev/vc/0\n 4 tty\n 4 ttyS\n 5 /dev/tty\n 5 /dev/console\n 5 /dev/ptmx\n 7 vcs\n 10 misc\n 13 input\n 14 sound\n 21 sg\n 29 fb\n116 alsa\n128 ptm\n136 pts\n180 usb\n189 usb_device\n202 cpu/msr\n203 cpu/cpuid\n226 drm\n251 hidraw\n252 usbmon\n253 bsg\n254 rtc\n\nBlock devices:\n 1 ramdisk\n259 blkext\n 7 loop\n 8 sd\n 9 md\n 11 sr\n 65 sd\n 66 sd\n 67 sd\n 68 sd\n 69 sd\n 70 sd\n 71 sd\n128 sd\n129 sd\n130 sd\n131 sd\n132 sd\n133 sd\n134 sd\n135 sd\n253 device-mapper\n254 mdp\n", 1024) = 473 close(3) = 0 munmap(0x7f6eb0208000, 4096) = 0 open("/proc/misc", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6eb0208000 read(3, " 59 network_throughput\n 60 network_latency\n 61 cpu_dma_latency\n 62 device-mapper\n144 nvram\n228 hpet\n 63 autofs\n184 microcode\n227 mcelog\n", 1024) = 136 close(3) = 0 munmap(0x7f6eb0208000, 4096) = 0 stat("/dev/mapper/control", {st_mode=S_IFCHR|0660, st_rdev=makedev(10, 62), ...}) = 0 open("/dev/mapper/control", O_RDWR) = 3 uname({sys="Linux", node="luffy", ...}) = 0 open("/proc/devices", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6eb0208000 read(4, "Character devices:\n 1 mem\n 4 /dev/vc/0\n 4 tty\n 4 ttyS\n 5 /dev/tty\n 5 /dev/console\n 5 /dev/ptmx\n 7 vcs\n 10 misc\n 13 input\n 14 sound\n 21 sg\n 29 fb\n116 alsa\n128 ptm\n136 pts\n180 usb\n189 usb_device\n202 cpu/msr\n203 cpu/cpuid\n226 drm\n251 hidraw\n252 usbmon\n253 bsg\n254 rtc\n\nBlock devices:\n 1 ramdisk\n259 blkext\n 7 loop\n 8 sd\n 9 md\n 11 sr\n 65 sd\n 66 sd\n 67 sd\n 68 sd\n 69 sd\n 70 sd\n 71 sd\n128 sd\n129 sd\n130 sd\n131 sd\n132 sd\n133 sd\n134 sd\n135 sd\n253 device-mapper\n254 mdp\n", 1024) = 473 close(4) = 0 munmap(0x7f6eb0208000, 4096) = 0 ioctl(3, DM_VERSION, 0x22f0100) = 0 ioctl(3, DM_LIST_VERSIONS, 0x22f0050) = 0 getuid() = 0 geteuid() = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 open("/dev/tty", O_RDWR) = 4 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(4, "Enter LUKS passphrase: ", 23Enter LUKS passphrase: ) = 23 ioctl(4, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0 read(4, "test\n", 512) = 5 ioctl(4, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 write(4, "\n", 1 ) = 1 close(4) = 0 open("/dev/tty", O_RDWR) = 4 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(4, "Verify passphrase: ", 19Verify passphrase: ) = 19 ioctl(4, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0 read(4, "test\n", 512) = 5 ioctl(4, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 write(4, "\n", 1 ) = 1 close(4) = 0 access("/etc/gcrypt/fips_enabled", F_OK) = -1 ENOENT (No such file or directory) open("/proc/sys/crypto/fips_enabled", O_RDONLY) = -1 ENOENT (No such file or directory) mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6eb0205000 getuid() = 0 mlock(0x7f6eb0205000, 16384) = 0 open("/dev/urandom", O_RDONLY) = 4 read(4, "U!\327\227\363\247%\10\360\304*0\2546\342\250\254\0233\260\6= \374\367@4\337\235\372\231\30", 32) = 32 read(4, "-3\320\270\365\307\2\24C\373(v\23Tn\357\304\223{x\244\324\276BY\203\313\36\345\262_\317", 32) = 32 rt_sigaction(SIGVTALRM, {0x411ac0, [VTALRM], SA_RESTORER|SA_RESTART, 0xf0000000fc0c748}, {SIG_DFL, [], 0}, 8) = 0 setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={1, 0}}, NULL) = 0 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Segmentation fault Below are results of running cryptsetup within GDB. It segfaults in pbkdf.c:247 which is a file in the 'luks' directory in cryptsetup source. It fails in the sigvtalarm() function which does a simple (?) assignment between two variables defined at the top of the file. Both vars are defined as: static volatile uint64_t __PBKDF2_global_j = 0; static volatile uint64_t __PBKDF2_performance = 0; GDB output: # gdb --args /sbin/cryptsetup luksFormat /dev/sdb1 GNU gdb (Gentoo 7.1.50.20100309 vanilla) 7.1.50.20100309 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /sbin/cryptsetup...done. (gdb) r Starting program: /sbin/cryptsetup luksFormat /dev/sdb1 WARNING! ======== This will overwrite data on /dev/sdb1 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Program received signal SIGSEGV, Segmentation fault. 0x0000000000413936 in sigvtalarm (foo=26) at pbkdf.c:247 247 } (gdb) bt #0 0x0000000000413936 in sigvtalarm (foo=26) at pbkdf.c:247 #1 0x0f0000000fc0c748 in ?? () #2 0x0000000000000000 in ?? () (gdb) i r rax 0x0 0 rbx 0x3 3 rcx 0x19 25 rdx 0x7fffffffce80 140737488342656 rsi 0x7fffffffcfb0 140737488342960 rdi 0x1a 26 rbp 0x7fffffffd490 0x7fffffffd490 rsp 0x7fffffffce78 0x7fffffffce78 r8 0x770e5140cf6b6d66 8578883678987054438 r9 0x99f93c86 2583248006 r10 0x0 0 r11 0x0 0 r12 0x7fffffffd2e0 140737488343776 r13 0xffffffff 4294967295 r14 0x1 1 r15 0x7fffffffd4e7 140737488344295 rip 0x413936 0x413936 <sigvtalarm+54> eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x0 0 (gdb) x/10i $rip-20 0x413922 <sigvtalarm+34>: mov 0x8(%rsp),%rax 0x413927 <sigvtalarm+39>: xor %fs:0x28,%rax 0x413930 <sigvtalarm+48>: jne 0x413937 <sigvtalarm+55> 0x413932 <sigvtalarm+50>: add $0x18,%rsp => 0x413936 <sigvtalarm+54>: retq 0x413937 <sigvtalarm+55>: callq 0x49e080 <__stack_chk_fail> 0x41393c <PBKDF2_HMAC_ready>: sub $0x18,%rsp 0x413940 <PBKDF2_HMAC_ready+4>: mov %fs:0x28,%rax 0x413949 <PBKDF2_HMAC_ready+13>: mov %rax,0x8(%rsp) 0x41394e <PBKDF2_HMAC_ready+18>: xor %eax,%eax (gdb) I can provide more info if needed but still no idea as to why it happens :) needs someone more knowledgeable... The actual error seems to be at line 270 of the pbkdf.c file as can be observed on the gdb output below: # gdb --args /sbin/cryptsetup luksFormat /dev/sdb1 GNU gdb (Gentoo 7.1.50.20100309 vanilla) 7.1.50.20100309 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /sbin/cryptsetup...done. (gdb) b PBKDF2_performance_check Breakpoint 1 at 0x413d45: file pbkdf.c, line 251. (gdb) r Starting program: /sbin/cryptsetup luksFormat /dev/sdb1 WARNING! ======== This will overwrite data on /dev/sdb1 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Breakpoint 1, PBKDF2_performance_check (hash=0x738c08 "sha1", iter=0x738fc0) at pbkdf.c:251 251 { (gdb) n 256 if (__PBKDF2_global_j) (gdb) n 259 if (!PBKDF2_HMAC_ready(hash)) (gdb) n 262 signal(SIGVTALRM,sigvtalarm); (gdb) n 263 it.it_interval.tv_usec = 0; (gdb) n 264 it.it_interval.tv_sec = 0; (gdb) n 265 it.it_value.tv_usec = 0; (gdb) n 266 it.it_value.tv_sec = 1; (gdb) n 267 if (setitimer (ITIMER_VIRTUAL, &it, NULL) < 0) (gdb) n 270 r = pkcs5_pbkdf2(hash, "foo", 3, "bar", 3, ~(0U), 1, &buf, 1); (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x0000000000413936 in sigvtalarm (foo=26) at pbkdf.c:247 247 } (gdb) bt #0 0x0000000000413936 in sigvtalarm (foo=26) at pbkdf.c:247 #1 0x0f0000000fc0c748 in ?? () #2 0x0000000000000000 in ?? () (gdb) i r rax 0x0 0 rbx 0x739af0 7576304 rcx 0x7fffffffd180 140737488343424 rdx 0x7fffffffce00 140737488342528 rsi 0x7fffffffcf30 140737488342832 rdi 0x1a 26 rbp 0x2 0x2 rsp 0x7fffffffcdf8 0x7fffffffcdf8 r8 0x77adc954 2007877972 r9 0xf3329947 4080179527 r10 0xa13671d0 2704699856 r11 0xdecce49 233623113 r12 0x739f88 7577480 r13 0x14 20 r14 0x1 1 r15 0x7fffffffd4e7 140737488344295 rip 0x413936 0x413936 <sigvtalarm+54> eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x0 0 (gdb) When compiled with USE="dynamic" it passes this instruction fine. The problem is occurring as part of the code's internal performance benchmarking of pkcs5_pbkdf2. (This is the Password-Based Key Derivation Function RFC 2898, where many iterations are done on a passphrase to generate the derived key DK.) The actual seg fault does occur on line 241 when calling sigvtalarm after signal(SIGVTALRM,sigvtalarm) which is set to fire after a 1 second delay. You can avoid the seg fault by lowering the number of iteration c of pkcs5_pbkdf2 when called on line 270. If one replaces r = pkcs5_pbkdf2(hash, "foo", 3, "bar", 3, ~(0U), 1, &buf, 1); with (for example) r = pkcs5_pbkdf2(hash, "foo", 3, "bar", 3, 100000, 1, &buf, 1); the seg fault is avoided. Lower numbers of iterations continue to avoid the seg fault while higher number eventually hit it. Why this is avoided when cryptsetup is dynamically linked and not statically is still unknown. I'm also now sure what the final fix should be because messing with the benchmarking may compromise the strength of the crypto. To make my previous comment clearer I wrote the following POC:
#include <signal.h>
#include <sys/time.h>
static volatile size_t global_count = 0;
static volatile size_t perf_count = 0;
static int looper( unsigned int c )
{
unsigned int i, rc = 0 ;
for (i = 1; i <= c; i++) {
if (perf_count) {
rc = i ;
goto out;
}
global_count++;
}
out:
return rc;
}
static void sigvtalarm(int foo)
{
perf_count = global_count;
}
int main()
{
int r;
struct itimerval it;
signal(SIGVTALRM,sigvtalarm);
it.it_interval.tv_usec = 0;
it.it_interval.tv_sec = 0;
it.it_value.tv_usec = 0;
it.it_value.tv_sec = 1;
if (setitimer (ITIMER_VIRTUAL, &it, 0) < 0)
return -1 ;
r = looper( ~(0U) ) ;
printf("perf_count = %ld\n", perf_count );
global_count = 0;
perf_count = 0;
return r;
}
If we compile this with gcc-4.3.4 or gcc-4.4.4-r1 dynamic/static, we get a reproduction of the seg fault:
yellowness tmp # gcc -o signaler signaler.c
signaler.c: In function ‘main’:
signaler.c:43: warning: incompatible implicit declaration of built-in function ‘printf’
yellowness tmp # ./signaler
perf_count = 444770828
yellowness tmp # gcc -static -o signaler signaler.c
signaler.c: In function ‘main’:
signaler.c:43: warning: incompatible implicit declaration of built-in function ‘printf’
yellowness tmp # ./signaler
Segmentation fault
However, if we use vanilla gcc-4.4.3-r2 then there is no problem:
basile@gentoo-dev ~ $ gcc -o signaler signaler.c
signaler.c: In function 'main':
signaler.c:43: warning: incompatible implicit declaration of built-in function 'printf'
signaler.c:43: warning: format '%ld' expects type 'long int', but argument 2 has type 'size_t'
basile@gentoo-dev ~ $ ./signaler
perf_count = 436764469
basile@gentoo-dev ~ $ gcc -static -o signaler signaler.c
signaler.c: In function 'main':
signaler.c:43: warning: incompatible implicit declaration of built-in function 'printf'
signaler.c:43: warning: format '%ld' expects type 'long int', but argument 2 has type 'size_t'
basile@gentoo-dev ~ $ ./signaler
perf_count = 442126054
Actually the problem is even deeper than my previous comments. The segfault occurs with ANY signal being caught by statically linked code. Here's the code to demonstrate:
/*
* Compile either
* 1. gcc -static -o poc poc.c
* 2. gcc -o poc poc.c
*
* When run, do kill -s 1 <pid>. Static
* give seg fault, dynamic is okay.
*
* Works with any signal, except non-blocking
*
*/
#include <signal.h>
#include <sys/types.h>
#include <unistd.h>
void sigvtalarm()
{
printf("s\n") ;
}
int main()
{
int i ;
printf("My PID = %d\n", getpid() ) ;
signal(1,sigvtalarm);
for (i = 1; ; i++) ;
return 0 ;
}
Created attachment 242993 [details]
signal.tar.bz2
if we look at the disassembly of __libc_sigaction in glibc and compare libc.so to libc.a, we see that the shared code (correctly) does:
db: 48 8d 05 2e ff ff ff lea -0xd2(%rip),%rax # 10 <__restore_rt>
while the static code (incorrectly) does:
db: 48 8b 05 2e ff ff ff mov -0xd2(%rip),%rax # 10 <__restore_rt>
the former will load the address of __restore_rt into %rax while the latter will load the code at the address of __restore_rt into %rax. this is why when we look at the stack, the return address is something like:
0x0f0000000fc0c748
this is the first 64bits of the opcodes of __restore_rt:
0000000000000010 <__restore_rt>:
10: 48 c7 c0 0f 00 00 00 mov $0xf,%rax
17: 0f 05 syscall
so it would seem gcc is miscompiling the x86_64 sigaction.c code. specifically, this bit of sysdeps/unix/sysv/linux/x86_64/sigaction.c:
...
extern void restore_rt (void) asm ("__restore_rt") attribute_hidden;
...
kact.sa_restorer = &restore_rt;
...
in the attached tarball, you can find the code to reproduce this behavior. assumption is that it is in an unpacked & configured glibc-2.11.2, but you should be able to experiment with just the .i files when compiling things by hand and looking at the output.
this happens on my system with a hardened gcc profile, not a vanilla or hardenednopie gcc profile (use gcc-config to change). so -fpie usage seems to be key to triggering the bug.
From bug PR45286
Re: #c12, the difference is because the source code is different.
In the first preprocessed source, restore_rt isn't hidden, in the latter it is.
So, in the first case (-fPIE) gcc can't assume __restore_rt is defined in the
same shared library or binary, in the latter case it can.
Shorter testcase is:
extern void foo (void) asm ("baz")
#ifdef HIDDEN
__attribute__((visibility ("hidden")))
#endif
;
void *bar (void)
{
return &foo;
}
asm (".text; .type baz, @function; baz: nop; .previous");
-fpie vs. -fpic -DHIDDEN, the only difference is again:
- movq baz@GOTPCREL(%rip), %rax
+ leaq baz(%rip), %rax
So, if there is any bug, it is either on the assembler/ld side, or on the glibc
side or user side, compiling glibc in a way it was never meant to be compiled.
@vapier have you any idea what to do next? Compile the libc.a with -fPIC insted or build it with -nopie? *** Bug 333173 has been marked as a duplicate of this bug. *** This need to be fixed in as or glibc. Glibc 1. Do we compile sigaction.o with -nopie 2. Split out lib*.a from the objectfiles and compile it with -nopie Created attachment 247070 [details, diff]
updated patch with the fix for sigaction
added a fix for sigaction in the hardened-pie patch
don't know if this is okey with toolchain or we need make some else fix.
*** Bug 209979 has been marked as a duplicate of this bug. *** *** Bug 351843 has been marked as a duplicate of this bug. *** This issue also occurred some time ago with sigalarm as in http://www.linuxquestions.org/questions/slackware-14/slackware-64-static-compilation-broken-803845/ For me, it showed up in July 2010 with fbsplash, being linked statically against glibc on hardened x86_64. The problem seems to be that the relocation information is lost when statically binding glibc against some programs when using position independent code and using sigalarm, which uses 64-bit instruction pointer relative adressing in a wrong way, which is only possible for x86_64. In sigalarm.c, the usage of extern void restore_rt (void) asm ("__restore_rt") attribute_hidden; where attribute_hidden is curiously not defined, seems to imply that the symbol does not appear in the right way on the outer interface of sigaction.o . The problem is, that the linker does not resolve the relocation information (for the callback of sigalarm) in the right way and produces a callback address for the kernel syscall binding, which is no address but the move instruction at that point (which should move the call back address to register rax). 0xffc0c748 : xxxxxx: 48 c7 c0 xx xx xx xx mov xx,%rax xxxxxx: 0f 05 syscall The linker should replace this address xx xx xx xx by the real call back address to resume the program on return from the system call, but fails to do so. Two ways have proven to solve the problem of wrong adressing of __restore_rt in sigaction.c for me with hardened gentoo with pic on x86_64: First: fixed replacement of 'attribute_hidden' by '__attribute__((__visibility__("hidden")))' Second: Making the symbol __restore_rt global and shown in the global offset table by the following patch. Created attachment 260620 [details, diff]
patch to give linker a hint for correct relocation info of __restore_rt
(In reply to comment #22) > Created an attachment (id=260620) [details] > patch to give linker a hint for correct relocation info of __restore_rt > Zorry and I both tested this patch and it worked. We both tested on amd64. Created attachment 261195 [details, diff] This patch has the attachment 260620 [details, diff] in it. Thanks for the help and hint squeezy Created attachment 261197 [details, diff] This patch has the attachment 260620 [details, diff] in it. Fix some typos in the last patch. Created attachment 261199 [details, diff]
Patch with fixed spacing
The previous didn't apply due to bad spacing copypasta. This ought to fix that :D
Created attachment 261200 [details, diff]
Doing things well, forgot a few details :P
Created attachment 264219 [details, diff] fix the attribute_hidden on __restore_rt We only need one fix __attribute__((__visibility__("hidden"))); see comment 21 patch is in glibc-2.13-r2 It is now July 2011 and sys-libs/glibc is still 2.12.2 in portage as the most recent not masked glibc. So, this problem still exist for crypt users with harden. At least for me. The patch that was tested on amd64 no longer works. i've used it before successfully. i don't know why it doesn't work anymore. localhost cryptsetup # USE="static-libs" emerge cryptsetup * IMPORTANT: 2 news items need reading for repository 'gentoo'. * Use eselect news to read news items. * IMPORTANT: config file '/etc/portage/savedconfig/sys-apps/busybox-1.17.4' needs updating. * See the CONFIGURATION FILES section of the emerge * man page to learn how to update config files. Calculating dependencies... done! >>> Verifying ebuild manifests >>> Emerging (1 of 1) sys-fs/cryptsetup-1.1.3-r3 * cryptsetup-1.1.3.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * Package: sys-fs/cryptsetup-1.1.3-r3 * Repository: gentoo * Maintainer: base-system@gentoo.org * USE: amd64 elibc_glibc kernel_linux multilib nls selinux userland_GNU * FEATURES: sandbox selinux sesandbox * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.37-hardened-r7/build * Found sources for kernel version: * 2.6.37-hardened-r7 * Checking for suitable kernel configuration options... [ ok ] >>> Unpacking source... >>> Unpacking cryptsetup-1.1.3.tar.bz2 to /var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/work >>> Source unpacked in /var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/work >>> Preparing source in /var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/work/cryptsetup-1.1.3 ... * Running elibtoolize in: cryptsetup-1.1.3/ * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... * Applying newpatch.patch ... * Failed Patch: newpatch.patch ! * ( /usr/portage/sys-fs/cryptsetup/files/newpatch.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/temp/newpatch.patch.out * ERROR: sys-fs/cryptsetup-1.1.3-r3 failed (prepare phase): * Failed Patch: newpatch.patch! * * Call stack: * ebuild.sh, line 56: Called src_prepare * environment, line 3475: Called epatch '/usr/portage/sys-fs/cryptsetup/files/newpatch.patch' * environment, line 1840: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * * If you need support, post the output of 'emerge --info =sys-fs/cryptsetup-1.1.3-r3', * the complete build log and the output of 'emerge -pqv =sys-fs/cryptsetup-1.1.3-r3'. * The complete build log is located at '/var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/temp/environment'. * S: '/var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/work/cryptsetup-1.1.3' >>> Failed to emerge sys-fs/cryptsetup-1.1.3-r3, Log file: >>> '/var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/temp/build.log' * Messages for package sys-fs/cryptsetup-1.1.3-r3: * Failed Patch: newpatch.patch ! * ( /usr/portage/sys-fs/cryptsetup/files/newpatch.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/temp/newpatch.patch.out * ERROR: sys-fs/cryptsetup-1.1.3-r3 failed (prepare phase): * Failed Patch: newpatch.patch! * * Call stack: * ebuild.sh, line 56: Called src_prepare * environment, line 3475: Called epatch '/usr/portage/sys-fs/cryptsetup/files/newpatch.patch' * environment, line 1840: Called die * The specific snippet of code: * die "Failed Patch: ${patchname}!"; * * If you need support, post the output of 'emerge --info =sys-fs/cryptsetup-1.1.3-r3', * the complete build log and the output of 'emerge -pqv =sys-fs/cryptsetup-1.1.3-r3'. * The complete build log is located at '/var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/temp/environment'. * S: '/var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/work/cryptsetup-1.1.3' * IMPORTANT: 2 news items need reading for repository 'gentoo'. * Use eselect news to read news items. localhost cryptsetup # Created attachment 280985 [details]
cat /var/tmp/portage/sys-fs/cryptsetup-1.1.3-r3/temp/newpatch.patch.out
Created attachment 280987 [details]
emerge --info =sys-fs/cryptsetup-1.1.3-r3
Created attachment 280989 [details]
make.info, uname -a, emerge --info
this bug has nothing to do with cryptsetup. please stop spamming that stuff. The original author, Nick, who filed this bug stated: "Trying to run the following command always results in the following: luffy ~ # /sbin/cryptsetup --cipher=aes-cbc-essiv:sha256 -s 256 luksFormat /dev/md0 WARNING! ======== This will overwrite data on /dev/md0 irrevocably. Are you sure? (Type uppercase yes): YES Segmentation fault (core dumped)" Did you not see that this was reported by Nick on 2009-09-02 02:18? Did not you see that he when filed this bug because he stated he was trying to encrypt his partition with cryptsetup and it segfaulted? Instead of accusing me of spamming, why not maintain this and fix it? If all you can do is accuse me of spamming in which I had the same problem as Nick just a couple of months ago, then it explains why this bug has dated back to 2009 and still has not been fixed. (In reply to comment #37) > The original author, Nick, who filed this bug stated: > "Trying to run the following command always results in the following: > > luffy ~ # /sbin/cryptsetup --cipher=aes-cbc-essiv:sha256 -s 256 luksFormat > /dev/md0 > > WARNING! > ======== > This will overwrite data on /dev/md0 irrevocably. > > Are you sure? (Type uppercase yes): YES > Segmentation fault (core dumped)" > > > > Did you not see that this was reported by Nick on 2009-09-02 02:18? Did not you > see that he when filed this bug because he stated he was trying to encrypt his > partition with cryptsetup and it segfaulted? > > Instead of accusing me of spamming, why not maintain this and fix it? If all > you can do is accuse me of spamming in which I had the same problem as Nick > just a couple of months ago, then it explains why this bug has dated back to > 2009 and still has not been fixed. The reason you are not getting a response from the devs is because you don't understand what's going on and stubbornly refuse to listen to us. The problem is triggered by cryptsetup, but it is in glibc. If you look at my POC in comment 11 and comment 12, you will see *other* programs that trigger this same error. Note that the patch is in glibc-2.13-r2 so it is fixed if you upgrade to. Finally, stop spamming this bug. It forces people reading it to have to waste time skipping over the useless information. *** Bug 383599 has been marked as a duplicate of this bug. *** Current stable glibc is 2.15-r3. I can't see, why this was not closed already, as there is a fix released and all users should have received it. Am I missing something? (In reply to Manuel Ullmann from comment #40) the patch in the tree is a hack. we don't know why it makes things work. more analysis is necessary so we can find the true source of the bug. have updated the upstream bug if it works on gcc 6.x and trunk glibc. Looks like it is fixed in glibc 2.22 |
