-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for 6.6.x workstation kernels #45
Conversation
c2b75ff
to
ec1c58b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly notes/questions for myself.
debian/control.workstation
Outdated
Package: securedrop-workstation-grsec | ||
Section: admin | ||
Architecture: ${DEBARCH} | ||
Pre-Depends: qubes-kernel-vm-support (>=4.0.31) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume we can drop this now? The 4.1 bookworm VM I have is on 4.1.19+deb12u1
already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per freedomofpress/securedrop-builder@de34206 this was also only needed for the dkms build, so we can drop it too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This analysis didn't account for the switch to minimal templates, which are missing this package. So we do need a dependency on qubes-kernel-vm-support, though we can make it unversioned.
For whatever reason, the 6.6.22 kernel doesn't have networking in Qubes with HVM. Here's the diff of kernel modules between a stock Debian bookworm kernel (with working networking) and ours: https://gist.github.com/legoktm/292e4a5dbd0c733d837cb6f0d72c0773 |
The qubes-antispoof.service unit failed, because of network filter errors. Here's the beginning of the error:
So the missing networkfilter modules from above are even more suspect: -nf_conntrack
-nf_defrag_ipv4
-nf_defrag_ipv6
-nf_nat
nfnetlink
-nf_reject_ipv4
-nf_reject_ipv6
nf_tables
-nft_chain_nat
-nft_ct
-nft_masq
-nft_reject
-nft_reject_ipv4
-nft_reject_ipv6 |
The newly built kernel (freedomofpress/securedrop-apt-test#225) now has networking on Qubes \o/ |
615c69f
to
5d4b064
Compare
OK, we now have seemingly functional kernels! The remaining steps here are to add some back-compat for the 5.15 series, since we're planning to keep building those for a while on the server. |
A quick note: I'm not sure why you are pressing on HVM modes, you can actually use Xen's pvh grub. |
Remember Qubes has transitioned away from iptables. nft is used now instead. I would strongly suggest considering building monolithic kernels with a minimal config. If you transition away from HVM to pvgrub, and even if you don't, it will be a good idea. Removing LKM support has several benefits in terms of reducing attack surface in the kernel for ROP and code injection scenarios (after all, LKM support comes with the implicit need for a dynamic linker in kernel space). |
Yup, SDW AppVMs were previously HVM, but looks like we're moving to PVH for the next workstation release on Qubes 4.2, it's working pretty well on a test branch. |
This is a good point and something I started wondering about mid-last week, whether there was any benefit to building individual modules. I'll look into doing a monolithic build. |
Unrelated to the kernel-builder but remember pvgrub requires a working GRUB bootloader in the virtual disk and some issues might come up (if this is not done properly) when creating qubes from disposable templates with their kernel set to pvgrub. MIght save you time. Use a separate dispvm template from sys-usb and co or you might face a non functional system once dom0 does the USB controller handoff. |
e466358
to
0d6f913
Compare
OK, marking this as ready for review now. I've split the monolithic kernel suggestion to its own issue. |
So far:
others to follow. |
6.6.23-1-grsec-workstation results
|
The 6.6 build command runs |
Some reproducibility issue seems to have snuck in...debugging. |
New configuration was generated by taking the old 5.15 config, taking a 6.6.22 grsec-patched kernel tree and running `make xen.config` and then `make olddefconfig` in a bookworm VM.
We are missing netfilter modules that the Qubes firewall/network needs, so copy their config directly: <https://github.com/QubesOS/qubes-linux-kernel/blob/b93840a3c8254c696bc3fedcb792bb3ed99bfa19/config-base>.
Reduce the diff between the two. We can't eliminate it fully, but there are no superificial differences anymore.
Build on bookworm so we can take advantage of newer gcc and the hardening features they bring.
Instead of dynamically generating the debian/ packaging information, just keep our own. This will hopefully make future upgrades easier since we'll just need to synchronize the d/rules file. Instead of continuing to use increasingly complex shell scripts, take the opportunity to port build-kernel.sh to Python and use jinja2 for templating the dynamic parts of the debian/ folder. Take the opportunity to start xz-compressing the orig tarballs. This brings us in line with stable kernel releases and allows us to reuse upstream tarballs when possible (implemented in a later commit).
* Allow varying the base distro in the Dockerfile * Add conditionals to d/rules to vary how we build the kernel packages * Add tinyconfig from 5.15.16, intentionally using an old version that has missing settings
To avoid repacking the kernel source on non-grsec builds, we can reuse the upstream tarball. The only thing we modify in the kernel source is `.config`, which we can place in the debian/ directory.
* Build tinyconfig kernels instead of "vanilla" ones for speed * Have one job build both times instead of duplicating into a second job * Use diffoscope on the .changes file but ignore the buildinfo file * Install xz-utils so the packages can be diffed instead of hexdumped
I better documented the changes around xz and rebased and signed this commit stack. |
libelf-dev is a leftover from the u2mn kernel module builds that we needed on buster/4.0 but haven't since. Switch qubes-kernel-vm-support to an unversioned `Depends` as it's only needed in the postinst and the necessary version is already in both bullseye and bookworm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good sleuthing, and thank you!
Tacked on 2 wee commits:
|
Both of your commits LGTM, thanks. (I still don't understand the Pre-Depends vs Depends, I will take some time next week to better understand the dependency.) |
Per internal chat, kernels looking good, gonna merge -thanks @legoktm and team for all your work on this |
Description
Linux 6.6 changed mkdebian, so our previous copy and override would've needed significant work to follow upstream. I think it's easiest to just create our own Debian directory with all the metadata we want, and any future kernel upgrades will require synchronizing
debian/rules
with what upstream does. This is shown in the current file with two different stanzas for 5.15 and 6.6. The script has gotten sufficiently complex now so I've taken the opportunity to port it to Python and jinja2 templating.For 6.6, I took the workstation 5.15 config, ran
make olddefconfig
and then copied over the Qubes kernel config's netfilter part. I also updated the build container to bookworm for these 6.6 builds.Linux has a concept of "tinyconfig", which is the smallest possible kernel that can be built, which is a good way to test our build infrastructure without taking too much time. Add 5.15 and 6.6 tinyconfigs and use those in CI, cutting it down from about 10-11min to 5min.
Test plan
Run through all the make targets:
make tiny-5.15
make tiny-6.6
make securedrop-core-5.15
make securedrop-workstation-5.15
make securedrop-workstation-6.6
And then: