| doko | slangasek, the problem was that -fPIE couldn't be turned off in some situations. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70192. Strange that this didn't turn up during testing ... | 00:56 |
|---|---|---|
| ubottu | gcc.gnu.org bug 70192 in driver "-fno-pic doesn't work with --enable-default-pie" [Normal,Resolved: fixed] | 00:56 |
| slangasek | doko: hmm, what problem is that? | 00:57 |
| slangasek | missing context | 00:57 |
| doko | the kernel can't build with pie, so you have to turn it off | 00:57 |
| slangasek | ah, that one | 00:57 |
| doko | and every kernel module | 00:57 |
| slangasek | not automatable somehow? | 00:58 |
| slangasek | like, in the dkms package instead of fixing each module? | 00:58 |
| doko | well, lets fix the kernel first | 00:58 |
| doko | I could turn it off if I see some other options, like -ffreestanding, or -nostdlib. but I'm unsure how much I'll break which such automated guessing | 00:59 |
| === juliank is now known as Guest40488 | ||
| === juliank_ is now known as juliank | ||
| === Wulf4 is now known as Wulf | ||
| slangasek | LocutusOfBorg: fyi, LP: #1576914. Since I'm pretty sure this is a regression in a core package, I'm not inclined to remove the upstart binaries to work around it. | 02:19 |
| ubottu | Launchpad bug 1576914 in upstart (Ubuntu) "upstart,libnih ftbfs on s390x with linux 4.4.0-21.37" [Undecided,New] https://launchpad.net/bugs/1576914 | 02:19 |
| doko | slangasek, this could be automated: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1576915 | 02:29 |
| ubottu | Launchpad bug 1576915 in dpkg (Ubuntu) "dpkg-buildflags should explicitly pass -fno-PIE and -no-pie if DEB_BUILD_HARDENING_PIE=0 is set" [Undecided,New] | 02:29 |
| slangasek | doko: are those options defined somewhere, or are you proposing new options that don't currently exist in Debian? | 02:43 |
| doko | slangasek, well, DEB_BUILD_HARDENING_PIE seems to be documented. we should just adjust these to work when pie is the default | 02:44 |
| slangasek | the standard option I know about is DEB_BUILD_{MAINT_,}OPTIONS=hardening=-pie,-bindnow | 02:44 |
| slangasek | doko: documented where? | 02:45 |
| doko | hmm, I saw this in virtualbox ... | 02:45 |
| doko | LocutusOfBorg, ^^^ | 02:45 |
| slangasek | https://wiki.debian.org/Hardening documents DEB_BUILD_HARDENING_PIE, but that's hardening-wrapper, which is obsolete | 02:45 |
| doko | ahh | 02:46 |
| doko | slangasek, but in any case, =hardening=-pie should result in no pie flags | 02:46 |
| * slangasek nods | 02:47 | |
| doko | and I realize there is no way to turn off the -z now default :-/ | 02:47 |
| slangasek | doko: wouldn't that be -z lazy? | 02:47 |
| doko | ohh, was looking for nonow | 02:49 |
| slangasek | -z someothertime ;) | 02:49 |
| doko | one more thing for the gcc specs :-/ | 02:50 |
| doko | LocutusOfBorg, please teach virtualbox to pass the appropriate no pie flags | 02:56 |
| === athairus is now known as afkthairus | ||
| LocutusOfBorg | doko, ack | 08:46 |
| LocutusOfBorg | thanks | 08:46 |
| bigon | is anybody taking care of the selinux userspace in ubuntu (even if you are a apparmor shop?) | 09:12 |
| LocutusOfBorg | doko, it doesn't work | 09:20 |
| LocutusOfBorg | I don't have any fPIC fpic fpie fPIE references in the build log | 09:20 |
| LocutusOfBorg | but it fails anyway | 09:20 |
| LocutusOfBorg | trying -pic,-pie,-bindnow | 09:21 |
| cjwatson | cyphermox: ndisc6> go for it | 09:32 |
| abhinav-- | seeing this error in dmesg when trying to boot from 16.04 live USB traps: compiz[3446] trap invalid opcode ip:7fb11003e0e9 sp:7ffc1d32ec20 error:0 | 12:01 |
| abhinav-- | is this a known bug with? | 12:02 |
| === Cimi_ is now known as cimi | ||
| doko | gdal, json-c, cpl, cfitsio, ffmpeg, gsoap, libgetdata are now all entangled transitions | 14:00 |
| === afkthairus is now known as athairus | ||
| showaz | http://support.ntp.org/bin/view/Main/SecurityNotice#April_2016_NTP_4_2_8p7_Security | 17:04 |
| cjwatson | doko: at least the ffmpeg transition seems to be going relatively smoothly so far. I filed a Debian bug about the failing ffmpeg autopkgtest | 17:50 |
| cjwatson | will look at freshplayerplugin in the coming week | 17:51 |
| doko | yeah, I set up the tracker, and then noticed that you had already started :) | 20:34 |
| infinity | doko: Why do PIE executables think they're libraries? | 21:37 |
| doko | split personality | 21:37 |
| infinity | (base)adconrad@nosferatu:~$ readelf -a /usr/bin/wget | grep '^ Type:' | 21:38 |
| infinity | Type: DYN (Shared object file) | 21:38 |
| infinity | (base)adconrad@nosferatu:~$ readelf -a /bin/mv | grep '^ Type:' | 21:38 |
| infinity | Type: EXEC (Executable file) | 21:38 |
| infinity | It's rather irksome. | 21:38 |
| infinity | (I get that they're linked as shared objects, so technically are just like a PIC library, but I don't get why the ELF header has to be wrong too) | 21:39 |
| kees | infinity: they're both ET_DYN. it's been a bug that .so files were detected using the Type. | 21:40 |
| kees | i.e. this is, imo, a bug in readelf | 21:41 |
| === NCommander is now known as Guest14045 | ||
| infinity | kees: So, how would readelf go about telling the difference, then? | 21:46 |
| kees | infinity: I think the presence of DT_DEBUG | 22:19 |
| kees | $ readelf -d /usr/lib/x86_64-linux-gnu/libmirclient.so | fgrep '(DEBUG)' | 22:19 |
| kees | $ readelf -d /usr/bin/ssh | fgrep '(DEBUG)' | 22:19 |
| kees | 0x0000000000000015 (DEBUG) 0x0 | 22:19 |
| infinity | kees: binutils patch forthcoming? :) | 22:22 |
| infinity | kees: It's weird to see my system slowly shifting to being nothing but libraries (weirder still to see tools like lintian agree) | 22:22 |
| kees | I'm used to it at this point. :) chrome os has been default PIE since the beginning, and Android switched a few years ago too. | 22:23 |
| kees | it really confuses "file" :) | 22:23 |
| infinity | Quite. | 22:23 |
| infinity | file is where I first noticed it. | 22:24 |
| infinity | Which I assume it just using the same heuristic as readelf. | 22:24 |
| kees | yup. it just examines the elf type. fundamentally, there's no difference. | 22:24 |
| kees | it just happens that gcc drops in DT_DEBUG for executables for some reason | 22:24 |
| infinity | Still seems wrong to my that the ELF type is "shared object" (even if it technically is), but meh. | 22:25 |
| infinity | I wonder if the real definition of an ELF executable would be "any valid ELF type" + "has a PI entry". | 22:25 |
| infinity | Except that I've seen a ton of libraries with /lib/ld-linux PI entries, so there's a toolchain bug there too. :P | 22:26 |
| infinity | s/bug/misfeature/ ... It's not like it hurts for a library to have a PI, but it's also pointless. | 22:27 |
| kees | i'm misparsing. what do you mean by PI? I was reading it as "position independent" but "a PI" doesn't make sense to me now :) | 22:28 |
| infinity | kees: Program Interpreter. | 22:28 |
| kees | ah! | 22:28 |
| infinity | kees: ie: a binary shebang. | 22:28 |
| kees | right | 22:28 |
| infinity | Of course, static binaries also shouldn't have one, so that goes out the window. :P | 22:29 |
| kees | where does the PI show up? | 22:29 |
| infinity | But if the existence of (DEBUG) is a gcc oddity, that's also a broken heuristic. | 22:29 |
| kees | yeah, I'd rather have a better one | 22:29 |
| infinity | kees: I don't recall precisely where it shows up in the byte stream, file knows. | 22:30 |
| infinity | /bin/mv: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 | 22:30 |
| infinity | Since it extracts it. | 22:30 |
| kees | yeah... trying to find it in readelf... | 22:30 |
| infinity | But. Like I said, we seem to have a toolchain that bakes it into libraries too, so that's no help. :P | 22:30 |
| kees | oh, it does? ew | 22:31 |
| infinity | Oh. Maybe not. | 22:31 |
| infinity | It might just be needlessly linking libraries to it. | 22:31 |
| infinity | Which is fine. | 22:31 |
| LocutusOfBorg | can anybody with an s390x machine tell me why this package isn't installable? https://launchpad.net/ubuntu/+source/dolfin/1.6.0-1ubuntu5/+build/9621086 | 22:31 |
| LocutusOfBorg | Missing build dependencies: libslepc3.6.1-dev | 22:31 |
| infinity | http://paste.ubuntu.com/16160211/ | 22:33 |
| infinity | kees: ^-- So, quick random sample of a whole two files. Yes, libs are linked to ld-linux, but not listed as an interpreter. And file seems smart enough to point out interpreters even in "libraries" (PIE wget). | 22:33 |
| infinity | kees: So that may indeed by the right heuristic, since a PI implies executable, even if it's just because you misbuilt your library. ie: that may be a misbuild you'd want to know about anyway. | 22:34 |
| kees | infinity: yeah, I think that's correct. I still haven't found where that's listed in the various readelf options... | 22:34 |
| infinity | Or you may be a unique snowflake like libc, which is intentionally an executable library and, indeed, I think it should be detected as EXEC. | 22:35 |
| kees | Program headers, I think | 22:35 |
| kees | yeah, no INTERP program header. | 22:36 |
| kees | so, maybe even just INTERP or not... not need to check for ld-linux. | 22:36 |
| kees | which is, I think, what you just said. ;) | 22:36 |
| infinity | Right. | 22:38 |
| infinity | kees: Oh hey, since you're the resident expert on PIE... | 22:38 |
| * kees cringes | 22:38 | |
| infinity | kees: I understand why it's a massive performance hit on i386 (register pressure because, well, we have two), why is there not an i686 implementation that just absconds with an MMX register instead? | 22:38 |
| infinity | kees: Given our baseline is i686, that would seem like it should work... | 22:39 |
| kees | infinity: I don't know :) this is a question for the compiler gods. | 22:39 |
| infinity | kees: Also, your mention of ChromeOS and Android implies you're PIEing on armv7. Does that eat one of the vfp registers, or one of the gp registers (and did you benchmark it at all)? | 22:40 |
| kees | infinity: iirc, it eats a gp register. we don't care about the hit because PIE is more important. :) | 22:41 |
| kees | (though our ASLR entropy on armv7 is terrible) | 22:41 |
| infinity | kees: I feel like this is a thing we should turn on for all our arches (well, minus i386, unless we can get something magic like above), but I need a lot more info. | 22:41 |
| kees | it should be on for all archs including i386. ;) | 22:42 |
| infinity | Turning it on for i386, we may as well just drop i386, the hit's that bad. :/ | 22:42 |
| kees | nah | 22:42 |
| kees | but given most people are in a "who cares about i386?" mood, taking a perf hit doesn't bother them :) | 22:43 |
| infinity | I might make an executive decision as the powerpc community port maintainer to turn it on there. | 22:44 |
| infinity | But armv7, arm64, and i386 will take internal discussions. | 22:44 |
| kees | arm64 should be a no-brainer | 22:44 |
| infinity | I'm inclined to agree. It's just that doko and the security team only tested amd64 and ppc64el on the last pass, so those are the ones he enabled. | 22:45 |
| infinity | (And we did s390x out of the gate) | 22:45 |
| kees | no one has any arm64, so no one will notice a change. :) | 22:46 |
| infinity | We actually have a fair few installations out there. | 22:47 |
| infinity | Some reasonably large, even. | 22:47 |
| infinity | I was as puzzled as you to discover this. | 22:47 |
| infinity | That said, right after an LTS seems the best time to be switching. | 22:48 |
| infinity | People have two years to deal with the new world order. | 22:48 |
| kees | I love s390x | 22:56 |
| infinity | kees: I feel like there's a followup coming to turn that into a sarcastic statement. | 22:57 |
| kees | unrelated: I don't seem to be able to debootstrap yaketty right now. complains about deps | 22:57 |
| kees | infinity: no! the s390x hardware support in the kernel is great! they've had strong kernel memory permissions since forever, they have separate userspace and kernel space memory, etc etc | 22:57 |
| kees | much more hardened than x86 | 22:57 |
| infinity | Well, you have to look at the heritage. | 22:57 |
| infinity | The invented virtualization before we started copying BASIC programs from magazines. | 22:58 |
| infinity | The real disappointment is that it's taken everyone else so long to catch up. | 22:58 |
| infinity | They caught up to "mainframe performance", but skipped all the features. | 22:59 |
| infinity | s/The invented/They invented/ | 22:59 |
| infinity | kees: --variant=buildd, or a big, fat debootstrap? | 23:01 |
| infinity | kees: A buildd one just worked here. | 23:01 |
| * infinity tries a chubby one. | 23:01 | |
| infinity | kees: chubby debootstrap also succeeded, I blame your mirror. | 23:05 |
| kees | infinity: hmmm. I will double-check my mirror. I've been having .. Issues(tm) | 23:17 |
| kees | oh good, my mirror refresh just finished. debootstrap much happier now | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!