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.
Bgreat 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
Regardless of actual target image... to me, adding akmods addresses the hardware enablement goal same as we do by adding udev-rules to
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).
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
mainextended and nvidiaextended ( 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
mainRead 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).
Av4l2loopback isn't hardware to be fair but I'm not against it
Byeah, definitely Quality of Life, not hardware 
but that's in scope too
but that's in scope too 
AThis is awesome stuff. 
DI 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
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 mainAlso 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 requirement
A1. 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.
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.
D1. 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.
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.
BI'm responding to both of you @iwantmynumberback and @Arcitec
1) David and I (and more obviously the
As to the question "do we care about tainted kernels" ... I think that ship has already sailed given we ship
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!
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
nvidia2a) 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!
AAlright, I read both replies and everything sounds excellent. Good point that we already ship
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.
nvidiaAnd 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.
BAnd 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
AAhhh, that file made me think it was how GitHub signs files. But it makes sense that they have a private private key feature.
JI just looked the signing key isn't in the github secrets afaict
Bit's an org secret, no?
JThe 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
AOh, so the visible key in the repo is used for signing the kernel modules during builds then?
Bi'm going to read code so i don't talk out my ass
Jwe'd have to confirm with josh
B@j0rge should be a secret named
AKMOD_PRIVKEYJoh yep, ok found it, not org level, repo level
BSIGNING_SECRET is org level, right?Jyeah it's like the others, I can't see the actual key I can only ever overwrite it
Jyeah, SIGNING_SECRET is
Bi'd love to get AKMOD_PRIVKEY moved to org level
Bbut i'm guessing only Josh has it?
Bi'll file a ticket for that
Bmy reasoning... we'll want to use the same key for akmods as nvidia...
Jindeed
Bbut i don't see us building them in same repo
Jalso it wouldn't hurt to exercise some key management discipline
Bwhatever perms i have on nvidia, i can't see it
J
Bah, yeah, in
ucore i can see that SIGNING_SECRET at least existsB
Jyeah file it and we'll do it org-wide
Bok, thank you for confirming all this @j0rge
BGitHub
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...
Bok, my guests are REALLY here any minute, so i'm outie again
A@bsherman Okay enjoy your evening!
