please mark stable/unmask
-r8 fixes issues in above url
Updating summary to reference 2.6.23-r9 (which has recently been committed).
-r9 will be what we would like to begin targeting stable testing for a few weeks.
A vote of confidence from the PPC camp would be most welcome :)
Builds and boots ok. It'll be running on this machine now. So some ppc testing is underway as of now.
x86 Build and runs fine with pax and grsec enabled, hardened userland, traffic shaping & l7-filter. Running services: apache, bind, postfix, courier, sshd, nfs, dhcpd, ddclient, mrtg, snmp, mysql, ntp, privoxy, tor, rngd, syslog-ng, cron
Thanks. For those users that are able to do so, I would like for the stock "Hardened [Gentoo]" security level to be tested with a view to ensuring that there is no adverse impact upon their respective workloads. As noted in the help text for this level and the ewarn statements in the ebuild, this level now enables PAX_MEMORY_UDEREF by default for x86 so be sure to switch that option off if running the kernel on a VM guest (host is OK).
Also, if anyone does actually test the Hardened [Gentoo] level and finds that it's a bit sluggish for their workload would they please switch to a Custom level, disable PAX_MEMORY_SANTIZE and offer some observations regarding the changes in performance, if any?
(In reply to comment #8) > Also, if anyone does actually test the Hardened [Gentoo] level and finds that > it's a bit sluggish for their workload would they please switch to a Custom > level, disable PAX_MEMORY_SANTIZE and offer some observations regarding the > changes in performance, if any? This is what I'm doing now. I did feel a performance hit.. But just to make sure it's not in my mind I'll be putting this to the test under nbench and report results here.
benchmark results were inconclusive. Looking at the sysctl controllable value kernel.grsecurity.destroy_unused_shm which was probably set to =1 by the CONFIG_GRKERNSEC_SYSCTL_ON that was causing the performance hit.
http://forums.grsecurity.net/viewtopic.php?f=3&t=1934&st=0&sk=t&sd=a&start=15 make sure CONFIG_ELF_CORE=y is set in the kernel
gradm -E You are using incompatible versions of gradm and grsecurity. Please update both versions to the ones available on the website. Make sure your gradm has been compiled for the kernel you are currently running. compiled gradm against r9
(In reply to comment #12) > gradm -E > You are using incompatible versions of gradm and grsecurity. > Please update both versions to the ones available on the website. > Make sure your gradm has been compiled for the kernel you are currently > running. > > compiled gradm against r9 > forgot version of gradm: sys-apps/gradm-2.1.10.200702231759
If marking -r9 stable, =sys-apps/gradm-2.1.11.200708011700 must be stabilized, too. Older versions of gradm do not work with -r9.
Re: Comment 14, it doesn't qualify as a blocker because people who are using versions of hardened-sources/gradm keyworded stable right *now* are already affected. Therefore, it's not a regression. Nonetheless, we intend to sort it out in as soon as possible.
Created attachment 147701 [details, diff] Patch to address bug #206678
Removing block on 206678. We don't want to hold up stabilisation of a mature 2.6.23 release any longer. Instead, we'll ewarn and address the matter in a better way for the 2.6.24 release.
Well I ran some tests to try and determine the impact of the PAX_MEMORY_SANITIZE option. Firstly, some information about my hardware: System: Dell PowerEdge SC1435 CPU: 2 x Dual-Core AMD Opteron(tm) Processor 2212 HE RAM: 1GB Storage: Symbios Logic SAS1068 PCI-X Fusion-MPT SAS; 2 x Seagate ST3300555SS drives (RAID1 in hardware) Prior to the entire process I created a dedicated 7GB logical volume to contain the kernel sources. I also ensured that the bootloader was configured to boot a 2.6.23-r9 kernel image. For the first test, I enabled the stock "Hardened [Gentoo]" level then switched to the Custom level in order to disable PAX_MEMORY_SANITIZE. Note that I went through the correct process to ensure that no options were inadvertently changed when switching to Custom (as documented by our new help text). Furthermore, I should point out that - as the level allows for many otherwise unselected options to be enabled by the user - I was sure to wipe the portion of my .config containing any grsecurity/PaX related options beforehand, thus ensuring that the policy defined by the level was initially effected in exactly the same way as it would be if no prior .config existed at all (i.e. as it would be in the case of a new Hardened Gentoo user enabling grsecurity for the first time). For the second test, I enabled PAX_MEMORY_SANITIZE whilst keeping all other configuration options the same, thus rendering the overall configuration completely identical to that of the "Hardened [Gentoo]" level. No more, no less. Running in single mode was not practical. Nonetheless, I ensured that only the bare minimum of init scripts were present in the default runlevel (most notably, net.eth0 and ssh). The testing procedure itself was as follows: 1) Created a fresh ext3 filesystem upon the volume with "mkfs -j" 2) Copied a hardened-2.6.23-r9 source tree to the filesystem 3) Configured the kernel with: make allyesconfig 4) Ran: sync && echo 3 > /proc/sys/vm/drop_caches 5) Ran: time make -j3 Now for the results: Test #1 (+GRKERNSEC_HARDENED -PAX_MEMORY_SANITIZE) Setup is 10808 bytes (padded to 11264 bytes). System is 14274 kB Kernel: arch/x86_64/boot/bzImage is ready (#1) real 26m34.191s user 40m1.210s sys 5m19.136s Test #2 (+GRKERNSEC_HARDENED) Setup is 10808 bytes (padded to 11264 bytes). System is 14274 kB Kernel: arch/x86_64/boot/bzImage is ready (#1) real 27m44.696s user 40m12.779s sys 7m29.820s As can be seen, the impact upon real time is somewhat modest. Looking at it from a subjective viewpoint, I enabled PAX_MEMORY_SANITIZE on my setup after first booting with a work-in-progress 2.6.24 patchset a few weeks ago and have not noticed any adverse effect upon my workload. As it stands, I am not aware of any compelling data to suggest that it would be remiss to keep this option enabled in the default level.
Re: Comment 10 > benchmark results were inconclusive. Looking at the sysctl controllable value > kernel.grsecurity.destroy_unused_shm which was probably set to =1 by the > CONFIG_GRKERNSEC_SYSCTL_ON that was causing the performance hit. I concur. When the level was enabled for the first time on miranda, the prior .config options were inherited. This would have caused a considerable number of options to be enabled above and beyond those selected by the level itself. In particular, I suspect that this may have caused the logging to go nuts. This is not something that would affect a new user enabling grsecurity for the first time as the logging options that are explicitly selected are actually fairly conservative (although the user is free to do as they will, and instructions are provided as how to inherit this - in my view, sensible - default policy into the Custom level).
Thank you for testing Kerin. From your results the performance hit is ~4.25%, which is not that different from the 3% performance hit quoted in the help for the SANITIZE option. Our "Hardened Gentoo" security level is supposed to be security-oriented first and foremost (while remaining compatible with the vast majority of software of course). Since the performance hit in most circumstances is not that large and the option does not completely break any known software, my opinion is the option should stay enabled for our security level. With this question resolved, I can see no additional blockers to 2.6.23-r9 going stable, so IMO stabilization should go forward now.
Keyworded stable on x86/amd64. nixnut, would you be so kind as to endorse that the same happens for ppc/ppc64?
(In reply to comment #21) > Keyworded stable on x86/amd64. nixnut, would you be so kind as to endorse that > the same happens for ppc/ppc64? ppc stable. can't speak for ppc64 since I don't have the hardware.
I guess that covers all the platforms for which we are collectively able to perform any testing. Closing.
