Bug 570420 – sys-kernel/hardened-sources-4.3.3-r3: BUG during boot

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Klaus Kusche 2015-12-31 17:32:23 UTC]

Created attachment 421360 [details]
Picture of BUG

Panics during boot, shortly after mounting root, before login is possible.
Compiled with gcc 5.3.0.
4.3.3-r1 had the same problem, 4.2.7 (also compiled with gcc 5.3.0) is fine.

Config and picture of the BUG attached.

[Comment 1 Michael Palimaka (kensington) 2015-12-31 17:35:15 UTC]

Created attachment 421362 [details]
Picture of BUG.png

Converted image to PNG for convenience.

[Comment 2 Klaus Kusche 2015-12-31 17:35:40 UTC]

Created attachment 421364 [details]
Kernel config

[Comment 3 Anthony Basile 2015-12-31 17:55:28 UTC]

i just added 4.3.3-r3 to the tree = grsecurity-3.1-4.3.3-201512282134

can you test that?

[Comment 4 Klaus Kusche 2015-12-31 20:03:40 UTC]

4.3.3-r3 has the same problem.

[Comment 5 Anthony Basile 2015-12-31 20:12:37 UTC]

(In reply to Klaus Kusche from comment #4)
> 4.3.3-r3 has the same problem.

thanks for the quick response.

[Comment 6 PaX Team 2016-01-01 22:39:41 UTC]

we'll need more information about this. first, enable DEBUG_INFO and FRAME_POINTER at least to get a better backtrace and symbols. second, it'd be nice to capture the entire dmesg as there're seemingly earlier failures related to iommu and/or radeon (you can also try to turn them off in your config to see if it helps). third, can you try to disable all grsec features and fourth, also test a vanilla 4.3.x kernel?

[Comment 7 Klaus Kusche 2016-01-03 11:23:05 UTC]

1.) DEBUG_INFO and FRAME_POINTER do not result in any additional info
being displayed.

2.) The other errors are not related. 
They also occur with a working kernel and have been there for many months.

3.) I was able to narrow it down to a single PaX config flag:
With CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="or", the kernel panics.
With CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="bts" or with KERNEXEC turned off
(and everything else unchanged), the kernel works fine.

[Comment 8 PaX Team 2016-01-03 13:01:45 UTC]

thanks, that's definitely a smoking gun. can you tell me if your userland (or at least the systemd binary) is 32 bit or 64 bit?

[Comment 9 Klaus Kusche 2016-01-03 13:40:17 UTC]

Everything 64 bit.
I do not even have the IA32 flag in the kernel
or the 32 bit multilib libs in userland.

[Comment 10 PaX Team 2016-01-03 21:02:12 UTC]

does the KERNEXEC_OR method work if you disable CONFIG_CONTEXT_TRACKING?

[Comment 11 Klaus Kusche 2016-01-04 15:45:16 UTC]

I was unable to turn off CONTEXT_TRACKING individually:
It is automagically turned back on.

But when switching from VIRT_CPU_ACCOUNTING to TICK_CPU_ACCOUNTING,
CONTEXT_TRACKING was removed automatically, and with these two changes, 
the kernel works fine even with KERNEXEC_OR.

So yes, the problem is related to CONTEXT_TRACKING (or VIRT_CPU_ACCOUNTING).

[Comment 12 PaX Team 2016-01-04 16:23:34 UTC]

thanks for the confirmation, in fact i already released the fix and the next grsec will have it too. if i overlooked something and it still doesn't work, just let me know here.

[Comment 13 Anthony Basile 2016-01-07 02:08:17 UTC]

(In reply to PaX Team from comment #12)
> thanks for the confirmation, in fact i already released the fix and the next
> grsec will have it too. if i overlooked something and it still doesn't work,
> just let me know here.

please test 4.3.3-r4 which i just added to the tree.  it includes grsecurity-3.1-4.3.3-201601051958

[Comment 14 Klaus Kusche 2016-01-07 11:12:53 UTC]

Works for me.