Bump SecureDrop kernel to 4.4.177

[emkll]

Status

Ready for review

Description of Changes

Towards #4024
Simply bumps strings for grsec kernel, the kernel work was done by @zenmonkeykstop in freedomofpress/ansible-role-grsecurity-build#46

Changes proposed in this pull request:

Test Plan

First:

• Metapackage and kernel images uploaded to apt-test (Thanks @rmol !)

To validate the functionality of these kernels:

• Clean install using apt-test.freedom.press is successful
• intel e1000e NIC is functional using the 4.4.177-grsec kernel provided
• CI passes

Deployment

New and existing installs will be upgraded via apt

Checklist

If you made non-trivial code changes:

• I have written a test plan and validated it for this PR

[emkll]

This should now be ready for review. CI will staging-test-with-rebase will fail on all PRs due to 4.4.177 currently being served by apt-test, and the tests are checking for 4.4.167

[rmol]

@zenmonkeykstop @emkll Hate to end the week with bad news, but it's probably just something I've done wrong. I tried a fresh install of SD on Xenial, by changing the apt repo to apt-test in my develop checkout and running securedrop-admin install, and the installation timed out while waiting for my NUCs to reboot.

I logged in on their consoles to find they're both now running the 4.4.177-grsec kernel, but with no Ethernet interfaces configured. Running modprobe e1000e does nothing. The interface doesn't show up in ip link (there's just the loopback), and the driver isn't attached to the NIC in the output of lspci. The PCI ID is the same as above (8086:15d8), rev 21.

These are NUC 7i5BNHs. One has the same BIOS revision as above, 72, while the other is at 76. The NICs worked fine for the first part of the installation.

[zenmonkeykstop]

Hi @rmol - if the kernel version bumped, I don't think that you did anything wrong. Could you do me a favour and run modinfo e1000e | grep -i 15d8 to see if there's an alias for the chipset defined in the module that it's running?

[rmol]

@zenmonkeykstop There is not.

[conorsch]

Summarizing discussion from today's standup: @rmol's surprising result of broken hardware support was caused by a mix-up on the backend, with the apt-test repo. We're sorting that out now, having rebuilt with the patches presented in freedomofpress/ansible-role-grsecurity-build#46. CI is passing here, validating that the new kernel versions are serving as expected, via the apt-test repo.

We'll proceed with manual QA on hardware prior to the 0.12.2 point release. Approving and merging, given that the changes are presented are behaving well (as evidenced by CI), and also because the new test vars are required for other PRs to pass CI now, given the automatic rebase in CI.

At a later date, let's consider a branch naming pragma with kernel-, similar to what we do with docs- (to skip the full CI run, which would skip just the kernel version tests.

[conorsch]

Approving based on visual review, and confirmation that CI is passing with the new test vars.

[emkll]

thanks for the review @rmol I have updated apt-test with kernels that should now be e1000e compatible. The previous kernels were built on master instead of the e1000e feature branch, as I was using a disposable VM and forgot to explicitly check out the correct WIP remote branch, my apologies.