| Summary: | sys-kernel/hardened-sources-4.3.3-r3: BUG during boot | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Klaus Kusche <klaus.kusche> |
| Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | pageexec |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Picture of BUG
Picture of BUG.png Kernel config |
||
Created attachment 421362 [details]
Picture of BUG.png
Converted image to PNG for convenience.
Created attachment 421364 [details]
Kernel config
i just added 4.3.3-r3 to the tree = grsecurity-3.1-4.3.3-201512282134 can you test that? 4.3.3-r3 has the same problem. (In reply to Klaus Kusche from comment #4) > 4.3.3-r3 has the same problem. thanks for the quick response. 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? 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. 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? Everything 64 bit. I do not even have the IA32 flag in the kernel or the 32 bit multilib libs in userland. does the KERNEXEC_OR method work if you disable CONFIG_CONTEXT_TRACKING? 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). 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. (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 Works for me. |
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.