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?
i'm going to read code so i don't talk out my ass
we'd have to confirm with josh
@j0rge should be a secret named
AKMOD_PRIVKEYoh yep, ok found it, not org level, repo level
SIGNING_SECRET is org level, right?yeah it's like the others, I can't see the actual key I can only ever overwrite it
yeah, SIGNING_SECRET is
i'd love to get AKMOD_PRIVKEY moved to org level
but i'm guessing only Josh has it?
i'll file a ticket for that
my reasoning... we'll want to use the same key for akmods as nvidia...
indeed
but i don't see us building them in same repo
also it wouldn't hurt to exercise some key management discipline
whatever perms i have on nvidia, i can't see it
ah, yeah, in
ucore i can see that SIGNING_SECRET at least exists
yeah file it and we'll do it org-wide
ok, thank you for confirming all this @j0rge
GitHub
migrate akmod keys from repo to org level · Issue #100 · ublue-os/n...
We need to migrate AKMOD_PRIVKEY and AKMOD_PUBKEY to be org-level secrets rather than nvidia repo level. Reason: we plan to use the same single key for akmods signing of both our current nvidia akm...
ok, my guests are REALLY here any minute, so i'm outie again
@bsherman Okay enjoy your evening! 🙂