Summary: | sys-kernel/hardened-sources 2.6.36-r6 kernel panic | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dillon <developer> |
Component: | Hardened | Assignee: | The Gentoo Linux Hardened Kernel Team (OBSOLETE) <hardened-kernel+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | andrej, hardened, kallamej, pageexec, spender |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
kernel .config
hardened sources kernel panic Hardened-sources 2.6.32-r31 crash |
Description
Dillon
2010-12-25 18:23:11 UTC
Created attachment 258038 [details]
kernel .config
Created attachment 258039 [details]
hardened sources kernel panic
Okay after a back and forth on IRC/#gentoo-hardened, I'm not sure what's going on yet. Can you try your working config file from hardened-sources-2.6.32-r22 with 2.6.32-r31 and see if that works. Also try your current *failing* config file with vanilla-2.6.36.2. Both should isolate whether this is an issue with the vanilla kernel vs grsec hardened. If I can't narrow it from there, I'll pass the bug upstream. Created attachment 258090 [details]
Hardened-sources 2.6.32-r31 crash
h-s-2.6.32-r31 crashes with the kernel config that was working on h-s-2.6.32-r22
v-s-2.6.36.2 works with the config that fails on h-s-2.6.36-r6
I'm experiencing the same problems, though slightly different call trace. In addition to comment #4, hardened-sources-2.6.36-r6 boots if both grsec and pax are disabled (i.e after answering N to all questions when using oldconfig on the vanilla .config). Hardware wise it's an Asus A7N8X2.0 deluxe with one pata disk. Thanks guys, its clearly hardened-kernel issue. I'm alerting upstream. In the mean time, there are some newer grsec patches out that may address this issue. I'll see if the diff shows some new code that may address this and then roll them out. In the mean time, if you continue using 2.6.32-r22 with ECONET off you are secure. as i asked on the list as well, which grsec is included in r6? this particular issue with the recent UDEREF changes should be fixed in the latest grsec but there's another outstanding issue with the IP checksum code that will be fixed in the next patch only. (In reply to comment #7) > as i asked on the list as well, which grsec is included in r6? this particular > issue with the recent UDEREF changes should be fixed in the latest grsec but > there's another outstanding issue with the IP checksum code that will be fixed > in the next patch only. > hardened-sources-2.6.32-r31 has grsecurity-2.2.1-2.6.32.27-201012121726 hardened-sources-2.6.36-r6 has grsecurity-2.2.1-2.6.36.2-201012121726 (In reply to comment #8) > hardened-sources-2.6.32-r31 has grsecurity-2.2.1-2.6.32.27-201012121726 > > hardened-sources-2.6.36-r6 has grsecurity-2.2.1-2.6.36.2-201012121726 yeah so they're a bit dated now ;), so you can either pull in the changes since then or wait a bit more for an even newer patch to fix one more issue. (In reply to comment #9) > (In reply to comment #8) > > hardened-sources-2.6.32-r31 has grsecurity-2.2.1-2.6.32.27-201012121726 > > > > hardened-sources-2.6.36-r6 has grsecurity-2.2.1-2.6.36.2-201012121726 > > yeah so they're a bit dated now ;), so you can either pull in the changes since > then or wait a bit more for an even newer patch to fix one more issue. > I'm rolling out the latest: hardened-sources-2.6.32-r32 based on grsecurity-2.2.1-2.6.32.27-201012182005 hardened-sources-2.6.36-r7 based on grsecurity-2.2.1-2.6.36.2-201012221906 They'll be added to the tree after I compile/run test them --- about 24 hrs. I'll leave them marked ~arch (testing needed) and will aim at stabilizing the next set of patches which solve the other issue. It might be useful for the users to inform us if this set fixes the kernel panic. (In reply to comment #10) > I'm rolling out the latest: > > hardened-sources-2.6.32-r32 based on grsecurity-2.2.1-2.6.32.27-201012182005 > hardened-sources-2.6.36-r7 based on grsecurity-2.2.1-2.6.36.2-201012221906 Tried .36-r7 and it boots. Thanks guys! r7 had this build error until I removed the const from line 321 of include/linux/compiler.h The bug is fixed now. # make bzImage CHK include/linux/version.h CHK include/generated/utsrelease.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h CC kernel/rcutree.o In file included from kernel/rcutree.c:1966: kernel/rcutree_plugin.h: In function ‘__rcu_read_lock’: kernel/rcutree_plugin.h:204: error: increment of read-only location ‘*(const volatile int *)&get_current()->rcu_read_lock_nesting’ kernel/rcutree_plugin.h: In function ‘__rcu_read_unlock’: kernel/rcutree_plugin.h:347: error: decrement of read-only location ‘*(const volatile int *)&t->rcu_read_lock_nesting’ kernel/rcutree_plugin.h: In function ‘synchronize_rcu_expedited’: kernel/rcutree_plugin.h:718: error: increment of read-only location ‘*(const volatile long int *)&sync_rcu_preempt_exp_count’ make[1]: *** [kernel/rcutree.o] Error 1 make: *** [kernel] Error 2 (In reply to comment #12) > r7 had this build error until I removed the const from line 321 of > include/linux/compiler.h compile errors should be directly reported to spender and me ;). (In reply to comment #13) > (In reply to comment #12) > > r7 had this build error until I removed the const from line 321 of > > include/linux/compiler.h > > compile errors should be directly reported to spender and me ;). > By direct do you mean via email rather than via bugzilla? Other than the const volitile issue (which is a repeat of the x86_64 case [1]) your latest changes fixed the issue. Thanks pipacs! Ref: [1] http://forums.grsecurity.net/viewtopic.php?f=3&t=2501&start=0 I had the very same kernel panic with 2.6.36-r6, now r7 boots fine, testing it further. (In reply to comment #14) > By direct do you mean via email rather than via bugzilla? yes (for email/irc), it's more effective than posting this kind of problem into a random gentoo bugzilla entry that's about something else ;). > Other than the const volitile issue (which is a repeat of the x86_64 case [1]) the next patch will fix it properly as well. I just marked 2.6.36-r9 stable. Closing this one. |