Provide a 5.4-series grsecurity-patched kernel with NUC10 support

[zenmonkeykstop]

Description

Intel NUCs are the default recommendation for SecureDrop servers, but the 10-series NUCs' Comet Lake chipset is only supported by Linux 5.5+. Ubuntu 20.04 ships with a 5.4 kernel with backported support for Comet Lake.

GRSecurity provides a patch for 5.4-series kernels. In order to be able to update hardware recommendations and prepare for the transition to Focal, we should build and test a 5.4-series kernel and determine what patches are required to get the necessary NUC functionality working.

User Research Evidence

User anecdotes about NUC availability.

[eloquence]

For the 1/6-1/20 sprint, @conorsch has committed to attempting to build and upload a 5.4 series kernel with the necessary patches to support NUC10 hardware, and @zenmonkeykstop will make a minimal attempt to install it on NUC10s.

[conorsch]

Haven't tracked down the necessary upstream commits to pull in as patches yet, which is a prereq for NUC10 support. I'll first try a build of 5.x with the patches we already have, and upload that to apt-test as a first step. We can rebuild and iterate on the config, only affecting Focal behavior, given the changes proposed in #5691

[conorsch]

For NUC10 support, we'll need to update the e1000e drivers again, similar to what we did in freedomofpress/ansible-role-grsecurity-build#46. More recent patches can be viewed here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/net/ethernet/intel/e1000e/hw.h (thanks for digging that up, @emkll!). Everything newer than Kaby Lake is worth pulling in.

[eloquence]

Our plan of record is that we want to ship a new kernel after the 1.8.0 release with initial Ubuntu 20.04 support, so likely 1.9.0. The NUC8s are still available and supported by the current kernel. We'll continue our investigations of the 5.4 series (again with the primary goal of achieving NUC10 support) during the 2/3-2/17 sprint and can flexibly reassess prioritization if we need to.

[conorsch]

tl;dr: Let's test the 5.4.88 kernel on NUC10, it should Just Work™.

Did a bit more reading on this today. Yes, the NUC10 is a Comet Lake chipset, but it appears that the necessary hardware support has already been backported into the stable tree for linux-5.4.y. That means we don't need to pull in an Ubuntu-specific overlay, we can just use the latest 5.4.x series kernel from upstream, with or without the grsec patch set, and it'll have the Comet Lake support added for the e1000e driver.

Now's a good time to point out that we aren't currently using any custom patches for e1000e support. We did pull in custom patches back in freedomofpress/ansible-role-grsecurity-build#46, but that was intentionally restricted to "stable2", i.e. 4.4.x series. Ever since we moved to 4.14.x in freedomofpress/ansible-role-grsecurity-build#51, those patches haven't been pulled in manually, since we've had access to the changes that represent from upstream.

The list of e1000e-related updates in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/net/ethernet/intel/e1000e/hw.h, above, is comprehensive, but too much so for our needs: only Comet Lake has been identified as the possibly-unsupported platform, which is specifically this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/intel/e1000e/hw.h?id=914ee9c436cbe90c8ca8a46ec8433cb614a2ada5 Note that commit hash, 914ee9c436cbe90c8ca8a46ec8433cb614a2ada5.

Switch over to the stable tree, rather than the mainline torvalds tree, we can dig out the same commit in the linux-5.4.y branch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.4.y&id=cd171c18d3d59f801ae8cbd63043d3e51713de6a Note that the previous commit hash appears verbatim:

commit 914ee9c436cbe90c8ca8a46ec8433cb614a2ada5 upstream

The web view for the git repos is convenient for documenting these relationships, but I don't like it for exploration. If you prefer CLI for grepping around, try the following:

# first up, we'll scope out the originally "5.4" release
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-mainline # you need ~5GB free
cd linux-mainline
git tag | grep 5.4
git checkout v5.4
git log ./drivers/net/ethernet/intel/e1000e/hw.h # page through it, observe Comet Lake references are absent
# ok, let's switch over to the stable tree!
cd
git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git linux-stable
cd linux-stable
git branch -a | grep 5.4
git checkout linux-5.4.y
git log ./drivers/net/ethernet/intel/e1000e/hw.h # page through it, observe Comet Lake references are present!

Despite this reading, I haven't actually tested on a NUC10, because I don't have one on hand right now. It's possible we've misunderstood the specific drivers required, and additional patches will be necessary. Regardless of patch inclusion, I'd like to rebuild a slightly more recent 5.4.x kernel for Focal (e.g. 5.4.88 -> 5.4.95, current stable at time of writing), but first things first, let's validate that those network interfaces are shipping bits as we'd expect.

Because I have no better place to put this information, I'd like to take this opportunity to point out that the codename for the 5.4.x kernel series is "Kleptomaniac Octopus": https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?h=linux-5.4.y#n6 which is a remarkably fun thought.

[emkll]

Thanks for the investigation @conorsch . I just tested the 5.4.88 kernel that is currently being served apt-test (NUC10i5FNH1) and can confirm that the kernel boots and the networking Just Works™. I did not go through a full install or testing as I only have 1 unit and no other mon server to go with it, but this unblocks further testing. At this point, I would suggest we update the metapackage strings and publish to apt-test to test the kernel more broadly (including CI).