I just updated hardened kernel to 3.12.6 and can't boot: grsec crashes init with > grsec: denied resource overstep by requesting 3221225472 for RLIMIT_STACK against limit 8388608 for /sbin/init[swapper/0:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper/0:0] uid/euid:0/0 gid/egid:0/0 > BUG: unable to handle kernel NULL pointer dereference at (nil) (see attached boot logs) P.S. 3.12.5 boots like a charm Reproducible: Always
Created attachment 366104 [details] emerge --info This is emerge info
Created attachment 366106 [details] boot1.log This is original bootlog
Created attachment 366108 [details] boot2.log This is bootlog, where I disabled hwclock stuff (time syncing) by blueness suggestion. Kernel still doesn't boot.
Created attachment 366110 [details] .config This is kernel's .config file I using for all my builds (including 3.12.5)
=hardened-sources-3.12.6-r2 seems to be fixed now
Although, now I've some troubles with IPv6 neighbour discovery between Xen domUs (not sure, if it is related only to xen or at all).
So, despite of original issue (with restricting init to start) is fixed, hardened 3.12.6 is still broken: somewhy it makes kernel to ignore acpi_rsdp cmdline option (so, kernel can't find RSDP table and then limits CPU core to 1 for entire system). I just tested with vanilla 3.12.6 and it works fine there.
acpi_rsdp is used only under CONFIG_KEXEC which depends on !CONFIG_GRKERNSEC_KMEM which you have enabled.
Yup. 1) somewhy it enables itself on make nconfig execution, 2) It's strange, but last time I tested it with manually disabled CONFIG_GRKERNSEC_KMEM and enabled KEXEC, it wasn't working too. But now, after a day full of debugging, it working on last my attempt, thanks. So, as for now, it is one more issue with .6 hardened kernel (that okay in .5): I can't point it's source exactly, but that is the situation: a) it is few virtual machines (Xen domUs) b) they has link-local IPv6 addressed (fe80:: ones) and ULA ones (from fc00::/7) for internal networking (nfs, dns, DB and so on) c) on hardened <=3.12.5 all works fine d) on 3.12.6 some machines gone unreachable (for any kind of traffic, will it be tcp, udp, icmp, ...) with ULA-address for some others, unless unreachable machine itself pings machine that missed it. But it stays accessible with link-local addresses (that is non need neighbour discovery). I'd suggest it is something with ND (neigbour discovery) or much globally, multicasting (or one more new grsec option hardening networking in strange way). But I don't even know where to debug.
uhm, lol, strange: 3.12.6 produces such network behaviour (described abode) even if it is installed only on virthost (dom0).
Created attachment 366464 [details, diff] diff_harden_vanilla there is a diff between config of vanilla 3.12.6 host kernel (where it is no such behaviour) and latest (-r2) hardened sources. Can something of that option lead to that behaviour? Or it, possibly, bug somewhere deeper in kernel code?
Although, looking at that fact, that 3.12.5-hardened-r1 works fine with identical to bugged-3.12.6-hardened-r2 kernel config, I'd suggest it is something in the hardened patches...
spender regularly backports fixes from vanilla that are not yet in stable and it's possible that one of these broke ipv6 (and will probably break stable when it gets the patch in question). maybe you can look at http://www.grsecurity.net/~spender/changelog-test.txt and revert the network related backports (say, b1aac815c0891fe4a55a6b0b715910142227700f) and see if any one is the culprit.
3.12.6 has been off the tree for a while. Given that this was probably a backported patch by spender which is probably resolved by now, I'm going to close this as obsolete. Please reopen if you are still hitting this.
