| 21 Jun 2021 |
 raboof | In reply to @foxboron:archlinux.org
You are also loosing the ability to detect tainted modules on any normal nixos installation. That is a net negative in terms of security for any live deployment. not sure about 'net negative' overall, but that's indeed a disadvantage. I wonder if we could have our cake and eat it, too, here: after all, to detect tainted modules you only need to somehow have a trusted set of checksums, you don't need a signature | 08:30:35 |
 Foxboron | In Arch we have been contemplating just splitting out key material to a separate package and declare it "non-reproducible". But it is non-obvious how to best approach the issue. Which is why I was curious what you where doing :) | 08:32:04 |
| Foxboron | In reply to @raboof:matrix.org
not sure about 'net negative' overall, but that's indeed a disadvantage. I wonder if we could have our cake and eat it, too, here: after all, to detect tainted modules you only need to somehow have a trusted set of checksums, you don't need a signature I'm not sure how this would work without kernel support though. Having the lockdown mode available is a great feature even if fairly unusable with DKMS without kernel patching currently. | 08:33:13 |
 Linux Hackerman | I think what would probably make sense is to have "local" signatures generated outside the scope of the kernel build (indeed, outside the scope of any nix build) | 08:33:42 |
| Linux Hackerman | That has the disadvantage of requiring a signing key that resides on the machine which is booting the kernel in question | 08:34:08 |
| Linux Hackerman | but the advantage of also being applicable to out-of-tree kernel modules (like zfs). We don't have dkms for that sort of thing because of how nix works | 08:34:48 |
| Linux Hackerman | I'm also not sure if it's feasible to patch a differnet key into the kernel image after the fact? But I imagine it should be. | 08:35:18 |
| raboof | in the NixOS context I'm not sure it's worth it since it's so easy to build bespoke kernels anyway... | 08:36:22 |
| Linux Hackerman | Secure boot is a similar topic, and (while it's not merged yet) this PR takes a similar approach to that https://github.com/NixOS/nixpkgs/pull/53901 | 08:36:53 |
| Foxboron | It's non-trivial. There are some null bytes in the linux initrd where you can just insert a public key and the kernel is going to accept it as a module signing key, but afaik it's missing in the efistub(?). Other distributions actually include a rejected out-of-tree patch where Secure Boot keys (OEM and MOK) are inserted into the keyring. | 08:36:41 |
| Foxboron | (Self-promotion: https://github.com/Foxboron/sbctl/) | 08:37:16 |
| Linux Hackerman | Nice! | 08:37:41 |
| Linux Hackerman | Oh but if keys can be loaded from the initramfs that's perfect. | 08:38:22 |
| Foxboron | Well, not without additional patching. | 08:38:37 |
| Foxboron | I haven't figured out how the initrd key insertion works. I have been trying to figure out lockdown mode + secureboot. (But now we are moving into offtopic territory) | 08:39:02 |
| Linux Hackerman | hm, I was thinking that the kernel could boot in non-lockdown mode, then the initramfs (which is also a signed efi image ergo trustable) can load some keys in via sysfs/procfs/whatever, and then enable lockdown | 08:39:48 |
| Linux Hackerman | IMHO, it's on-topic enough :p | 08:40:15 |
| Foxboron | There is no support. Currently you need to insert a key into the initrd or add the canonical/redhat patches which yeets the secure boot keys into the kernel keyring. | 08:40:41 |
| Foxboron | But initrd != efistub (or something) | 08:40:54 |
| Foxboron | (I never dug deep into that part of the problem) | 08:41:01 |
| Linux Hackerman | Well yeah, inserting the key into the initramfs is what I'm describing | 08:41:34 |
| Linux Hackerman | The efi stub is part of the linux kernel which makes it into an EFI-bootable image IIUC. | 08:42:02 |
| Foxboron | initramfs isn't actually protected by secure boot. But if you make a unified EFI image with initramfs+kernel it is. Hmmmm. Ahh this would be a cool feature | 08:43:33 |
| Linux Hackerman | Oh right, yeah, just saw that in https://github.com/NixOS/nixpkgs/pull/53901/files#diff-14341d580318ebe4f2ce22e4fc94c02f6a56229cdc7ae939728628a47b9e6b39R144-R149 :) | 08:44:00 |
| Foxboron | Make a seperate initramfs with the key in kernel/x86/key/somecert.cert (this is what microcode does for early boot loading) which you can concat with microcode + initramfs. | 08:44:49 |
| Foxboron | This is me theorizing what alternative key loading would look like fwiw | 08:45:32 |
|  fgaz joined the room. | 10:05:45 |
 baloo | 1486 out of 1486 (100.00%) paths in the minimal installation image are reproducible! 🎉🎉🎉 | 12:48:25 |
| baloo | In reply to @foxboron:archlinux.org
initramfs isn't actually protected by secure boot. But if you make a unified EFI image with initramfs+kernel it is. Hmmmm. Ahh this would be a cool feature That is pretty easy to do actually.
https://github.com/baloo/reproducibility-lab/tree/main/pkgs/uefi-bundle
I haven’t worked on injecting the key from the secureboot but that does not sound impossible. | 13:32:28 |
| baloo | Although if I might be pessimistic a bit. Not too sure all too many people have a practical use case for it | 13:33:46 |
