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.

bsherman•5/12/23, 10:43 PM

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

main

... your approach seems to be adding an and

nvidia

nvidia

may auto-inherit from ( 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

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).

akdev•5/12/23, 10:45 PM

v4l2loopback isn't hardware to be fair but I'm not against it

bsherman•5/12/23, 10:53 PM

yeah, definitely Quality of Life, not hardware

but that's in scope too

Arcitec•5/13/23, 12:26 AM

This is awesome stuff.

DavidOP•5/13/23, 9:29 AM

I absolutely agree that the akmods we are talking about all fall under "hardware enablement" and probably should be included in main, but:

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 image is not more work on our end. We build

main

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.

DavidOP•5/13/23, 9:31 AM

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 requirement

DDavid I absolutely agree that the akmods we are talking about all fall under "hardware...

Arcitec•5/13/23, 3:05 PM

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.

DavidOP•5/13/23, 5:17 PM

No it does not break secure boot. You can still sign closed-source modules.
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.

bsherman•5/13/23, 6:58 PM

I'm responding to both of you @iwantmynumberback and @Arcitec

1) David and I (and more obviously the 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

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!

Arcitec•5/13/23, 10:26 PM

Alright, I read both replies and everything sounds excellent. Good point that we already ship

nvidia

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.

AArcitec Alright, I read both replies and everything sounds excellent. Good point that we...

bsherman•5/13/23, 10:28 PM

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

Arcitec•5/13/23, 10:32 PM

Ahhh, that file made me think it was how GitHub signs files. But it makes sense that they have a private private key feature.

Bbsherman I'm responding to both of you @iwantmynumberback and @Arcitec 🙂 1) David and ...

j0rge•5/13/23, 10:32 PM

I just looked the signing key isn't in the github secrets afaict

bsherman•5/13/23, 10:32 PM

it's an org secret, no?

j0rge•5/13/23, 10:32 PM

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

Arcitec•5/13/23, 10:33 PM

Oh, so the visible key in the repo is used for signing the kernel modules during builds then?

bsherman•5/13/23, 10:33 PM

i'm going to read code so i don't talk out my ass

j0rge•5/13/23, 10:33 PM

we'd have to confirm with josh

bsherman•5/13/23, 10:34 PM

@j0rge should be a secret named

j0rge•5/13/23, 10:35 PM

oh yep, ok found it, not org level, repo level

bsherman•5/13/23, 10:35 PM

is org level, right?

j0rge•5/13/23, 10:35 PM

yeah it's like the others, I can't see the actual key I can only ever overwrite it

j0rge•5/13/23, 10:35 PM

yeah, SIGNING_SECRET is

bsherman•5/13/23, 10:35 PM

i'd love to get AKMOD_PRIVKEY moved to org level

bsherman•5/13/23, 10:35 PM

but i'm guessing only Josh has it?

bsherman•5/13/23, 10:36 PM

i'll file a ticket for that

bsherman•5/13/23, 10:36 PM

my reasoning... we'll want to use the same key for akmods as nvidia...

j0rge•5/13/23, 10:36 PM

indeed

bsherman•5/13/23, 10:37 PM

but i don't see us building them in same repo

j0rge•5/13/23, 10:37 PM

also it wouldn't hurt to exercise some key management discipline

bsherman•5/13/23, 10:37 PM

whatever perms i have on nvidia, i can't see it

j0rge•5/13/23, 10:37 PM

bsherman•5/13/23, 10:37 PM

ah, yeah, in i can see that SIGNING_SECRET at least exists

bsherman•5/13/23, 10:38 PM

j0rge•5/13/23, 10:38 PM

yeah file it and we'll do it org-wide

bsherman•5/13/23, 10:38 PM

ok, thank you for confirming all this @j0rge

bsherman•5/13/23, 10:40 PM

https://github.com/ublue-os/nvidia/issues/100

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...

bsherman•5/13/23, 10:40 PM

ok, my guests are REALLY here any minute, so i'm outie again

Arcitec•5/13/23, 10:41 PM

@bsherman Okay enjoy your evening!