For example I m still not quite sure
For example I'm still not quite sure whether akmods (xone, v4l2loopback,...) should be included in main or be their own image.
34 Replies
great to hear from you! Yeah, I have similar akmods stuff on my personal image that's working smoothly... and i've been picking up more PRs in config/main/nvidia so I feel very good about moving forward here. I'm pretty happy to pick up your PR and run, but you started the effort, so we can do it together or whatever you like.
I'm pretty out of pocket on Sunday, but content to do some async stuff in a a discord thread, on your PR, or in a github discussion.
regarding questions about which akmods are included...
My original goal was to build akmods and add them to
main... your approach seems to be adding an extended and nvidia may auto-inherit from extended ( I know you wrote all this up once, but I'd have to dig for it )
Regardless of actual target image... to me, adding akmods addresses the hardware enablement goal same as we do by adding udev-rules to main ... so WHICH hardware do we enable becomes a community decision assuming the requested driver fits within the defined scope and framework of tools.
Read up a bit and you'll see my thoughts on why system76 stuff would not fit yet, even with akmods (it's dkms and git checkout && make stuff).v4l2loopback isn't hardware to be fair but I'm not against it
yeah, definitely Quality of Life, not hardware 😉 but that's in scope too 😉
This is awesome stuff. 🙂
I absolutely agree that the akmods we are talking about all fall under "hardware enablement" and probably should be included in main, but:
1. Do we care about tainted kernels? Not relevant to xone and v4l2loopback, but I think some broadcom stuff taints?
2a. What about people who are already on main and would suddenly get some akmods, whose keys they'd need to enroll, shoved under their butts? ("Beta - deal with it" may be al valid answer)
2b. Luckily thats seems to be solved for new installs from the iso, which auto enrolls keys 🙂
Also: An
extended image is not more work on our end. We build main (without akmods) anyway and then use it to build the akmods, to ensure that kernel versions match. But it may introduce confusion for users.
Also before any new PR gets approved I really need to test the akmods stuff with isogenerator, whether the key enrollment works smoothly in a new install, that should certainly be a requirement1. Yeah tainted kernels is a no-no in core images. It breaks secure boot. It should be optional for people with that hardware.
2a. I've been thinking about the whole signing situation too. Our situation is interesting: We need to publish the private signing keys for akmods so that GitHub can build the signed modules. That gives evil people access to the private keys for trusted keys on everyone's motherboards.
But we are protected by the fact that people can't install new modules on immutable distros.
If that user switches back to regular Fedora they're a bit more vulnerable, but an attacker would still need sudo. Either way, that threat is basically never gonna happen, nobody is gonna target "ublue user who switched away to something else but still kept our leaked signing key in their BIOS". 😄 That's too obscure.
So my proposal is that we sign EVERY ublue akmod with the exact same key so that people only need to enroll ONCE for secure boot on all ublue distros.
1. No it does not break secure boot. You can still sign closed-source modules.
2. ABSOLUTLY NOT! The Secure Boot signing keys are NOT public. The private key published in the repo is just for testing purposes. The key used for production builds is managed with github secrets and, let me emphasize, NOT PUBLIC.
(I think jorge generated it and obv has access, but no one else)
Also: Immutability is not a protection mechanism! (at least not against evil actors, maybe against your mistake-making self) A leak of the production secure boot keys would be BAD.
Sudo is completly irrelevant, as secure boot is not meant to stop attacks in userspace, but before/during boot.
As for the last point: That is certainly planned and currently the way I do things, and afaik bsherman too.
I'm responding to both of you @iwantmynumberback and @Arcitec 🙂
1) David and I (and more obviously the
silverblue-nvidia image) have demonstrated successful SecureBoot on Silverblue with signed closed-source and open-source akmods ... so far list of kmods I've seen this way: nvidia, xone, xpadneo, broadcom wl...
As to the question "do we care about tainted kernels" ... I think that ship has already sailed given we ship nvidia. 🙂
2a) mostly, yes, "it's Beta, deal with it" seems pretty reasonable. We've been discussing the addition of akmods, ESPECIALLY xbox controller drivers and v4l2loopback for months now.
but, aside from that, only impacts users WITH the hardware... if you are using nvidia and don't want other kmods like this... well, that's an odd distinction. if you are PURE OPEN SOURCE, you aren't using uBlue, because we already pull in mesa-freeworld.
if you don't have hardware related to drivers, you see zero change except a few extra KB in the total image size.
re: signing... yeah, our signing is secure as any, private keys are NOT exposed... AFAIK, our SecureBoot signing key is only visible to @j0rge as he's the owner of the github org. I'm maintainer on most repos now and I know I can't see it.
I DO agree we should use the same key for akmods and nvidia, minimizing friction on the SecureBoot mode.
2b) yay!Alright, I read both replies and everything sounds excellent. Good point that we already ship
nvidia so adding more modules would be fine then.
And great to hear that the key in the repo is just some example key. 🙂
As long as everything is signed with the same key for convenience, I'm totally in favor of adding many more (trusted!!) modules to help people with different hardware.And great to hear that the key in the repo is just some example key. 🙂ahh... yeah, there is a TEST key checked in which is to aid in dev/testing for users trying to locally test an nvidia PR but that's not used to sign the in the actual build... the non-test file which exists is zero-length
Ahhh, that file made me think it was how GitHub signs files. But it makes sense that they have a private private key feature. 🙂
I just looked the signing key isn't in the github secrets afaict
it's an org secret, no?
The only secret I can "see" is the SIGNING_SECRET for cosign, and I can't see the actual key, I can only ever overwrite it with a new one
Oh, so the visible key in the repo is used for signing the kernel modules during builds then?