Re: [systemd-devel] So how am I supposed to put together my Linux system?
On 22.10.2014 21:08, Tobias Hunger wrote: Hi Lennart, On Wed, Oct 22, 2014 at 7:03 PM, Lennart Poettering lenn...@poettering.net wrote: Sorry for the late response, been travelling for a month, and then have been more travelling, and still trying to process all the mails that queued up since. No problem at all:-) On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering I see that secure boot wants one file and that you will need to merge kernel and initrd into one. But you will need the meta data to link the kernel/initrd combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos also has that and stores that meta-data in non-volatile memory accessible to the BIOS. My idea would be that the initrd contains that info. Each usr tree comes with one initrd, and that initrd knows which usr tree to boot. That implies that each installation snapshot must come with an initrd, even if the only change to earlier versions is the snapshot name. That sounds suboptimal to me. But then I am playing with atomic upgrades for a while now and in practice each snapshots comes with its own initrd anyway. 2. If we cannot have external config files, then kernel/initrd should find their stuff an empty kernel cmdline option. Nice ideal, but I do not see how that will work in general. You could bake some id into the kernel (kernel version or whatever), but usually the kernel changes slower than the sum of the files in /usr. You do want to boot different of these usr-setups with one kernel. Note that at least chromeos doesn't do this. They update the whole OS at once, including the kernel. And never kernel and /usr independently. I am following Arch and create new snapshots daily. For me the kernel updates way less often than the rest. The initrd does change for each snapshot though. I need to investigate what is causing that. I would have expected the initrd to change more often than the kernel, but definitely not for each update. Maybe mkinitcpio bakes in some timestamp or something. 4. The initrds should probably use information from /usr/lib/os-release (as shipped in the initrd as a copy of the OS' version) to build the btrfs sub-volume name to boot from. It should not allow overriding this name via the kernel cmdline, at least as long as we are in a mode where secureboot is actually turned on... That could work, provided there is something like a timestamp/version number in /usr/lib/os-release that actually changes every time *anything* in /usr changes (or at least when those changes are getting distributed as an image). You still need to store that information somewhere though for the kernel to know what to boot. Well, gummiboot picks a kernel with the initrd attached. the initrd then finds the right /usr tree according to the information it contains. Hope that makes some sense? Not really. I do see how this can work to boot the newest installation of distroX: You just need to look for the newest version of the usr-subvolume and boot that. Well, I think kernel and /usr hierarchy really belong together. If you pick a kernel you thus implicitly also pick a /usr tree. (Of course, this strict we only need to be for a verified boot. For other cases, we of course can allow passing arbitrary kernel cmdline options, to pick different usr tree. The user should be able to override things, unless the device is in trusted mode) How do I boot the version I ran before the upgrade in case the upgrade failed? In general the rule should probably be to go back in version one-by-one if a kernel/system failed to boot. THe boot loader should by default boot the newest kernel, thus the newest /usr, too. if that for some reason nerver finishes, on next reboot it should pick the kernel one version older, and so on. I really do not see how you can get around storing meta-data somehow. You can not change the kernel/initrd when it is signed, so you can not bake any information into that file. You can apparently not have a separate file when using secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Sure, we can store failure info in EFI Vars, no problem really. I agree that this should work for secure boot and a classic distribution upgrade. For my non-secure boot use case with incremental/daily upgrades the necessary changes to the systemd-fstab-generator were already merged (Thanks!), so I am waiting impatiently for the next systemd release to hit the arch repos. Those were the last bits I needed for my grand atomic upgrade scheme to work without me having to patch stuff locally:-) Now I can proceed to move more of my systems over to actually use it. PS: Your scheme was significantly simpler to get up and running than the ostree-approach I tried before. But maybe that was just because I started out with a working ostree setup:-) Best Regards, Tobias So, this what I do for the
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On 09.09.2014 17:01, Colin Guthrie wrote: Tobias Hunger wrote on 05/09/14 19:34: Any place that you would care to recomend? It would suck to have each distro put kernels somewhere else. Good question. On Mageia and Fedora (at least originally, not sure if it's changed recently), the modules are in: /lib/modules/kernel-version/ tree. These days this should of course be: /usr/lib/modules/kernel-version/ The actual modules are stored in a: /lib/modules/kernel-version/kernel/ subfolder. If there are no compelling reasons to pick otherwise, we could use: /usr/lib/kernel/kernel-version/ tree. Inside there would be a: /usr/lib/kernel/kernel-version/modules/ folder containing the actual modules (same as /lib/modules/kernel-version/kernel/) For compatibility, the /lib/modules/kernel-version could be symlinked to /usr/lib/kernel/kernel-version and a simple modules - kernel symlink shipped inside the /usr/lib/kernel/kernel-version/ folder. All old paths would work in that case. The kernel itself could then simply be: /usr/lib/kernel/kernel-version/vmlinuz Not sure if this is just completely made up in my head or if this is how others have envisioned it also. I don't think any of the spec documents talked about the actual filesystem layout of the actual kernel files/modules. Cheers Col Hmm, those symlinks would look ugly, but of course /usr/lib/kernel/kernel-version would be the sane name. Anyway, as a first step, I would put just put the kernel, System.map, config and any precompiled initrd in the modules directory: # ls /lib/modules/3.18.0-0.rc0.git9.2.fc22.1.x86_64/ System.map config initrd vmlinuz ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On Thu, Oct 23, 2014 at 12:51 AM, Lennart Poettering lenn...@poettering.net wrote: snip Correct. I can see that for some uses this might appear as overkill, but in general I would not make much of a distinction between the kernel and the basic userspace here, they really belong together. I am following Arch and create new snapshots daily. For me the kernel updates way less often than the rest. The initrd does change for each snapshot though. I need to investigate what is causing that. I would have expected the initrd to change more often than the kernel, but definitely not for each update. Maybe mkinitcpio bakes in some timestamp or something. I figure they want to make sure the files in the initrd are actually always identical to the source they are copied from in /usr. That kinda requires updating the initrd on each update of /usr. Of course I do create a new initrd for each new /usr (its my scripts, nothing arch does). But I keep the initrd and the kernel in /usr and only copy them if their sha does not match up with any of the other kernels/initrds that were installed to /boot already. No need to have the same file twice, my /boot partition is not that big. I did steal that from ostree:-) I had expected that the initrds will be shared between a couple of my daily snapshots, but it seems like I did not take the timestamps of the files in the initrd into account. Well, I still got some more things to clean up before I will bother about those. So for now I will live with one initrd per /usr. For my non-secure boot use case with incremental/daily upgrades the necessary changes to the systemd-fstab-generator were already merged (Thanks!), so I am waiting impatiently for the next systemd release to hit the arch repos. I am working on it, but there are a couple of things I still need to work on before the release. Sorry! No hurry. I just copy a patched systemd-fstab-generator into all the images that get generated. I did this setup so things like that would be easy. Well, actually I did it because I wanted to play with atomic upgrades;-) Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On Fri, 05.09.14 20:34, Tobias Hunger (tobias.hun...@gmail.com) wrote: Heya, Sorry for the late response, been travelling for a month, and then have been more travelling, and still trying to process all the mails that queued up since. On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering lenn...@poettering.net wrote: Yeah, we want to encourage distros to install kernels into /usr, somewhere next to where the kmods already are, and then copy that over where necessary into the used boot partition. We actually have sime infrastructure for this in place in systemd, in the install-kernel script, which also has a man page. Any place that you would care to recomend? It would suck to have each distro put kernels somewhere else. Hmm, dunno, I figure Kay/Harald might have an idea about this. Kay? Harald? I see that secure boot wants one file and that you will need to merge kernel and initrd into one. But you will need the meta data to link the kernel/initrd combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos also has that and stores that meta-data in non-volatile memory accessible to the BIOS. My idea would be that the initrd contains that info. Each usr tree comes with one initrd, and that initrd knows which usr tree to boot. 2. If we cannot have external config files, then kernel/initrd should find their stuff an empty kernel cmdline option. Nice ideal, but I do not see how that will work in general. You could bake some id into the kernel (kernel version or whatever), but usually the kernel changes slower than the sum of the files in /usr. You do want to boot different of these usr-setups with one kernel. Note that at least chromeos doesn't do this. They update the whole OS at once, including the kernel. And never kernel and /usr independently. 4. The initrds should probably use information from /usr/lib/os-release (as shipped in the initrd as a copy of the OS' version) to build the btrfs sub-volume name to boot from. It should not allow overriding this name via the kernel cmdline, at least as long as we are in a mode where secureboot is actually turned on... That could work, provided there is something like a timestamp/version number in /usr/lib/os-release that actually changes every time *anything* in /usr changes (or at least when those changes are getting distributed as an image). You still need to store that information somewhere though for the kernel to know what to boot. Well, gummiboot picks a kernel with the initrd attached. the initrd then finds the right /usr tree according to the information it contains. Hope that makes some sense? Not really. I do see how this can work to boot the newest installation of distroX: You just need to look for the newest version of the usr-subvolume and boot that. Well, I think kernel and /usr hierarchy really belong together. If you pick a kernel you thus implicitly also pick a /usr tree. (Of course, this strict we only need to be for a verified boot. For other cases, we of course can allow passing arbitrary kernel cmdline options, to pick different usr tree. The user should be able to override things, unless the device is in trusted mode) How do I boot the version I ran before the upgrade in case the upgrade failed? In general the rule should probably be to go back in version one-by-one if a kernel/system failed to boot. THe boot loader should by default boot the newest kernel, thus the newest /usr, too. if that for some reason nerver finishes, on next reboot it should pick the kernel one version older, and so on. I really do not see how you can get around storing meta-data somehow. You can not change the kernel/initrd when it is signed, so you can not bake any information into that file. You can apparently not have a separate file when using secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Sure, we can store failure info in EFI Vars, no problem really. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
Hi Lennart, On Wed, Oct 22, 2014 at 7:03 PM, Lennart Poettering lenn...@poettering.net wrote: Sorry for the late response, been travelling for a month, and then have been more travelling, and still trying to process all the mails that queued up since. No problem at all:-) On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering I see that secure boot wants one file and that you will need to merge kernel and initrd into one. But you will need the meta data to link the kernel/initrd combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos also has that and stores that meta-data in non-volatile memory accessible to the BIOS. My idea would be that the initrd contains that info. Each usr tree comes with one initrd, and that initrd knows which usr tree to boot. That implies that each installation snapshot must come with an initrd, even if the only change to earlier versions is the snapshot name. That sounds suboptimal to me. But then I am playing with atomic upgrades for a while now and in practice each snapshots comes with its own initrd anyway. 2. If we cannot have external config files, then kernel/initrd should find their stuff an empty kernel cmdline option. Nice ideal, but I do not see how that will work in general. You could bake some id into the kernel (kernel version or whatever), but usually the kernel changes slower than the sum of the files in /usr. You do want to boot different of these usr-setups with one kernel. Note that at least chromeos doesn't do this. They update the whole OS at once, including the kernel. And never kernel and /usr independently. I am following Arch and create new snapshots daily. For me the kernel updates way less often than the rest. The initrd does change for each snapshot though. I need to investigate what is causing that. I would have expected the initrd to change more often than the kernel, but definitely not for each update. Maybe mkinitcpio bakes in some timestamp or something. 4. The initrds should probably use information from /usr/lib/os-release (as shipped in the initrd as a copy of the OS' version) to build the btrfs sub-volume name to boot from. It should not allow overriding this name via the kernel cmdline, at least as long as we are in a mode where secureboot is actually turned on... That could work, provided there is something like a timestamp/version number in /usr/lib/os-release that actually changes every time *anything* in /usr changes (or at least when those changes are getting distributed as an image). You still need to store that information somewhere though for the kernel to know what to boot. Well, gummiboot picks a kernel with the initrd attached. the initrd then finds the right /usr tree according to the information it contains. Hope that makes some sense? Not really. I do see how this can work to boot the newest installation of distroX: You just need to look for the newest version of the usr-subvolume and boot that. Well, I think kernel and /usr hierarchy really belong together. If you pick a kernel you thus implicitly also pick a /usr tree. (Of course, this strict we only need to be for a verified boot. For other cases, we of course can allow passing arbitrary kernel cmdline options, to pick different usr tree. The user should be able to override things, unless the device is in trusted mode) How do I boot the version I ran before the upgrade in case the upgrade failed? In general the rule should probably be to go back in version one-by-one if a kernel/system failed to boot. THe boot loader should by default boot the newest kernel, thus the newest /usr, too. if that for some reason nerver finishes, on next reboot it should pick the kernel one version older, and so on. I really do not see how you can get around storing meta-data somehow. You can not change the kernel/initrd when it is signed, so you can not bake any information into that file. You can apparently not have a separate file when using secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Sure, we can store failure info in EFI Vars, no problem really. I agree that this should work for secure boot and a classic distribution upgrade. For my non-secure boot use case with incremental/daily upgrades the necessary changes to the systemd-fstab-generator were already merged (Thanks!), so I am waiting impatiently for the next systemd release to hit the arch repos. Those were the last bits I needed for my grand atomic upgrade scheme to work without me having to patch stuff locally:-) Now I can proceed to move more of my systems over to actually use it. PS: Your scheme was significantly simpler to get up and running than the ostree-approach I tried before. But maybe that was just because I started out with a working ostree setup:-) Best Regards, Tobias ___ systemd-devel mailing list
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On Wed, 22.10.14 21:08, Tobias Hunger (tobias.hun...@gmail.com) wrote: My idea would be that the initrd contains that info. Each usr tree comes with one initrd, and that initrd knows which usr tree to boot. That implies that each installation snapshot must come with an initrd, even if the only change to earlier versions is the snapshot name. That sounds suboptimal to me. Correct. I can see that for some uses this might appear as overkill, but in general I would not make much of a distinction between the kernel and the basic userspace here, they really belong together. I am following Arch and create new snapshots daily. For me the kernel updates way less often than the rest. The initrd does change for each snapshot though. I need to investigate what is causing that. I would have expected the initrd to change more often than the kernel, but definitely not for each update. Maybe mkinitcpio bakes in some timestamp or something. I figure they want to make sure the files in the initrd are actually always identical to the source they are copied from in /usr. That kinda requires updating the initrd on each update of /usr. secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Sure, we can store failure info in EFI Vars, no problem really. I agree that this should work for secure boot and a classic distribution upgrade. For my non-secure boot use case with incremental/daily upgrades the necessary changes to the systemd-fstab-generator were already merged (Thanks!), so I am waiting impatiently for the next systemd release to hit the arch repos. I am working on it, but there are a couple of things I still need to work on before the release. Sorry! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
Simon McVittie wrote on 09/09/14 19:02: Inside there would be a: /usr/lib/kernel/kernel-version/modules/ folder containing the actual modules (same as /lib/modules/kernel-version/kernel/) This seems like moving things around for the sake of moving things around. If Fedora, Debian and Mageia all use /lib/modules/kvers/kernel/ then it seems reasonably likely that everyone else does too. Well my only logic was that putting a vmlinuz file in /lib/modules/... tree doesn't sound right. I mean it's not a module - it's the actual kernel! But modules are modules of the kernel so keeping them inside a /lib/kernel/ feels OK. But if it's just not worth the hassle, then perhaps the kernel can just live in /lib/modules/kvers/vmlinuz Also, the kernel/ subdirectory does exist for a reason: it's where in-tree modules from that kernel go (as opposed to backports of newer drivers, or out-of-tree modules like kdbus). Fair enough. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
Tobias Hunger wrote on 05/09/14 19:34: Any place that you would care to recomend? It would suck to have each distro put kernels somewhere else. Good question. On Mageia and Fedora (at least originally, not sure if it's changed recently), the modules are in: /lib/modules/kernel-version/ tree. These days this should of course be: /usr/lib/modules/kernel-version/ The actual modules are stored in a: /lib/modules/kernel-version/kernel/ subfolder. If there are no compelling reasons to pick otherwise, we could use: /usr/lib/kernel/kernel-version/ tree. Inside there would be a: /usr/lib/kernel/kernel-version/modules/ folder containing the actual modules (same as /lib/modules/kernel-version/kernel/) For compatibility, the /lib/modules/kernel-version could be symlinked to /usr/lib/kernel/kernel-version and a simple modules - kernel symlink shipped inside the /usr/lib/kernel/kernel-version/ folder. All old paths would work in that case. The kernel itself could then simply be: /usr/lib/kernel/kernel-version/vmlinuz Not sure if this is just completely made up in my head or if this is how others have envisioned it also. I don't think any of the spec documents talked about the actual filesystem layout of the actual kernel files/modules. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On 09/09/14 16:01, Colin Guthrie wrote: On Mageia and Fedora (at least originally, not sure if it's changed recently), the modules are in: /lib/modules/kernel-version/ tree. ... The actual modules are stored in a: /lib/modules/kernel-version/kernel/ subfolder. It's the same on Debian and its derivatives, FWIW. Out-of-tree, backported or otherwise weird modules go in a different subdirectory of /lib/modules/kernel-version/. In particular, I think I've seen /lib/modules/kernel-version/updates/ used for backported versions of newer graphics drivers which should take precedence over the in-tree version. Inside there would be a: /usr/lib/kernel/kernel-version/modules/ folder containing the actual modules (same as /lib/modules/kernel-version/kernel/) This seems like moving things around for the sake of moving things around. If Fedora, Debian and Mageia all use /lib/modules/kvers/kernel/ then it seems reasonably likely that everyone else does too. Also, the kernel/ subdirectory does exist for a reason: it's where in-tree modules from that kernel go (as opposed to backports of newer drivers, or out-of-tree modules like kdbus). S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] So how am I supposed to put together my Linux system?
Hi I have read http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html with interest and since I am using a home-grown image based installation scheme anyway, I would like to try and move that closer to the proposal from the systemd cabal. It is pretty easy to create the suggested subvolumes, but I how to proceed from that point still is a bit unclear to me:-) How should I install kernels/initramfs though? I understood the plan to be to copy the kernel/initramfs into the EFI boot partion and to create boot loader entries linking the kernel/initramfs combo with the root file system. But where do those kernels come from? I would think the usr-subvolume is the best place for that. Did you recommend a place for the kernel/initramfs yet (E.g. usr-subvolume/boot) or do you expect the distributions to decide that? Do you consider a tool that will copy the kernel/initramfs from the usr-subvolumes into the EFI boot partition in scope for systemd or should the distributions handle that instead? I think the following steps are pretty generic and could be handled by a small tool shipped as part of systemd: * iterate over the usr-snapshots and get the kernel(s) and initramfs file(s) from all the snapshots boot directory (assuming you expect the distributions to put the kernels into /usr/boot). * copy those into the EFI boot partition. De-duplicate them while doing that. EFI boot partitions are FAT-based, so that will most likely require a bit of hashing as FS-based deduplication and hard-/softlinks are out:-) * create the necessary boot loader entry files according to the http://freedesktop.org/wiki/Specifications/BootLoaderSpec/ I need to give the root filesystem/subvolume with the usual kernel command line arguments, so that is not a problem. But how should the usr-subvolume be specified? Setting that in the root-subvolume makes little sense and the initramfs needs to mount /usr anyway, so I guess that will require more kernel command line arguments. Did you define those yet? I would suggest just using usrfs, usrflags and usrfstype (where the usrfs should default to rootfs and usrfstype to btrfs). Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On Fri, 05.09.14 16:19, Tobias Hunger (tobias.hun...@gmail.com) wrote: Hi I have read http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html with interest and since I am using a home-grown image based installation scheme anyway, I would like to try and move that closer to the proposal from the systemd cabal. It is pretty easy to create the suggested subvolumes, but I how to proceed from that point still is a bit unclear to me:-) How should I install kernels/initramfs though? I understood the plan to be to copy the kernel/initramfs into the EFI boot partion and to create boot loader entries linking the kernel/initramfs combo with the root file system. But where do those kernels come from? I would think the usr-subvolume is the best place for that. Did you recommend a place for the kernel/initramfs yet (E.g. usr-subvolume/boot) or do you expect the distributions to decide that? Yeah, we want to encourage distros to install kernels into /usr, somewhere next to where the kmods already are, and then copy that over where necessary into the used boot partition. We actually have sime infrastructure for this in place in systemd, in the install-kernel script, which also has a man page. Do you consider a tool that will copy the kernel/initramfs from the usr-subvolumes into the EFI boot partition in scope for systemd or should the distributions handle that instead? I think the following steps are pretty generic and could be handled by a small tool shipped as part of systemd: * iterate over the usr-snapshots and get the kernel(s) and initramfs file(s) from all the snapshots boot directory (assuming you expect the distributions to put the kernels into /usr/boot). * copy those into the EFI boot partition. De-duplicate them while doing that. EFI boot partitions are FAT-based, so that will most likely require a bit of hashing as FS-based deduplication and hard-/softlinks are out:-) * create the necessary boot loader entry files according to the http://freedesktop.org/wiki/Specifications/BootLoaderSpec/ I need to give the root filesystem/subvolume with the usual kernel command line arguments, so that is not a problem. But how should the usr-subvolume be specified? Setting that in the root-subvolume makes little sense and the initramfs needs to mount /usr anyway, so I guess that will require more kernel command line arguments. Did you define those yet? I would suggest just using usrfs, usrflags and usrfstype (where the usrfs should default to rootfs and usrfstype to btrfs). I think in the long run we really need to get to something where we easily can cover a mode similar to chromebooks, where we have a fully verified trust chain from the firmware to the apps we run on the OS. (Not saying that this is how developers and folks will use the stuff by default, but a large number fo setups will take benefit of it I am sure). Now for the trust chain to work, the secureboot firmware stuff would sign a kernel image. This kernel image would need the initrd appended, so that it can also be covered, and it would need to know its own identify, and then search for a btrfs volume, and for a volume that matches precisely what the kernel's identity is. The btrfs subvolume would carry verification data then, and the chain goes on from there. This of course means a couple of things: 1. we can only really have one file per boot menu entry, not three anymore as we have right now (for kernel + initrd + meta info for the cmdline and stuff), because we need the firmware to verify it and having external config files then is really hard to do 2. If we cannot have external config files, then kernel/initrd should find their stuff an empty kernel cmdline option. 3. As the signature on the kernel/initrd needs to come from the vendor we cannot build the initrd on the final system anymore, but need to support vendor-built initrds. Or in other words, the vendor would simply supply some file in /usr somewhere which is already the combined version of kernel and initrd, properly EFI signed, and we would then just copy that into the ESP after each upgrade. 4. The initrds should probably use information from /usr/lib/os-release (as shipped in the initrd as a copy of the OS' version) to build the btrfs sub-volume name to boot from. It should not allow overriding this name via the kernel cmdline, at least as long as we are in a mode where secureboot is actually turned on... Hope that makes some sense? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
Hi Lennart, thanks for taking the time to reply! On Fri, Sep 5, 2014 at 6:58 PM, Lennart Poettering lenn...@poettering.net wrote: Yeah, we want to encourage distros to install kernels into /usr, somewhere next to where the kmods already are, and then copy that over where necessary into the used boot partition. We actually have sime infrastructure for this in place in systemd, in the install-kernel script, which also has a man page. Any place that you would care to recomend? It would suck to have each distro put kernels somewhere else. I think in the long run we really need to get to something where we easily can cover a mode similar to chromebooks, where we have a fully verified trust chain from the firmware to the apps we run on the OS. (Not saying that this is how developers and folks will use the stuff by default, but a large number fo setups will take benefit of it I am sure). Now for the trust chain to work, the secureboot firmware stuff would sign a kernel image. This kernel image would need the initrd appended, so that it can also be covered, and it would need to know its own identify, and then search for a btrfs volume, and for a volume that matches precisely what the kernel's identity is. The btrfs subvolume would carry verification data then, and the chain goes on from there. This of course means a couple of things: 1. we can only really have one file per boot menu entry, not three anymore as we have right now (for kernel + initrd + meta info for the cmdline and stuff), because we need the firmware to verify it and having external config files then is really hard to do I want to be able to do atomic upgrades (like chromeos/coreos), so I need to be able to give the root-subvolume (the system I want to boot) and the usr-subvolume (the software configuration I want to boot). I see that secure boot wants one file and that you will need to merge kernel and initrd into one. But you will need the meta data to link the kernel/initrd combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos also has that and stores that meta-data in non-volatile memory accessible to the BIOS. 2. If we cannot have external config files, then kernel/initrd should find their stuff an empty kernel cmdline option. Nice ideal, but I do not see how that will work in general. You could bake some id into the kernel (kernel version or whatever), but usually the kernel changes slower than the sum of the files in /usr. You do want to boot different of these usr-setups with one kernel. 3. As the signature on the kernel/initrd needs to come from the vendor we cannot build the initrd on the final system anymore, but need to support vendor-built initrds. Or in other words, the vendor would simply supply some file in /usr somewhere which is already the combined version of kernel and initrd, properly EFI signed, and we would then just copy that into the ESP after each upgrade. At this point the way the initrd is created seems more like an implementation detail to me. But then I know too little about secure boot to know for sure. My current problem is how to make my machine boot again with the kernel/initrd I put into my usr-subvolume:-) 4. The initrds should probably use information from /usr/lib/os-release (as shipped in the initrd as a copy of the OS' version) to build the btrfs sub-volume name to boot from. It should not allow overriding this name via the kernel cmdline, at least as long as we are in a mode where secureboot is actually turned on... That could work, provided there is something like a timestamp/version number in /usr/lib/os-release that actually changes every time *anything* in /usr changes (or at least when those changes are getting distributed as an image). You still need to store that information somewhere though for the kernel to know what to boot. Hope that makes some sense? Not really. I do see how this can work to boot the newest installation of distroX: You just need to look for the newest version of the usr-subvolume and boot that. But how do I know which root-subvolume goes with that if there is more than one? How do I boot the version I ran before the upgrade in case the upgrade failed? I really do not see how you can get around storing meta-data somehow. You can not change the kernel/initrd when it is signed, so you can not bake any information into that file. You can apparently not have a separate file when using secure boot. That leaves EFI vars I think. Do those integrate with secure boot? Anyway: For starters I would like to get the non-secure-boot case rolling. A entry for the boot loader with kernel command line settings does work there:-) So how should the usr-subvolume be defined in that use-case? Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] So how am I supposed to put together my Linux system?
On Fri, Sep 05, 2014 at 08:34:56PM +0200, Tobias Hunger wrote: I see that secure boot wants one file and that you will need to merge kernel and initrd into one. But you will need the meta data to link the kernel/initrd combo to a combination of root-subvolume and usr-subvolume. IIRC chromeos also has that and stores that meta-data in non-volatile memory accessible to the BIOS. I've been wanting the ability to take a kernel image and add/replace an initrd to the end of it after it is built and remain a single image that you can then sign/copy/whatever. You can't do that today due to some static variables in the initrd image. I started to hack it up a while ago, need to carve up some time to revisit that to fix this issue, which should make some of this easier. sorry for the digression, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
