FS#52881 - [linux-grsec] can't boot after upgrade to 4.9.8

Attached to Project: Community Packages
Opened by Rhett M. Bowen (uzooscot) - Monday, 06 February 2017, 20:55 GMT
Last edited by Daniel Micay (thestinger) - Tuesday, 14 February 2017, 04:47 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Daniel Micay (thestinger)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

After latest upgrade I can't boot into new kernel. It stops in grub with "loading initial ramdisk" message. I don't have any logs. Vanilla 4.9.8 kernel boot without issues same as previous 4.8.17 grsec kernel.
This task depends upon

Closed by  Daniel Micay (thestinger)
Tuesday, 14 February 2017, 04:47 GMT
Reason for closing:  Fixed
Comment by Rhett M. Bowen (uzooscot) - Monday, 06 February 2017, 21:35 GMT
Also tested with refind and clean boot parameters.
Comment by Daniel Micay (thestinger) - Monday, 06 February 2017, 22:12 GMT
It's in testing for a reason: it's both a major new release branch (4.9.x) and there's a huge new feature that's potentially going to uncover a bunch of hardware-specific issues (RAP return address checking).
Comment by Brad Spengler (spendergrsec) - Tuesday, 07 February 2017, 01:19 GMT
This is currently being worked on, it's a type violation in the paravirt code.

-Brad
Comment by Daniel Micay (thestinger) - Tuesday, 07 February 2017, 15:10 GMT
There's linux-grsec-1:4.9.8.r201702060653-2 in community-testing now, but I'm not ready to move it out of testing yet. It needs a bit more time to have the new hardware specific issues found and worked through.
Comment by Clayton Craft (craftyguy) - Wednesday, 08 February 2017, 00:58 GMT
linux-grsec-1:4.9.8.r201702060653-2 doesn't boot on either of my two systems (one Haswell, one Skylake). It hangs very early in the boot process. I'm not able to get the kernel to output anything, even despite using "earlyprintk=efi ignore_loglevel"
Comment by Brad Spengler (spendergrsec) - Wednesday, 08 February 2017, 01:04 GMT
The latest patch doesn't include the fix for the paravirt issue yet. In the meantime if possible, you can try a kernel with paravirt disabled.

-Brad
Comment by Daniel Micay (thestinger) - Wednesday, 08 February 2017, 01:10 GMT
linux-grsec-1:4.9.8.r201702060653-2 has paravirt disabled so we'll see what happens with the latest patch.
Comment by Brad Spengler (spendergrsec) - Wednesday, 08 February 2017, 01:15 GMT
Can someone mail the failing .config that has paravirt disabled to pageexec@freemail.hu ?

-Brad
Comment by Clayton Craft (craftyguy) - Wednesday, 08 February 2017, 06:18 GMT
I'm hoping Daniel sends this to you since I don't have it and he's the maintainer of this patchset/kernel on Arch. If he doesn't or is unable to for some reason, let me know and I'll try to reproduce the .config using the patches he submitted to this repo.
Comment by Rhett M. Bowen (uzooscot) - Wednesday, 08 February 2017, 11:21 GMT
The config is here: https://git.archlinux.org/svntogit/community.git/plain/trunk/config.x86_64?h=packages/linux-grsec

As for me disabling paravirt is enough to boot it properly so there are different issues.
Comment by Clayton Craft (craftyguy) - Wednesday, 08 February 2017, 17:26 GMT
Ok. If you need any info from me to help figure out why it is failing to boot for others, let me know. As I said previously, the kernel seems to be hanging very early since enabling no amount of output through kernel parameters (at least that I could find) results in anything being output to screen.
Comment by Giuseppe (G-G) - Saturday, 11 February 2017, 18:53 GMT
I am running a kernel with paravirt disabled and have the same issue. I don't know if this is relevant, but I was able to boot the system disabling PAX_KERNEXEC.
Comment by Daniel Micay (thestinger) - Monday, 13 February 2017, 02:54 GMT
Should be fixed by 1:4.8.17.r201701151620-1.
Comment by Clayton Craft (craftyguy) - Monday, 13 February 2017, 03:27 GMT
> Should be fixed by 1:4.8.17.r201701151620-1.

Did you paste the wrong version string or ???

The previous 4.8 linux-grsec kernel (what you just referred to) works, that's not why this ticket was filed.
Comment by Daniel Micay (thestinger) - Monday, 13 February 2017, 03:56 GMT
I mean 1:4.9.9.r201702122044-1: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/linux-grsec&id=8a61d12c94072ac432e5254569e6322a9d2212d8.
Comment by Daniel Micay (thestinger) - Monday, 13 February 2017, 03:57 GMT
Still in the testing repository for now, but it can be moved in a bit.
Comment by Clayton Craft (craftyguy) - Monday, 13 February 2017, 04:02 GMT
Using 4.9.9.r201702122044-1, it still hangs for me a bit further in the boot process though (I see a message from systemd in initrd!!), I'll try to get more output tomorrow.

Yea I know this is the testing repository, and I'm testing :)
Comment by Clayton Craft (craftyguy) - Tuesday, 14 February 2017, 02:45 GMT
4.9.9.r201702122044-1 boots on my Haswell laptop (Dell XPS 13 9333), but does not boot on my Skylake system (Intel Skull Canyon NUC), where the 4.8 grsec kernel worked.

I'll try and enable more verbose output from the kernel to see if I can get anything useful when it hangs.
Comment by Clayton Craft (craftyguy) - Tuesday, 14 February 2017, 04:39 GMT
Ok, it's booting on both of my systems. The issue on my skylake system was not related to this kernel, but to Intel's wonky platform bios and some platform-specific(?) quirks/magic.

Loading...