View previous topic :: View next topic |
Author |
Message |
hfk22 n00b
Joined: 02 Dec 2013 Posts: 42
|
Posted: Sun Aug 20, 2017 5:00 pm Post subject: Should the pax_kernel use flag be set on hardened profiles? |
|
|
Should the pax_kernel use flag be set on hardened profiles given that hardened-sources are being removed? I saw the message 2017-08-19-hardened-sources-removal today and that prompted me to move back to gentoo-sources. By doing that, I noticed that I needed to turn off the pax_kernel use flag to have nvidia-drivers install correctly. Anyway, I thought PAX was purely a hardened-sources thing, so does this mean that the use flag should be removed? |
|
Back to top |
|
|
toralf Developer
Joined: 01 Feb 2004 Posts: 3920 Location: Hamburg
|
Posted: Sun Aug 20, 2017 5:28 pm Post subject: Re: Should the pax_kernel use flag be set on hardened profil |
|
|
hfk22 wrote: | Should the pax_kernel use flag be set on hardened profiles given that hardened-sources are being removed? I saw the message 2017-08-19-hardened-sources-removal today and that prompted me to move back to gentoo-sources. By doing that, I noticed that I needed to turn off the pax_kernel use flag to have nvidia-drivers install correctly. Anyway, I thought PAX was purely a hardened-sources thing, so does this mean that the use flag should be removed? | By putting Code: | PAX_MARKINGS="none" | into /etc/portage/make.conf you shouldn't get any error messages, or ? |
|
Back to top |
|
|
hfk22 n00b
Joined: 02 Dec 2013 Posts: 42
|
Posted: Wed Aug 23, 2017 4:40 am Post subject: |
|
|
I just tried this and removed the flag -pax_kernel from nvidia-drivers. Unfortunately, it didn't work:
Code: | >>> Emerging (13 of 15) x11-drivers/nvidia-drivers-384.59-r1::gentoo
* NVIDIA-Linux-x86_64-384.59.run SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
* nvidia-settings-384.59.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
* Determining the location of the kernel source code
* Found kernel source directory:
* /usr/src/linux
* Found kernel object directory:
* /lib/modules/4.12.5-gentoo/build
* Found sources for kernel version:
* 4.12.5-gentoo
* Checking for suitable kernel configuration options... [ ok ]
* Checking for suitable kernel configuration options... [ ok ]
>>> Unpacking source...
>>> Unpacking NVIDIA-Linux-x86_64-384.59.run to /var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/work
>>> Unpacking nvidia-settings-384.59.tar.gz to /var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/work
>>> Source unpacked in /var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/work
>>> Preparing source in /var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/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-375.20-pax.patch ...
The text leading up to this was:
--------------------------
|diff -urp work.orig/kernel/nvidia-uvm/uvm_full_fault_buffer.h work/kernel/nvidia-uvm/uvm_full_fault_buffer.h
|--- work.orig/kernel/nvidia-uvm/uvm_full_fault_buffer.h 2016-11-27 21:56:50.399642330 +0100
|+++ work/kernel/nvidia-uvm/uvm_full_fault_buffer.h 2016-11-27 21:54:23.975709978 +0100
--------------------------
No file to patch. Skipping patch.
2 out of 2 hunks ignored [ !! ]
* ERROR: x11-drivers/nvidia-drivers-384.59-r1::gentoo failed (prepare phase):
* patch -p1 failed with /var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/files/nvidia-drivers-375.20-pax.patch
*
* Call stack:
* ebuild.sh, line 115: Called src_prepare
* environment, line 5016: Called eapply '/var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/files/nvidia-drivers-375.20-pax.patch'
* environment, line 1290: Called _eapply_patch '/var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/files/nvidia-drivers-375.20-pax.patch'
* environment, line 1228: Called __helpers_die 'patch -p1 failed with /var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/files/nvidia-drivers-375.20-pax.patch'
* isolated-functions.sh, line 117: Called die
* The specific snippet of code:
* die "$@"
*
* If you need support, post the output of `emerge --info '=x11-drivers/nvidia-drivers-384.59-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv '=x11-drivers/nvidia-drivers-384.59-r1::gentoo'`.
* The complete build log is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/temp/environment'.
* Working directory: '/var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/work'
* S: '/var/tmp/portage/x11-drivers/nvidia-drivers-384.59-r1/work/'
>>> Failed to emerge x11-drivers/nvidia-drivers-384.59-r1, Log file: |
To be clear, I removed the -pax_kernel use flag and only had PAX_MARKINGS="none" in make.conf. Certainly, everything is fine if I retain the -pax_kernel use flag. |
|
Back to top |
|
|
fedeliallalinea Administrator
Joined: 08 Mar 2003 Posts: 30837 Location: here
|
Posted: Wed Aug 23, 2017 6:17 am Post subject: |
|
|
You are sure that pax_kernel use flag of nvidia-drivers is disabled? Because
Code: | * Applying nvidia-drivers-375.20-pax.patch ... |
And ebuild try to apply patch only if pax_kernel is enabled
Code: | if use pax_kernel; then
ewarn "Using PAX patches is not supported. You will be asked to"
ewarn "use a standard kernel should you have issues. Should you"
ewarn "need support with these patches, contact the PaX team."
eapply "${FILESDIR}"/${PN}-375.20-pax.patch
fi |
If you want ago has created grsecurity-sources that applies last publicly available grsecurity patches. _________________ Questions are guaranteed in life; Answers aren't. |
|
Back to top |
|
|
hfk22 n00b
Joined: 02 Dec 2013 Posts: 42
|
Posted: Wed Aug 23, 2017 6:44 pm Post subject: |
|
|
Very clearly it's not. If I add -pax_kernel to my package.use file:
Code: | x11-drivers/nvidia-drivers -pax_kernel |
Everything works fine. My question is that whether this should be necessary given that hardened-sources are being removed. Even after hardened-sources are removed, there is still some benefit from using a hardened profile, but this profile currently sets pax_kernel and that seems to only make sense if one is using hardened-sources. |
|
Back to top |
|
|
NTU Apprentice
Joined: 17 Jul 2015 Posts: 187
|
Posted: Thu Aug 24, 2017 12:40 am Post subject: |
|
|
hfk22 wrote: | Even after hardened-sources are removed, there is still some benefit from using a hardened profile |
Eh, not any benefit you can't get from adding -fstack-protector-strong -fPIC -fPIE to C{XX}FLAGS and -fPIE -pie -Wl,-z,relro -Wl,-z,now to LDFLAGS. Plus, specifying those manually are more effective than simply using a hardened profile. The hardened profile sucks at applying SSP and PIE so I just use the vanilla profile with those flags, then a package.env file that excludes any packages that don't build with -fPIE -pie to a nopie.conf file (just -fPIC -fstack-protector-strong)
pax_kernel I never use because I've never fully dissected the 8/9MB mystery patch blob as provided by the grsec guys and don't use any of their code. I got about half way through and split their patch blob up into a bunch of pieces and broke it down but the project has crumbled apart since then so there's really no need to further dissect, plus a lot of those features have now been mainlined.
Cheers! |
|
Back to top |
|
|
Petross404 n00b
Joined: 27 Sep 2016 Posts: 55
|
Posted: Thu Mar 22, 2018 12:07 pm Post subject: |
|
|
NTU wrote: | hfk22 wrote: | Even after hardened-sources are removed, there is still some benefit from using a hardened profile |
Eh, not any benefit you can't get from adding -fstack-protector-strong -fPIC -fPIE to C{XX}FLAGS and -fPIE -pie -Wl,-z,relro -Wl,-z,now to LDFLAGS. Plus, specifying those manually are more effective than simply using a hardened profile. The hardened profile sucks at applying SSP and PIE so I just use the vanilla profile with those flags, then a package.env file that excludes any packages that don't build with -fPIE -pie to a nopie.conf file (just -fPIC -fstack-protector-strong)
|
Isn't putting manually "hardened" flags, not recommended by the Handbook? What makes so think that the profile is not sufficient? |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|