On 25 08:55:46, Ard Biesheuvel wrote:
> On Mon, 25 Sept 2023 at 03:01, Pingfan Liu wrote:
>
> [...]
>
> > > 4. How can we debug the stubs that are being invoked?
> > > 5. Can we let the EFI binary know that this is a kexec and not a normal
> > > bootup. Potentially systemd-stub would want to
Hi Pingfan!
On 21 21:37:01, Pingfan Liu wrote:
> From: Pingfan Liu
>
> For security boot, the vmlinuz.efi will be signed so UEFI boot loader
> can check against it. But at present, there is no signature for kexec
> file load, this series makes a signature on the zboot's payload -- Image
>
Hi Ard, Greetings from Delft
On 20 10:50:31, Ard Biesheuvel wrote:
> On Wed, 20 Sept 2023 at 08:40, Dave Young wrote:
> >
> > On Wed, 20 Sept 2023 at 15:43, Dave Young wrote:
> > >
> > > > > In the end the only benefit this series brings is to extend the
> > > > > signature checking on the
On Thu, Sep 14, 2023, at 8:51 PM, Philipp Rudo wrote:
> [...]
>
> In this context I hope it is also clear to you that when more and more
> people rely on the spec you need a more formal process when including
> changes. Especially when the change might break the implementation of
> others. So no
> BTW, would not be a bad idea to extend CC list to at least Matthew and
> James Bottomley on this patch.
Sure. Added Matthew and James in CC
Also, I already made some minor changes. cmdline is now used from the syscall
if there is no .cmdline section included in the UKI. find_section now
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 ot
On Wed, Sep 13, 2023, at 4:00 PM, Philipp Rudo wrote:
> Hi Jan,
>
> All in all the code looks fine to me. Nevertheless I don't think UKI
> support should be added at the moment. This is because IMHO you
> basically reinterpret the kexec_file systemcall and thus add a new
> uapi to the kernel.
> 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
> 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? ;)
> By the way, could you provide detailed steps about how to test this
> patchset so that people interested can give it a shot?
Sure.
0. Build and run your kernel with my patches.
1. You're gonna need a UKI to kexec. I personally use sbctl or ukify to create
them.
sbctl command example (assumes
> 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
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 p
> 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
parses the UKI and passes the bzImage, initrd, and
cmdline to the normal bzImage loader.
Signed-off-by: Jan Hendrik Farr
---
arch/x86/include/asm/kexec-uki.h | 7 ++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/kexec-uki.c| 126 +
arch
- formatting tweaks
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 (2):
move pefile_parse_binary to its own file
x86/kexec: UKI support
arch/x86
Signed-off-by: Jan Hendrik Farr
---
crypto/asymmetric_keys/mscode_parser.c | 2 +-
crypto/asymmetric_keys/verify_pefile.c | 99 +-
crypto/asymmetric_keys/verify_pefile.h | 16
include/linux/parse_pefile.h | 32 +++
lib/Makefile
>> > - 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
>> >
> - 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
parses the UKI and passes the bzImage, initrd, and
cmdline to the normal bzImage loader.
Signed-off-by: Jan Hendrik Farr
---
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
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
20 matches
Mail list logo
