| Message ID | 20230909161851.223627-1-kernel@jfarr.cc (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86/kexec: UKI support | expand |
On Sat, 9 Sept 2023 at 17:19, Jan Hendrik Farr <kernel@jfarr.cc> wrote: > > Hello, > > this patch implements UKI support for kexec_file_load. It will require support > in the kexec-tools userspace utility. For testing purposes the following can be used: > https://github.com/Cydox/kexec-test/ > > There has been discussion on this topic in an issue on GitHub that is linked below > for reference. > > > Some links: > - Related discussion: https://github.com/systemd/systemd/issues/28538 > - Documentation of UKIs: https://uapi-group.org/specifications/specs/unified_kernel_image/ > > Jan Hendrik Farr (1): > x86/kexec: UKI support Hi, Thanks for working on this, it looks super useful and at Microsoft we are definitely interested in it, as we rely heavily on kexec and we are looking to switch to UKIs. I had a quick look, two comments: - the cmdline section is actually optional, just like it's optional to pass it on a traditional kexec load, so it should be used if present, but skipped if not - the dtb section also is optional but supported, and given kexec supports loading a new dtb I think this change should support it too immediately. Moreover, we are adding support for multiple DTBs in a single UKI (by simply having multiple .dtb sections, and picking the one that matches the firmware), as a stretch goal would be nice to support that too, but it can also come later - also what would it take to support arm64, which is the other major UEFI arch?
> - the cmdline section is actually optional, just like it's optional to > pass it on a traditional kexec load, so it should be used if present, > but skipped if not Should be an easy fix. This should be updated in the UKI documentation as for other optional sections it's explicitly marked. I assumed that in the case of an empty cmdline the section would still be included but empty. Or is that semantically different: empty .cmdline section -> no cmdline allowed, no .cmdline section -> user can specify cmdline in bootloader? > - the dtb section also is optional but supported, and given kexec > supports loading a new dtb I think this change should support it too > immediately. Moreover, we are adding support for multiple DTBs in a > single UKI (by simply having multiple .dtb sections, and picking the > one that matches the firmware), as a stretch goal would be nice to > support that too, but it can also come later As far as I know dtb is not supported by kexec_file_load at all at the moment. Maybe someone here knows more about this. I'll look into it. > - also what would it take to support arm64, which is the other major UEFI arch? I'm not familiar with UEFI on arm64, but I can certainly look into it. I assume it's not gonna be that difficult.
On Sat, 9 Sept 2023 at 18:58, Jan Hendrik Farr <kernel@jfarr.cc> wrote: > > > - the cmdline section is actually optional, just like it's optional to > > pass it on a traditional kexec load, so it should be used if present, > > but skipped if not > > Should be an easy fix. > > This should be updated in the UKI documentation as for other optional sections it's explicitly marked. I assumed that in the case of an empty cmdline the section would still be included but empty. Or is that semantically different: empty .cmdline section -> no cmdline allowed, no .cmdline section -> user can specify cmdline in bootloader? Yeah the doc is wrong, tools handle it as optional, fixing the docs: https://github.com/uapi-group/specifications/pull/72 > > - the dtb section also is optional but supported, and given kexec > > supports loading a new dtb I think this change should support it too > > immediately. Moreover, we are adding support for multiple DTBs in a > > single UKI (by simply having multiple .dtb sections, and picking the > > one that matches the firmware), as a stretch goal would be nice to > > support that too, but it can also come later > > As far as I know dtb is not supported by kexec_file_load at all at the moment. Maybe someone here knows more about this. I'll look into it. Not sure about the specific syscalls, but I definitely use kexec --load --dtb on arm64 with existing released versions of kernel/tooling > > - also what would it take to support arm64, which is the other major UEFI arch? > > I'm not familiar with UEFI on arm64, but I can certainly look into it. I assume it's not gonna be that difficult.
>> > - the dtb section also is optional but supported, and given kexec >> > supports loading a new dtb I think this change should support it too >> > immediately. Moreover, we are adding support for multiple DTBs in a >> > single UKI (by simply having multiple .dtb sections, and picking the >> > one that matches the firmware), as a stretch goal would be nice to >> > support that too, but it can also come later >> >> As far as I know dtb is not supported by kexec_file_load at all at the moment. Maybe someone here knows more about this. I'll look into it. > > Not sure about the specific syscalls, but I definitely use kexec > --load --dtb on arm64 with existing released versions of > kernel/tooling Ok, it looks like this is supported and should be doable (on arm64, not for x86). When I was looking around the source code yesterday I forgot that my LSP had indexed the kernel for x86 and not arm64. >> > - also what would it take to support arm64, which is the other major UEFI arch? >> >> I'm not familiar with UEFI on arm64, but I can certainly look into it. I assume it's not gonna be that difficult. I'll work on a separate patch for UKI support on arm64 (with .dtb section support). I think it's best to keep this x86 patch separate from that. I have a v2 patch for x86 put together with the small fix for the optional .cmdline section + a few other tweaks that I'll submit shortly.
On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > Hello, > > this patch implements UKI support for kexec_file_load. It will require support > in the kexec-tools userspace utility. For testing purposes the following can be used: > https://github.com/Cydox/kexec-test/ > > There has been discussion on this topic in an issue on GitHub that is linked below > for reference. > > > Some links: > - Related discussion: https://github.com/systemd/systemd/issues/28538 > - Documentation of UKIs: https://uapi-group.org/specifications/specs/unified_kernel_image/ > > Jan Hendrik Farr (1): > x86/kexec: UKI support > > arch/x86/include/asm/kexec-uki.h | 7 ++ > arch/x86/include/asm/parse_pefile.h | 32 +++++++ > arch/x86/kernel/Makefile | 2 + > arch/x86/kernel/kexec-uki.c | 113 +++++++++++++++++++++++++ > arch/x86/kernel/machine_kexec_64.c | 2 + > arch/x86/kernel/parse_pefile.c | 110 ++++++++++++++++++++++++ > crypto/asymmetric_keys/mscode_parser.c | 2 +- > crypto/asymmetric_keys/verify_pefile.c | 110 +++--------------------- > crypto/asymmetric_keys/verify_pefile.h | 16 ---- > 9 files changed, 278 insertions(+), 116 deletions(-) > create mode 100644 arch/x86/include/asm/kexec-uki.h > create mode 100644 arch/x86/include/asm/parse_pefile.h > create mode 100644 arch/x86/kernel/kexec-uki.c > create mode 100644 arch/x86/kernel/parse_pefile.c > > -- > 2.40.1 What the heck is UKI? BR, Jarkko
> What the heck is UKI?
UKI (Unified Kernel Image) is the kernel image + initrd + cmdline (+ some other optional stuff) all packaged up together as one EFI application.
This EFI application can then be launched directly by the UEFI without the need for any additional stuff (or by systemd-boot). It's all self contained. One benefit is that this is a convenient way to distribute kernels all in one file. Another benefit is that the whole combination of kernel image, initrd, and cmdline can all be signed together so only that particular combination can be executed if you are using secure boot.
The format itself is rather simple. It's just a PE file (as required by the UEFI spec) that contains a small stub application in the .text, .data, etc sections that is responsible for invoking the contained kernel and initrd with the contained cmdline. The kernel image is placed into a .kernel section, the initrd into a .initrd section, and the cmdline into a .cmdline section in the PE executable.
If we want to kexec a UKI we could obviously just have userspace pick it apart and kexec it like normal. However in lockdown mode this will only work if you sign the kernel image that is contained inside the UKI. The problem with that is that anybody can then grab that signed kernel and launch it with any initrd or cmdline. So instead this patch makes the kernel do the work instead. The kernel verifies the signature on the entire UKI and then passes its components on to the normal kexec bzimage loader.
Useful Links:
UKI format documentation: https://uapi-group.org/specifications/specs/unified_kernel_image/
Arch wiki: https://wiki.archlinux.org/title/Unified_kernel_image
Fedora UKI support: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > > Hello, > > > > this patch implements UKI support for kexec_file_load. It will require support > > in the kexec-tools userspace utility. For testing purposes the following can be used: > > https://github.com/Cydox/kexec-test/ > > > > There has been discussion on this topic in an issue on GitHub that is linked below > > for reference. > > > > > > Some links: > > - Related discussion: https://github.com/systemd/systemd/issues/28538 > > - Documentation of UKIs: https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > Jan Hendrik Farr (1): > > x86/kexec: UKI support > > > > arch/x86/include/asm/kexec-uki.h | 7 ++ > > arch/x86/include/asm/parse_pefile.h | 32 +++++++ > > arch/x86/kernel/Makefile | 2 + > > arch/x86/kernel/kexec-uki.c | 113 +++++++++++++++++++++++++ > > arch/x86/kernel/machine_kexec_64.c | 2 + > > arch/x86/kernel/parse_pefile.c | 110 ++++++++++++++++++++++++ > > crypto/asymmetric_keys/mscode_parser.c | 2 +- > > crypto/asymmetric_keys/verify_pefile.c | 110 +++--------------------- > > crypto/asymmetric_keys/verify_pefile.h | 16 ---- > > 9 files changed, 278 insertions(+), 116 deletions(-) > > create mode 100644 arch/x86/include/asm/kexec-uki.h > > create mode 100644 arch/x86/include/asm/parse_pefile.h > > create mode 100644 arch/x86/kernel/kexec-uki.c > > create mode 100644 arch/x86/kernel/parse_pefile.c > > > > -- > > 2.40.1 > > What the heck is UKI? Unified Kernel Images. More details available here: https://uapi-group.org/specifications/specs/unified_kernel_image/ It's a way of creating initramfs-style images as fully generic, reproducible images that can be built server-side. It is a requirement for creating locked down Linux devices for appliances that can be tamper-resistant too. -- 真実はいつも一つ！/ Always, there's only one truth!
On Tue Sep 12, 2023 at 1:54 AM EEST, Jan Hendrik Farr wrote: > > What the heck is UKI? > > UKI (Unified Kernel Image) is the kernel image + initrd + cmdline (+ > some other optional stuff) all packaged up together as one EFI > application. > > This EFI application can then be launched directly by the UEFI without > the need for any additional stuff (or by systemd-boot). It's all self > contained. One benefit is that this is a convenient way to distribute > kernels all in one file. Another benefit is that the whole combination > of kernel image, initrd, and cmdline can all be signed together so > only that particular combination can be executed if you are using > secure boot. Is this also for generic purpose distributions? I mean it is not uncommon having to tweak the command-line in a workstation. > The format itself is rather simple. It's just a PE file (as required > by the UEFI spec) that contains a small stub application in the .text, > .data, etc sections that is responsible for invoking the contained > kernel and initrd with the contained cmdline. The kernel image is > placed into a .kernel section, the initrd into a .initrd section, and > the cmdline into a .cmdline section in the PE executable. How does this interact with the existing EFI stub support in linux? > If we want to kexec a UKI we could obviously just have userspace pick > it apart and kexec it like normal. However in lockdown mode this will > only work if you sign the kernel image that is contained inside the > UKI. The problem with that is that anybody can then grab that signed > kernel and launch it with any initrd or cmdline. So instead this patch > makes the kernel do the work instead. The kernel verifies the > signature on the entire UKI and then passes its components on to the > normal kexec bzimage loader. > > Useful Links: > UKI format documentation: https://uapi-group.org/specifications/specs/unified_kernel_image/ > Arch wiki: https://wiki.archlinux.org/title/Unified_kernel_image > Fedora UKI support: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 BR, Jarkko
On Tue Sep 12, 2023 at 2:20 AM EEST, Neal Gompa wrote: > On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > > > Hello, > > > > > > this patch implements UKI support for kexec_file_load. It will require support > > > in the kexec-tools userspace utility. For testing purposes the following can be used: > > > https://github.com/Cydox/kexec-test/ > > > > > > There has been discussion on this topic in an issue on GitHub that is linked below > > > for reference. > > > > > > > > > Some links: > > > - Related discussion: https://github.com/systemd/systemd/issues/28538 > > > - Documentation of UKIs: https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > > > Jan Hendrik Farr (1): > > > x86/kexec: UKI support > > > > > > arch/x86/include/asm/kexec-uki.h | 7 ++ > > > arch/x86/include/asm/parse_pefile.h | 32 +++++++ > > > arch/x86/kernel/Makefile | 2 + > > > arch/x86/kernel/kexec-uki.c | 113 +++++++++++++++++++++++++ > > > arch/x86/kernel/machine_kexec_64.c | 2 + > > > arch/x86/kernel/parse_pefile.c | 110 ++++++++++++++++++++++++ > > > crypto/asymmetric_keys/mscode_parser.c | 2 +- > > > crypto/asymmetric_keys/verify_pefile.c | 110 +++--------------------- > > > crypto/asymmetric_keys/verify_pefile.h | 16 ---- > > > 9 files changed, 278 insertions(+), 116 deletions(-) > > > create mode 100644 arch/x86/include/asm/kexec-uki.h > > > create mode 100644 arch/x86/include/asm/parse_pefile.h > > > create mode 100644 arch/x86/kernel/kexec-uki.c > > > create mode 100644 arch/x86/kernel/parse_pefile.c > > > > > > -- > > > 2.40.1 > > > > What the heck is UKI? > > Unified Kernel Images. More details available here: > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > It's a way of creating initramfs-style images as fully generic, > reproducible images that can be built server-side. You can build today a kernel with these compiled in: 1. EFI stub 2. initeramfs 3. cmdline Why another way (and label 'UKI') for a pre-existing feature? BR, Jarkko
On Tue, Sep 12, 2023, at 12:33 PM, Jarkko Sakkinen wrote: > On Tue Sep 12, 2023 at 1:54 AM EEST, Jan Hendrik Farr wrote: >> > What the heck is UKI? >> >> UKI (Unified Kernel Image) is the kernel image + initrd + cmdline (+ >> some other optional stuff) all packaged up together as one EFI >> application. >> >> This EFI application can then be launched directly by the UEFI without >> the need for any additional stuff (or by systemd-boot). It's all self >> contained. One benefit is that this is a convenient way to distribute >> kernels all in one file. Another benefit is that the whole combination >> of kernel image, initrd, and cmdline can all be signed together so >> only that particular combination can be executed if you are using >> secure boot. > > Is this also for generic purpose distributions? I mean it is not > uncommon having to tweak the command-line in a workstation. This is for generic purpose distributions. See fedora's planned rollout: https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 Or Arch: https://wiki.archlinux.org/title/Unified_kernel_image There are UKI addons that help you achieve this. These are additional PE files that contain for example additional cmdline parameters. On a generic Linux distro doing secure boot you'd generally use shim, could enroll MOK and use that to sign an addon for your machine. This patch currently does not support addons. The plan would be to support them in the future though. I personally always run my own compiled kernel and build a UKI from that so I can obviously tweak the cmdline that way and sign the UKI with my own secure boot key. >> The format itself is rather simple. It's just a PE file (as required >> by the UEFI spec) that contains a small stub application in the .text, >> .data, etc sections that is responsible for invoking the contained >> kernel and initrd with the contained cmdline. The kernel image is >> placed into a .kernel section, the initrd into a .initrd section, and >> the cmdline into a .cmdline section in the PE executable. > > How does this interact with the existing EFI stub support in linux? It doesn't. During normal boot of a UKI the stub in it is used (systemd-stub, see: https://www.freedesktop.org/software/systemd/man/systemd-stub.html). The kernel's own EFI stub will still be in the binary inside the .linux section but not used. Now in this patch (also see v2 I already posted) obviously non of the stubs are used.
On Tue Sep 12, 2023 at 6:32 PM EEST, Jan Hendrik Farr wrote: > >> The format itself is rather simple. It's just a PE file (as required > >> by the UEFI spec) that contains a small stub application in the .text, > >> .data, etc sections that is responsible for invoking the contained > >> kernel and initrd with the contained cmdline. The kernel image is > >> placed into a .kernel section, the initrd into a .initrd section, and > >> the cmdline into a .cmdline section in the PE executable. > > > > How does this interact with the existing EFI stub support in linux? > > It doesn't. During normal boot of a UKI the stub in it is used > (systemd-stub, see: > https://www.freedesktop.org/software/systemd/man/systemd-stub.html). > The kernel's own EFI stub will still be in the binary inside the > .linux section but not used. What sort of bottleneck does the EFI stub have so that we need yet another envelope? BR, Jarkko
> What sort of bottleneck does the EFI stub have so that we need yet > another envelope? Well I can come up with a few advantages of UKI compared to normal bzImage with builtin initrd and cmdline. 1. You already identified this one. Using addons to adjust your cmdline 2. I can use my normal initramfs generation tooling. Just install my compiled kernel, my distros install script will generate the initramfs. Then I package it up as a UKI. This will be a lot more awkward with a builtin initrd. 3. Measured boot. You can place PCR signatures in the UKI using systemd-measure. This will sign the expected PCR values for booting this UKI. I think with normal bzImage this will be a lot more difficult. If you place those PCR signatures in the builtin initrd this will change the kernel image which means now the values you signed no longer match (depending on how you measure the kernel; I don't think the normal EFI stub even measures the kernel in first place, but I could be mistaken about this) 4. UKIs are automatically recognized by systemd-boot There's probably more reasons. The main reason for me to go with UKIs initially was the good tooling around them. You could probably overcome some of these drawbacks in the default kernel EFI stub. For example it could also get a place to put signed PCR values. And it could also do TPM measurements. However in the process all you're doing is rebuilding what already exists today in systemd-stub and the tooling around UKIs.
On Tue Sep 12, 2023 at 9:56 PM EEST, Jan Hendrik Farr wrote: > > What sort of bottleneck does the EFI stub have so that we need yet > > another envelope? > > Well I can come up with a few advantages of UKI compared to normal bzImage with builtin initrd and cmdline. > > 1. You already identified this one. Using addons to adjust your cmdline It is not a benefit as this is already possible today. > 2. I can use my normal initramfs generation tooling. Just install my > compiled kernel, my distros install script will generate the > initramfs. Then I package it up as a UKI. This will be a lot more > awkward with a builtin initrd. > 3. Measured boot. You can place PCR signatures in the UKI using > systemd-measure. This will sign the expected PCR values for booting > this UKI. I think with normal bzImage this will be a lot more > difficult. If you place those PCR signatures in the builtin initrd > this will change the kernel image which means now the values you > signed no longer match (depending on how you measure the kernel; I > don't think the normal EFI stub even measures the kernel in first > place, but I could be mistaken about this) > 4. UKIs are automatically recognized by systemd-boot These are sort of "tautological" arguments. There must be some objective reasons why this architecture was chosen instead of other (i.e. using what already pre-exists). BR, Jarkko
> These are sort of "tautological" arguments. There must be some > objective reasons why this architecture was chosen instead of > other (i.e. using what already pre-exists). You mean like your argument that the same can already be achieved with the normal EFI stub and builin initrd/cmdline? ;) I think only reasons #4 and the last paragraph in me response relate to it being pre-existing. The other reasons are actual limitations with the normal EFI stub setup. Doesn't mean that they can't be overcome, but UKIs work. I'm not sure what the initial reasons where for coming up with this architecture were, I was not involved. What I can tell you is that right now it is a format that has practical advantages and that there are generic mainstream distros looking to adopt it. So having the capability to kexec them is gonna come in handy.
> These are sort of "tautological" arguments. There must be some > objective reasons why this architecture was chosen instead of > other (i.e. using what already pre-exists). I think I misunderstood you in my earlier reply. I do not understand in what way you think my arguments are tautological. Can you elaborate?
On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote: > > > These are sort of "tautological" arguments. There must be some > > objective reasons why this architecture was chosen instead of > > other (i.e. using what already pre-exists). > > I think I misunderstood you in my earlier reply. I do not understand > in what way you think my arguments are tautological. Can you > elaborate? current Linux kernel has these features *already* in place: 1. CONFIG_EFI_STUB 2. CONFIG_CMDLINE 3. CONFIG_INITRAMFS_SOURCE 4. Secure boot with MOK keys and .machine keyring to manage them. Given that every single feature in IKU does exists in some form in the Linux kernel, I think it is fair to ask why scrape away this all existing science and reinvent the wheel? If your reponse is "systemd", it is a tautological answerk, i.e. same as sayig that "it is good because it is good". Not very motivating. BR, Jarkko
On Wed, Sep 13, 2023, at 4:45 PM, Jarkko Sakkinen wrote: > On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote: >> >> > These are sort of "tautological" arguments. There must be some >> > objective reasons why this architecture was chosen instead of other >> > (i.e. using what already pre-exists). >> >> I think I misunderstood you in my earlier reply. I do not understand >> in what way you think my arguments are tautological. Can you >> elaborate? > > current Linux kernel has these features *already* in place: > > 1. CONFIG_EFI_STUB > 2. CONFIG_CMDLINE > 3. CONFIG_INITRAMFS_SOURCE > 4. Secure boot with MOK keys and .machine keyring to manage them. Well, you also have to add 5. CONFIG_CMDLINE_OVERRIDE 6. CONFIG_INITRAMFS_FORCE Otherwise the bootloader can supply an unsinged initramfs/cmdline and the kernel will use them. And then you do not get all the features. One of your earlier responses asks how a user might change the cmdline with UKIs. With UKIs all they have to do is create a small addon file and sign that (with their MOK if they are using a generic distro with shim, instead of using their own secure boot keys). With the bzImage alternative they would have to recompile the kernel. This was reason #1. Also what about #3? How would you pass PCR signatures using the normal EFI stub / bzImage? I can see how #4 is kinda tautological, but please don't dismiss the other arguments without even responding. > Given that every single feature in IKU does exists in some form in the > Linux kernel, I think it is fair to ask why scrape away this all > existing science and reinvent the wheel? No, not every single feature of *UKI*s exist in the linux kernel today. > If your reponse is "systemd", it is a tautological answerk, i.e. same > as sayig that "it is good because it is good". Not very motivating. Again for #4 I see the point, but what about #1 , and #3 (#2 is not that important, tooling can be fixed)? Also, do you see how your argument is basically: "The current way is better because it is the current way." I'm not trying to be snarky. But I'm coming from the perspective of a user that actually experienced a problem (not being able to kexec my UKIs) and trying to come up with a fix. I'm not trying to push something for the heck of it. Also the UKI spec at this point is not ready for the kernel, so this is not going in anyways right now. See the discussion on v2: https://lore.kernel.org/kexec/ZP+41JvEFjsnEG19@MiWiFi-R3L-srv/T/#t
On Wed Sep 13, 2023 at 6:07 PM EEST, Jan Hendrik Farr wrote: > On Wed, Sep 13, 2023, at 4:45 PM, Jarkko Sakkinen wrote: > > On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote: > >> > >> > These are sort of "tautological" arguments. There must be some > >> > objective reasons why this architecture was chosen instead of other > >> > (i.e. using what already pre-exists). > >> > >> I think I misunderstood you in my earlier reply. I do not understand > >> in what way you think my arguments are tautological. Can you > >> elaborate? > > > > current Linux kernel has these features *already* in place: > > > > 1. CONFIG_EFI_STUB > > 2. CONFIG_CMDLINE > > 3. CONFIG_INITRAMFS_SOURCE > > 4. Secure boot with MOK keys and .machine keyring to manage them. > > Well, you also have to add > 5. CONFIG_CMDLINE_OVERRIDE > 6. CONFIG_INITRAMFS_FORCE > > Otherwise the bootloader can supply an unsinged initramfs/cmdline and > the kernel will use them. > > And then you do not get all the features. One of your earlier responses > asks how a user might change the cmdline with UKIs. With UKIs all they > have to do is create a small addon file and sign that (with their MOK if > they are using a generic distro with shim, instead of using their own > secure boot keys). With the bzImage alternative they would have to > recompile the kernel. This was reason #1. > > Also what about #3? How would you pass PCR signatures using the normal > EFI stub / bzImage? I did not notice anything in the description about PCRs but this counter-question does really enlighten what I've been trying to say. You should take time to explain where's the gain, and why it makes sense for the users. It does not really make sense for me to "defend" anything if I'm against something that I don't understand what it is and is capable of and such and so forth. I don't really care if e.g. systemd is using it, if it does not make me understand the topic better. It is then just argument by authority, which not a real argument in the first place. Linking URL to the specification is good enough for *details* but it does not save you from trouble of painting the picture what we are looking at. BR, Jarkko
On Di, 12.09.23 17:32, Jan Hendrik Farr (kernel@jfarr.cc) wrote: > >> The format itself is rather simple. It's just a PE file (as required > >> by the UEFI spec) that contains a small stub application in the .text, > >> .data, etc sections that is responsible for invoking the contained > >> kernel and initrd with the contained cmdline. The kernel image is > >> placed into a .kernel section, the initrd into a .initrd section, and > >> the cmdline into a .cmdline section in the PE executable. > > > > How does this interact with the existing EFI stub support in > > linux? > > It doesn't. During normal boot of a UKI the stub in it is used > (systemd-stub, see: > https://www.freedesktop.org/software/systemd/man/systemd-stub.html). The > kernel's own EFI stub will still be in the binary inside the .linux > section but not used. That's not true actually, if the inner kernel supports the EFI stub then systemd-stub actually defers to that for kernel execution. It's more portable that way, since the kernel then deals with the differences in the boot protocol on different architectures. Lennart -- Lennart Poettering, Berlin
On Mi, 13.09.23 17:45, Jarkko Sakkinen (jarkko@kernel.org) wrote: > On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote: > > > > > These are sort of "tautological" arguments. There must be some > > > objective reasons why this architecture was chosen instead of > > > other (i.e. using what already pre-exists). > > > > I think I misunderstood you in my earlier reply. I do not understand > > in what way you think my arguments are tautological. Can you > > elaborate? > > current Linux kernel has these features *already* in > place: > > 1. CONFIG_EFI_STUB > 2. CONFIG_CMDLINE > 3. CONFIG_INITRAMFS_SOURCE > 4. Secure boot with MOK keys and .machine keyring to manage them. > > Given that every single feature in IKU does exists in some form > in the Linux kernel, I think it is fair to ask why scrape away > this all existing science and reinvent the wheel? Nah, systemd-stub does considerably more than what you list above. 1. It measures the components of the UKI separately into PCR 11, 12, 13, which makes the mesaurements predictable, and allows vendors to provide a signed PCR policy with can be used to unlock TPM2 secrets that ause a PolicyAuthorize policy. This is a fundamental improvement over mechanisms that bind to literal PCR values, since the "brittleness" goes away. 2. That said signed PCR policy is included in the UKI in another PE section, that is made available to userspace. 3. If you like it brings a boot splash to screen before passing control off to the kernel, which is also contained 4. It can contain a devicetree blob, which it will setup for the kernel it spawns 5. There's a random seed maintained by systemd-stub in the ESP that is updated and passed to the kernel, which includes in in the pool. 6. It picks up "credentials" (which are TPM protected, encrypted, authenticated supported by systemd) that can be used to securely parameterize the invoked system from the backing fs (i.e. the ESP). Similar it can pick up sysext images (which is another systemd thing, i.e. dm-verity protected, signed disk images which can extend the initrd and the host, by being overlayed on /usr). 7. It picks up "add-ons" -- which are PE binaries that actually contain no code, but are SecureBoot signed/shim signed "mules" for carrying addition kernel cmdlines, devictree blobs (and maybe in future initrds) that allow some form of modularity in the UKI model. And there's more. This is just off the top of my head. Now, I can totally see you personally might not need any of this stuff, fine, but a claim that this stuff is redundant is just bogus. Afaics all big distributions are preparing to providing UKIs soonishly. It would be fantastic if kexec would just work with this too, and the dissection would be done on the kernel side instead of userspace. Lennart -- Lennart Poettering, Berlin
On Thu Sep 14, 2023 at 11:48 AM EEST, Lennart Poettering wrote: > On Di, 12.09.23 17:32, Jan Hendrik Farr (kernel@jfarr.cc) wrote: > > > >> The format itself is rather simple. It's just a PE file (as required > > >> by the UEFI spec) that contains a small stub application in the .text, > > >> .data, etc sections that is responsible for invoking the contained > > >> kernel and initrd with the contained cmdline. The kernel image is > > >> placed into a .kernel section, the initrd into a .initrd section, and > > >> the cmdline into a .cmdline section in the PE executable. > > > > > > How does this interact with the existing EFI stub support in > > > linux? > > > > It doesn't. During normal boot of a UKI the stub in it is used > > (systemd-stub, see: > > https://www.freedesktop.org/software/systemd/man/systemd-stub.html). The > > kernel's own EFI stub will still be in the binary inside the .linux > > section but not used. > > That's not true actually, if the inner kernel supports the EFI stub > then systemd-stub actually defers to that for kernel execution. It's > more portable that way, since the kernel then deals with the > differences in the boot protocol on different architectures. OK, that's nice. > Lennart > > -- > Lennart Poettering, Berlin BR, Jarkko
On Thu Sep 14, 2023 at 12:11 PM EEST, Lennart Poettering wrote: > On Mi, 13.09.23 17:45, Jarkko Sakkinen (jarkko@kernel.org) wrote: > > > On Tue Sep 12, 2023 at 11:49 PM EEST, Jan Hendrik Farr wrote: > > > > > > > These are sort of "tautological" arguments. There must be some > > > > objective reasons why this architecture was chosen instead of > > > > other (i.e. using what already pre-exists). > > > > > > I think I misunderstood you in my earlier reply. I do not understand > > > in what way you think my arguments are tautological. Can you > > > elaborate? > > > > current Linux kernel has these features *already* in > > place: > > > > 1. CONFIG_EFI_STUB > > 2. CONFIG_CMDLINE > > 3. CONFIG_INITRAMFS_SOURCE > > 4. Secure boot with MOK keys and .machine keyring to manage them. > > > > Given that every single feature in IKU does exists in some form > > in the Linux kernel, I think it is fair to ask why scrape away > > this all existing science and reinvent the wheel? > > Nah, systemd-stub does considerably more than what you list above. > > 1. It measures the components of the UKI separately into PCR 11, 12, > 13, which makes the mesaurements predictable, and allows vendors to > provide a signed PCR policy with can be used to unlock TPM2 secrets > that ause a PolicyAuthorize policy. This is a fundamental > improvement over mechanisms that bind to literal PCR values, since > the "brittleness" goes away. I guess this is an appropriate reference: https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/ I quickly checked what sort of use cases we have for PCRs in the kernel. I could spot one: https://www.kernel.org/doc/html/v6.5/security/keys/trusted-encrypted.html Generally, my only concern here is potential conflicts with user space extending the same PCRs as systemd does. Since this all is only used for boot phase I guess this should not be an issue, right? > 2. That said signed PCR policy is included in the UKI in another PE > section, that is made available to userspace. > 3. If you like it brings a boot splash to screen before passing > control off to the kernel, which is also contained > 4. It can contain a devicetree blob, which it will setup for the > kernel it spawns > 5. There's a random seed maintained by systemd-stub in the ESP that is > updated and passed to the kernel, which includes in in the pool. > 6. It picks up "credentials" (which are TPM protected, encrypted, > authenticated supported by systemd) that can be used to securely > parameterize the invoked system from the backing fs (i.e. the > ESP). Similar it can pick up sysext images (which is another > systemd thing, i.e. dm-verity protected, signed disk images which > can extend the initrd and the host, by being overlayed on /usr). > 7. It picks up "add-ons" -- which are PE binaries that actually contain > no code, but are SecureBoot signed/shim signed "mules" for carrying > addition kernel cmdlines, devictree blobs (and maybe in future > initrds) that allow some form of modularity in the UKI model. > > And there's more. This is just off the top of my head. > > Now, I can totally see you personally might not need any of this > stuff, fine, but a claim that this stuff is redundant is just bogus. Backing story was missing completely. Please add this reasoning to the patch set in some form (cover letter and possibly some patch descriptions). It is bogus without proper context, which is totally different than my personal use. The response that I received was more related to personal use. It took quite many emails to learn about PCR usage. IMHO that should have been told here so that we can then e.g. inspect possible conflicts etc. > Afaics all big distributions are preparing to providing UKIs > soonishly. It would be fantastic if kexec would just work with this > too, and the dissection would be done on the kernel side instead of > userspace. I don't see any existential reasons anymore not to include this to the mainline but it takes what it takes in terms of time span of course. > > Lennart > > -- > Lennart Poettering, Berlin BR, Jarkko
On Tue, 12 Sept 2023 at 11:38, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Tue Sep 12, 2023 at 2:20 AM EEST, Neal Gompa wrote: > On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > > > > Hello, > > > > > > > > this patch implements UKI support for kexec_file_load. It will require support > > > > in the kexec-tools userspace utility. For testing purposes the following can be used: > > > > https://github.com/Cydox/kexec-test/ > > > > > > > > There has been discussion on this topic in an issue on GitHub that is linked below > > > > for reference. > > > > > > > > > > > > Some links: > > > > - Related discussion: https://github.com/systemd/systemd/issues/28538 > > > > - Documentation of UKIs: https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > > > > > Jan Hendrik Farr (1): > > > > x86/kexec: UKI support > > > > > > > > arch/x86/include/asm/kexec-uki.h | 7 ++ > > > > arch/x86/include/asm/parse_pefile.h | 32 +++++++ > > > > arch/x86/kernel/Makefile | 2 + > > > > arch/x86/kernel/kexec-uki.c | 113 +++++++++++++++++++++++++ > > > > arch/x86/kernel/machine_kexec_64.c | 2 + > > > > arch/x86/kernel/parse_pefile.c | 110 ++++++++++++++++++++++++ > > > > crypto/asymmetric_keys/mscode_parser.c | 2 +- > > > > crypto/asymmetric_keys/verify_pefile.c | 110 +++--------------------- > > > > crypto/asymmetric_keys/verify_pefile.h | 16 ---- > > > > 9 files changed, 278 insertions(+), 116 deletions(-) > > > > create mode 100644 arch/x86/include/asm/kexec-uki.h > > > > create mode 100644 arch/x86/include/asm/parse_pefile.h > > > > create mode 100644 arch/x86/kernel/kexec-uki.c > > > > create mode 100644 arch/x86/kernel/parse_pefile.c > > > > > > > > -- > > > > 2.40.1 > > > > > > What the heck is UKI? > > > > Unified Kernel Images. More details available here: > > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > It's a way of creating initramfs-style images as fully generic, > > reproducible images that can be built server-side. > > You can build today a kernel with these compiled in: > > 1. EFI stub > 2. initeramfs > 3. cmdline > > Why another way (and label 'UKI') for a pre-existing feature? > In Ubuntu, we have considered to use the existing kernel features before going off to use UKI. Here are some of the reasons why we didn't opt to use the kernel builtin things: 1) we wanted to have ability to have TPM measured kernel commandline performed before kernel is being executed, which is what sd-stub provides us 2) we wanted to have ability to update / regenerate initrd, without rebuilding kernel. Thus whenever userspace in the initrd needs updating, we can generate new initrd for existing kernel build, create new kernel.efi, whilst using existing .linux / vmlinuz build. I don't believe it is currently trivial to relink vmlinuz with builtin initrd. 3) licensing wise it was not clear if initrd has to be GPLv2 compatible when linked inside vmlinuz, or if it can contain GPLv3 / LGPLv3 userspace code - with UKI it is believed unambigiously true, because vmlinuz boots by itself standalone and is compiled separately of the UKI. 4) we wanted to have ability to override cmdline via kernel args without secureboot, and use stock cmdline args under secureboot, to allow debugging & production behaviour from a single signed kernel.efi (that was custom development, and could be done in the stock vmlinuz too). 5) obvious mention, the intention here is to have TPM PCR measurements and Secureboot signature for vmlinuz and initrd and cmdline and dtb. There is otherwise no support for standalone signed initrd, cmdline, dtb today. Nor does vendoring it into vmlinuz achieves this to the same extent (and ease of predicting for sealing / resealing purposes). 6) in Ubuntu kernel.efi also has sbat section for targeted revocations (discussed separately elsewhere) Overall, it is mostly about flexibility to be able to reuse the same initrd against multiple kernel builds, or update use multiple initrd against the same kernel build. This is imho the biggest issue with using initrd built-into the vmlinuz itself. Resource wise, the initrd passed in via kernel.efi can be freed, as far as I understand. I don't know if the one built-into the vmlinuz is freeable. Improving design to do something else instead of UKI would be welcomed. Or for example improving the zimg linus upstream format to be a partial or a valid UKI would help as well. For example, building the kernel built-in initrd as a .initrd section that is replacable would be nice, or allowing to preload zimg with .dtb or .cmdline sections would help, and appropriately improve the linux efi stab to do measurements and loading of .dtb / .initrd from itself would be nice. Because then all the benefits / requirements described above could be made available out of the box and be trivially updatable. The biggest one being splitting out things into sections that can be updated with objcopy. > BR, Jarkko
On Mon Sep 18, 2023 at 6:41 PM EEST, Dimitri John Ledkov wrote: > On Tue, 12 Sept 2023 at 11:38, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > On Tue Sep 12, 2023 at 2:20 AM EEST, Neal Gompa wrote: > On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > > > > > Hello, > > > > > > > > > > this patch implements UKI support for kexec_file_load. It will require support > > > > > in the kexec-tools userspace utility. For testing purposes the following can be used: > > > > > https://github.com/Cydox/kexec-test/ > > > > > > > > > > There has been discussion on this topic in an issue on GitHub that is linked below > > > > > for reference. > > > > > > > > > > > > > > > Some links: > > > > > - Related discussion: https://github.com/systemd/systemd/issues/28538 > > > > > - Documentation of UKIs: https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > > > > > > > Jan Hendrik Farr (1): > > > > > x86/kexec: UKI support > > > > > > > > > > arch/x86/include/asm/kexec-uki.h | 7 ++ > > > > > arch/x86/include/asm/parse_pefile.h | 32 +++++++ > > > > > arch/x86/kernel/Makefile | 2 + > > > > > arch/x86/kernel/kexec-uki.c | 113 +++++++++++++++++++++++++ > > > > > arch/x86/kernel/machine_kexec_64.c | 2 + > > > > > arch/x86/kernel/parse_pefile.c | 110 ++++++++++++++++++++++++ > > > > > crypto/asymmetric_keys/mscode_parser.c | 2 +- > > > > > crypto/asymmetric_keys/verify_pefile.c | 110 +++--------------------- > > > > > crypto/asymmetric_keys/verify_pefile.h | 16 ---- > > > > > 9 files changed, 278 insertions(+), 116 deletions(-) > > > > > create mode 100644 arch/x86/include/asm/kexec-uki.h > > > > > create mode 100644 arch/x86/include/asm/parse_pefile.h > > > > > create mode 100644 arch/x86/kernel/kexec-uki.c > > > > > create mode 100644 arch/x86/kernel/parse_pefile.c > > > > > > > > > > -- > > > > > 2.40.1 > > > > > > > > What the heck is UKI? > > > > > > Unified Kernel Images. More details available here: > > > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > > > It's a way of creating initramfs-style images as fully generic, > > > reproducible images that can be built server-side. > > > > You can build today a kernel with these compiled in: > > > > 1. EFI stub > > 2. initeramfs > > 3. cmdline > > > > Why another way (and label 'UKI') for a pre-existing feature? > > > > In Ubuntu, we have considered to use the existing kernel features > before going off to use UKI. Here are some of the reasons why we > didn't opt to use the kernel builtin things: > 1) we wanted to have ability to have TPM measured kernel commandline > performed before kernel is being executed, which is what sd-stub > provides us OK this does make a lot of sense. > 2) we wanted to have ability to update / regenerate initrd, without > rebuilding kernel. Thus whenever userspace in the initrd needs > updating, we can generate new initrd for existing kernel build, create > new kernel.efi, whilst using existing .linux / vmlinuz build. I don't > believe it is currently trivial to relink vmlinuz with builtin initrd. > 3) licensing wise it was not clear if initrd has to be GPLv2 > compatible when linked inside vmlinuz, or if it can contain GPLv3 / > LGPLv3 userspace code - with UKI it is believed unambigiously true, > because vmlinuz boots by itself standalone and is compiled separately > of the UKI. Right UKI wraps kernel and kernel is a "leaf object". > 4) we wanted to have ability to override cmdline via kernel args > without secureboot, and use stock cmdline args under secureboot, to > allow debugging & production behaviour from a single signed kernel.efi > (that was custom development, and could be done in the stock vmlinuz > too). > 5) obvious mention, the intention here is to have TPM PCR measurements > and Secureboot signature for vmlinuz and initrd and cmdline and dtb. > There is otherwise no support for standalone signed initrd, cmdline, > dtb today. Nor does vendoring it into vmlinuz achieves this to the > same extent (and ease of predicting for sealing / resealing purposes). ok > 6) in Ubuntu kernel.efi also has sbat section for targeted revocations > (discussed separately elsewhere) > > Overall, it is mostly about flexibility to be able to reuse the same > initrd against multiple kernel builds, or update use multiple initrd > against the same kernel build. This is imho the biggest issue with > using initrd built-into the vmlinuz itself. > Resource wise, the initrd passed in via kernel.efi can be freed, as > far as I understand. I don't know if the one built-into the vmlinuz is > freeable. > > Improving design to do something else instead of UKI would be > welcomed. Or for example improving the zimg linus upstream format to > be a partial or a valid UKI would help as well. For example, building > the kernel built-in initrd as a .initrd section that is replacable > would be nice, or allowing to preload zimg with .dtb or .cmdline > sections would help, and appropriately improve the linux efi stab to > do measurements and loading of .dtb / .initrd from itself would be > nice. Because then all the benefits / requirements described above > could be made available out of the box and be trivially updatable. The > biggest one being splitting out things into sections that can be > updated with objcopy. BR, Jarkko