Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=147701) [details]
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.