Output from our system checking script: file /lib64/udev/accelerometer does not have a PT_PAX_FLAGS program header, try conversion file /lib64/udev/scsi_id does not have a PT_PAX_FLAGS program header, try conversion file /lib64/udev/cdrom_id does not have a PT_PAX_FLAGS program header, try conversion file /lib64/udev/ata_id does not have a PT_PAX_FLAGS program header, try conversion file /lib64/udev/v4l_id does not have a PT_PAX_FLAGS program header, try conversion file /lib64/udev/mtd_probe does not have a PT_PAX_FLAGS program header, try conversion file /lib64/udev/collect does not have a PT_PAX_FLAGS program header, try conversion file /lib64/systemd/systemd-udevd does not have a PT_PAX_FLAGS program header, try conversion file /bin/udevadm does not have a PT_PAX_FLAGS program header, try conversion This is a hardened system, executables without a PAX header are considered illegal here. Udev is the only package which installs executables without PAX headers (except for packages installing precompiled binaries like jdk). Please compile udev correctly, like any other package does.
Does -flto break PAX? See the discussion in bug 502950. I've removed upstream adding -flto from sys-fs/udev's ebuild without a revbump: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-210.ebuild?r1=1.8&r2=1.9 Have you tried if re-emerging sys-fs/udev solves the problem? Let me know. Also post emerge --info output, and if the re-compile of udev didn't work, post complete build.log from it too.
Created attachment 372222 [details] emerge --info
Created attachment 372224 [details] Build log
Re-sync and re-emerge didn't change anything: Still no PAX headers.
(In reply to Klaus Kusche from comment #4) > Re-sync and re-emerge didn't change anything: Still no PAX headers. OK, then I don't know where the problem is. Same with udev-211? I'll leave this to hardened devs.
I was told at IRC: "afaik, nothing installed has pax headers unless it needs to be pax marked. I see no reason why udev would need to be pax marked. Additionally, pax header is only for pt pax marking, and hardened is moving to xattr (xt) pax marking. I have no idea what is "system checking script" is" so closing, if the only thing broken is your system checking script
Please re-check with hardened. Fact is, *every* executable on my system *has* Pax headers, no matter if it needs any special Pax marking or not, except the prebuilt Oracle JDK "jexec" executable, all the udev executables, a prebuilt Adobe Flash utility, and two firefox utility programs (?). And I didn't add these headers manually, the executables are automatically built with them by emerge. Even if I compile and link "hello world" manually by just writing "gcc hello.c", the resulting a.out automatically has Pax headers set to -------x-e--. So the udev ebuild is doing something special and odd. Our checking script just finds all binary executables on our system, applies paxctl -v to them, and lists any file which gives an error message or has unusual settings in its Pax headers. The rationale behind this is that anything not having Pax headers has not been compiled here and is alien and highly suspect, and anything having permissive headers needs to be whitelisted explicitely. The script supports a whitelist of specific files having nonstandard Pax header settings, but it doesn't support a whilelist of executables having no Pax headers at all, because this simply wasn't the case up to now. I could add one, but I first want to know why udev is so strange. xattr pax marking is a no-go here. Neither our filesystems nor our backups support xattr, so any xattr pax marking will fail or be lost.
Well, I can think of -Wl,-fuse-ld=gold that was added to 210 to use ld.gold instead of ld.bfd as a linker. Can you try adding something like: sed -i -e '/use-ld/s:gold:bfd:' configure To src_prepare() in udev's ebuild, or possibly just adding -Wl,-fuse-ld=bfd to LDFLAGS temporarily, does that make a difference? Verify you see bfd as last in the linker line in the build.log, otherwise gold is used. Plus, still, if the header is missing, but no pax marking is required, how is that a problem?
Gold don't have any pax header fix as bfd has.
(In reply to Magnus Granberg from comment #9) > Gold don't have any pax header fix as bfd has. that would explain it then. so, for long as udev doesn't need it's pax mark changed, use of gold is not a problem here, and the reporter got his explanation ;)
You got it. Adding LDFLAGS="-Wl,-fuse-ld=bfd" to make.conf did the trick, udev now has Pax headers. However, this is no clean solution, because now the linker is actually called with *both* options: ... -Wl,-fuse-ld=gold -Wl,-fuse-ld=bfd ... Obviously, the last one takes precedence. About your question "Plus, still, if the header is missing, but no pax marking is required, how is that a problem?" It is not a real problem with the udev executables per se. But it was the first time ever an ebuild produced executables without Pax headers here, so I suspected that something is strange. And, up to now, I used the presence of Pax headers as an indication for "most likely was compiled on this system with the usual binutils" and their absence as "definitely not compiled here, danger, doublecheck, this is something alien and suspect". My script removed the x-Perms until I whitelisted such executables explicitely.
well, expect more and more packages to utilize thistype of configure.ac code that first checks if -Wl,-fuse-ld=gold is supported by binutils or not, and if it is, then make use of it i was considering providing such a patch for Xfce upstream, as they already do automatic -Wl,--as-needed -Wl,-O1 linker optimizations like that, so might as well use gold if available
It sounds like the best solution here would be to patch gold to support the PaX stuff.
The PAX header is only needed when you need to relax the protection on the bin else it should have full protection.
Plus gold's going to become the default linker someday. Probably it won't be soon but it's worth noting.
How are feature requests submitted in gentoo?
(In reply to Michał Górny from comment #15) > Plus gold's going to become the default linker someday. Probably it won't be > soon but it's worth noting. Why? Anyhow, at least we're ready with xattr pax flags. (In reply to Klaus Kusche from comment #16) > How are feature requests submitted in gentoo? open a bug
(In reply to Anthony Basile from comment #17) > (In reply to Michał Górny from comment #15) > > Plus gold's going to become the default linker someday. Probably it won't be > > soon but it's worth noting. > > Why? Anyhow, at least we're ready with xattr pax flags. Does that mean that all my file systems, my backup software, and my network file sharing needs to support xattr? Currently, none of them does. So that's not the way to go for me. Even if I would enable xattr on my filesystems, xattr-stored Pax flags would be lost when resoring a system from backup, cloning a system, or accessing / distributing executables via network shares. Pax flags have to be in the file contents itself, nowhere else.
(In reply to Anthony Basile from comment #17) > (In reply to Michał Górny from comment #15) > > Plus gold's going to become the default linker someday. Probably it won't be > > soon but it's worth noting. > > Why? Anyhow, at least we're ready with xattr pax flags. Because it's better, obviously. People create the new linker to make it default someday, not to maintain a side project indefinitely for the fun of it. At least gold is required for LTO, and future versions of clang and gcc may require it for some other reasons -- due to plugin support.
(In reply to Klaus Kusche from comment #18) > (In reply to Anthony Basile from comment #17) > > (In reply to Michał Górny from comment #15) > > > Plus gold's going to become the default linker someday. Probably it won't be > > > soon but it's worth noting. > > > > Why? Anyhow, at least we're ready with xattr pax flags. > > Does that mean that all my file systems, my backup software, > and my network file sharing needs to support xattr? > > Currently, none of them does. > > So that's not the way to go for me. > > Even if I would enable xattr on my filesystems, > xattr-stored Pax flags would be lost when resoring a system from backup, > cloning a system, or accessing / distributing executables via network shares. > > Pax flags have to be in the file contents itself, nowhere else. Well you can buy time with --fuse-ld=bfd. Also, not every executable needs pax flags set. You only need pax flags for the *exceptional* cases where you need to relax, say mprotect. udev doesn't need any exceptions, so even without a PT_PAX_FLAGS program header to house the markings, it will run fine.
(In reply to Anthony Basile from comment #20) > (In reply to Klaus Kusche from comment #18) > > (In reply to Anthony Basile from comment #17) > > > (In reply to Michał Górny from comment #15) > > > > Plus gold's going to become the default linker someday. Probably it won't be > > > > soon but it's worth noting. > > > > > > Why? Anyhow, at least we're ready with xattr pax flags. > > > > Does that mean that all my file systems, my backup software, > > and my network file sharing needs to support xattr? > > > > Currently, none of them does. > > > > So that's not the way to go for me. > > > > Even if I would enable xattr on my filesystems, > > xattr-stored Pax flags would be lost when resoring a system from backup, > > cloning a system, or accessing / distributing executables via network shares. > > > > Pax flags have to be in the file contents itself, nowhere else. > > Well you can buy time with --fuse-ld=bfd. Also, not every executable needs > pax flags set. You only need pax flags for the *exceptional* cases where > you need to relax, say mprotect. udev doesn't need any exceptions, so even > without a PT_PAX_FLAGS program header to house the markings, it will run > fine. I would prefer cases needing nonstandard Pax flags to be exceptional, but unfortunately, they are not. I'm writing this from a system with the minimum software needed for daily use (we have much larger ones), but even here, the whitelist of my checking script contains more than 100 items. There are all the interpreters (python, lisp, all java exe's, ...), there are the web browsers, thunderbird, and the plugin container, there is libreoffice, there is google earth, there is gstreamer, there is gcc itself, some llvm parts, and valgrind, and some more. And that's with lua jit, regexp jit, opengl jit, etc. all turned off. And no matter if these cases are exceptional or not, xattr pax flags are not the way to go: If they do not work from fileshares, or if they are lost when restoring backups, they are a showstopper, no matter if this hits ten thousand files or just a single one. There is no standardized xattr support in NFSv3 (and never will), there is none in SMB which transparently works linux to linux, and none in AFS. scp and sftp also drop xattrs. There is no portable, standardized archive format (tar, cpio, zip) supporting xattr, only vendor-specific extensions to some tar implementations (not cpio). Try saving xattr's with star and reading them back with tar or vice versa... So xattr's are not the way to go, at least not for the next five years or so. gold should generate executables with pax headers.
