* Failed Patch: nvidia-drivers-355.06-pax.patch ! * ( /usr/portage/x11-drivers/nvidia-drivers/files/nvidia-drivers-355.06-pax.patch ) * * Include in your bugreport the contents of: * $ cat ./info.txt ----------------------------------------------------------------- This is an unstable amd64 chroot image (named amd64-hardened-unstable_20160110-215200) at a hardened host acting as a tinderbox. ----------------------------------------------------------------- Portage 2.2.26 (python 3.4.3-final-0, hardened/linux/amd64, gcc-5.3.0, glibc-2.22-r1, 4.3.3-hardened-r4 x86_64) ================================================================= System uname: Linux-4.3.3-hardened-r4-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 16164680 total, 502176 free KiB Swap: 16777212 total, 16739064 free Timestamp of repository gentoo: Mon, 11 Jan 2016 22:43:25 +0000 sh bash 4.3_p42-r1 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p42-r1::gentoo dev-java/java-config: 2.2.0::gentoo dev-lang/perl: 5.22.1::gentoo dev-lang/python: 2.7.11-r2::gentoo, 3.4.3-r7::gentoo dev-util/cmake: 3.4.1::gentoo dev-util/pkgconfig: 0.29::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.19.1::gentoo sys-apps/sandbox: 2.10-r1::gentoo sys-devel/autoconf: 2.69-r1::gentoo sys-devel/automake: 1.11.6-r2::gentoo, 1.13.4-r1::gentoo, 1.14.1-r1::gentoo, 1.15-r1::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.9.3::gentoo, 5.3.0::gentoo sys-devel/gcc-config: 1.8::gentoo sys-devel/libtool: 2.4.6-r1::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers) sys-libs/glibc: 2.22-r1::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.de.gentoo.org/gentoo-portage/ priority: 1 local location: /usr/local/portage masters: gentoo priority: 2 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/apache2-php7.0/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cgi-php7.0/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/php/cli-php7.0/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/var/tmp/distfiles" EMERGE_DEFAULT_OPTS="--verbose-conflicts --deep --color=n --nospinner --tree --quiet-build --accept-properties=-interactive --accept-restrict=-fetch" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync network-sandbox news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo rsync://mirror.netcologne.de/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gor.bytemark.co.uk/gentoo/ rsync://ftp.snt.utwente.nl/gentoo" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j1" PKGDIR="/usr/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" PORTAGE_TMPDIR="/var/tmp" USE="X acl amd64 avcodec avformat berkdb bindist btrfs bzip2 cairo cdda cddb cli consolekit cracklib crypt cxx dbus dri drmkms egl evdev extraengine ftp gdbm gles2 gnuplot gpg gtkstyle hardened help hpn iconv ipv6 ithreads javascript jpeg justify libvirtd melt mikmod mmx mmxext modules multilib ncurses nls nptl openmp pam pax_kernel pcre pie pkcs11 pulseaudio pyqt4 qemu qt3support qt4 readline sddm sdl seccomp session source sse sse2 sse4 sse4_2 ssl ssp system-cairo tcpd tls unicode urandom usb uxa v4l vaapi wav xattr xtpax zlib" ABI_X86="64" 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" 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="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_GB" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="intel i965" 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, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 422676 [details] emerge-history.txt
Created attachment 422678 [details] environment
Created attachment 422680 [details] nvidia-drivers-355.06-pax.patch.out
Created attachment 422682 [details] x11-drivers:nvidia-drivers-361.16:20160112-020813.log
The patch fails on both nvidia-drivers-361.16 and nvidia-drivers-361.18. It applies to nvidia-drivers-358.16-r1, but that package doesn't build (kernel too recent, probably). nvidia-drivers-355.11-r2 also doesn't build. It would be nice if the package maintainer tested that the pax patch at least still applies before bumping it... this isn't the first time this happens. I know this is nvidia and all, but it's kind of unfortunate to be left without any buildable versions, because the older ones are too old and the newer ones fail the patch.
Sigh. Well, this is a different bug, but the two problem versions don't even build without USE=pax_kernel. Turns out ACCESS_ONCE needs to be replaced with ACCESS_ONCE_RW in two places...
i already published an updated patch: https://grsecurity.net/~paxguy1/nvidia-drivers-361.18-pax.patch
Soooo... having been 18 days since the patch has been available and nearly a fortnight since the fix for this bug presented itself, could we maybe push this a little towards the front of the queue? I'm know that it's not polite to cut in line, but could we maybe bump the priority to "high" and lower the severity to "trivial?" I'm not trying to be rude or anything, but...the bleeding edge is where the party's at and this bug's killin' the mood dawg.
(In reply to jeremiah from comment #8) > I'm not trying to be rude Thank you for explaining that.
Yes it would be rather helpful if we could push this patch into the tree by now, I've even tested the 361.18-pax-patch on the latest nvidia-drivers-361.28-r2 update as well as the previous driver at nvidia-drivers-358.16-r1 and with that patch in place the emerge completes successfully. The fix is simply a one line fix in the ebuild at line 174 and the addition of the pax-patch in the x11-drivers/nvidia-drivers/files location.
(In reply to Francis Booth from comment #10) > I've even tested the 361.18-pax-patch on the latest nvidia-drivers-361.28-r2 update i wonder how that could have worked as that version requires a new patch (it's at the usual place).
(In reply to PaX Team from comment #11) > (In reply to Francis Booth from comment #10) > > I've even tested the 361.18-pax-patch on the latest nvidia-drivers-361.28-r2 update > i wonder how that could have worked as that version requires a new patch > (it's at the usual place). I was actually just about to say that. I thought I was missing something, I thought I was going crazy as your right the patch was not working for the latest revision. Thanks for the heads up.
There is patch in grsecurity upstream. You can find it in: https://www.grsecurity.net/~paxguy1/ Actually, there is also patch for 361.28 too. https://www.grsecurity.net/~paxguy1/nvidia-drivers-361.28-pax.patch And it works well in my system.
*** Bug 575488 has been marked as a duplicate of this bug. ***
Now stable users are affected by this problem with commit: https://github.com/gentoo/gentoo/commit/40d70bd2641e07f1a4009ea15b20b8b6bbfcc3b9 because nvidia-drivers-361.28 went stable. [ebuild U ] x11-drivers/nvidia-drivers-361.28:0/361::gentoo [358.16-r1:0/358::gentoo] USE="X acpi driver%* gtk3 kms multilib pax_kernel tools -static-libs% -uvm (-gtk2%)" 0 KiB * Found sources for kernel version: * 4.4.2-hardened >>> Unpacking source... >>> Unpacking NVIDIA-Linux-x86_64-361.28.run to /var/tmp/portage/x11-drivers/nvidia-drivers-361.28/work >>> Unpacking nvidia-settings-361.28.tar.bz2 to /var/tmp/portage/x11-drivers/nvidia-drivers-361.28/work >>> Source unpacked in /var/tmp/portage/x11-drivers/nvidia-drivers-361.28/work >>> Preparing source in /var/tmp/portage/x11-drivers/nvidia-drivers-361.28/work ... * Using PAX patches is not supported. You will be asked to * use a standard kernel should you have issues. Should you * need support with these patches, contact the PaX team. * Applying nvidia-drivers-355.06-pax.patch ... * Failed Patch: nvidia-drivers-355.06-pax.patch ! * ( /mnt/sda7/portage/x11-drivers/nvidia-drivers/files/nvidia-drivers-355.06-pax.patch )
Created attachment 428746 [details] nvidia-drivers-355.06-pax.patch.out
Will add the new patches to 361.28-r2 and 364.12 Jer is that okay?
"Jer" - Error: ambiguous nickname
The patch has the wrong filename in ~364.12. It asks for "nvidia-drivers-361.26-pax.patch" but the patch is '361.28'.
(In reply to jeremiah from comment #19) > The patch has the wrong filename in ~364.12. It asks for > "nvidia-drivers-361.26-pax.patch" but the patch is '361.28'. That seems to be a typo. Sorry about that.
To anyone complaining about the delays: the Hardened team is supposed to take care of these patches and hasn't done so in a while. I (currently) don't use this combination of nvidia-drivers + hardened, and there is always an additional delay between new driver versions and appropriate patches appearing on the 'Net. The best I can do for this patch integration is a "patch test": does the patch apply, then it is probably OK. I can't run a compile test let alone a run test with these patches. I am all for dropping the hardened patches altogether and force hardened users to use epatch_user instead, since I can't guarantee that nvidia-drivers will work with whatever patch Some Guy on the 'Net publishes. That said, I fixed the 364 PaX patch.
(In reply to Jeroen Roovers from comment #21) > I am all for dropping the hardened patches altogether and force hardened > users to use epatch_user instead, since I can't guarantee that > nvidia-drivers will work with whatever patch Some Guy on the 'Net publishes. As for me, as one of hardened+nvidia user, epatch_user is fine if ebuild will ewarn with details of where we can manually download patches. > That said, I fixed the 364 PaX patch. Thanks!
(In reply to Jeroen Roovers from comment #21) > I am all for dropping the hardened patches altogether and force hardened > users to use epatch_user instead, since I can't guarantee that > nvidia-drivers will work with whatever patch Some Guy on the 'Net publishes. that 'Some Guy' happens to be me who's not only an nvidia user but also the author of PaX and tends to make sure that his code works. PS: one would think that someone who just the other day was complaining about someone else being rude to him would not do the same himself.
(In reply to PaX Team from comment #23) > (In reply to Jeroen Roovers from comment #21) > > I am all for dropping the hardened patches altogether and force hardened > > users to use epatch_user instead, since I can't guarantee that > > nvidia-drivers will work with whatever patch Some Guy on the 'Net publishes. > that 'Some Guy' happens to be me who's not only an nvidia user but also the > author of PaX and tends to make sure that his code works. > > PS: one would think that someone who just the other day was complaining > about someone else being rude to him would not do the same himself. Oi! Rather than devolving to complaining like a (l)user like I did, let's approach this like the sysadmins/programmers/engineers we are: make the computer do it. Why spend 3 hours doing something by hand when we can spend 3+ months designing and implementing a way to automate it? :) Off the top of my head: a tool tor upstream devs that produces a parsable, PGP-signed, RSS/Atom announce feed and a tool for distros that parses such feeds and auto-adds the package/patch/news/security advisories/changelog/release notes to the relevant branch(es)
(In reply to PaX Team from comment #23) > > nvidia-drivers will work with whatever patch Some Guy on the 'Net publishes. > PS: one would think that someone who just the other day was complaining > about someone else being rude to him would not do the same himself. I don't see anything rude there, so maybe you shouldn't either.
I wasn't trying to stop any rudeness, just the ad hominem attacks. Fight on the merits, not the presentation. Personally, I follow the opinions that: It's acceptable to be an a$$hole, as long as you're a correct a$$hole; and: If you make an argument but you can't make it in a meritorious manner, GTFO. I thought that bringing attention to my own rudeness while giving a possible out to the argument would nip what seemed to be a baseless spat in the bud. Also, I wanted to plug a random idea.
