linux-kernel - Re: [RFC PATCH 0/3] efi: Implement generic zboot support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Apr 2023 07:29:49 -0500
From:   Mario Limonciello <mario.limonciello@....com>
To:     Ard Biesheuvel <ardb@...nel.org>, Gerd Hoffmann <kraxel@...hat.com>
Cc:     linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Evgeniy Baskov <baskov@...ras.ru>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        Peter Jones <pjones@...hat.com>,
        Dave Young <dyoung@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC PATCH 0/3] efi: Implement generic zboot support


On 4/20/23 02:54, Ard Biesheuvel wrote:
> On Thu, 20 Apr 2023 at 08:07, Gerd Hoffmann <kraxel@...hat.com> wrote:
>>    Hi,
>>
>>>> Realistically, the second option is unlikely to ever be used on x86,
>>>>
>>>> What would be needed to do so?  Teach kexec-tools and grub2 parse and
>>>> load zboot kernels I guess?
>>> I already implemented this for mach-virt here, so we can load Fedora
>>> kernels without firmware:
>>>
>>> https://gitlab.com/qemu-project/qemu/-/commit/ff11422804cd03494cc98691eecd3909ea09ab6f
>>>
>>> On arm64, this is probably more straight-forward, as the bare metal
>>> image is already intended to be booted directly like that. However,
>>> the x86 uncompressed image requires surprisingly little from all the
>>> boot_params/setup_header cruft to actually boot, so perhaps there it
>>> is easy too.
>> For existing boot loaders like grub I'd expect it being easy
>> to code up, all the setup header code exists already, grub also
>> has support for uncompressing stuff, so it should really be only
>> zboot header parsing and some plumbing to get things going (i.e.
>> have grub boot efi zboot kernels in bios mode).
>>
>> Disclaimer: didn't actually check grub source code.
>>
> I have :-(
>
>> I suspect the bigger problem wrt. grub is that getting patches merged
>> upstream is extremely slow and every distro carries a huge stack of
>> patches ...
>>
> Yeah, Daniel has been asking me about LoadFile2 initrd loading support
> for x86, so I think getting things merged is not going to be a problem
> (although it will still take some time) - I can just implement it and
> send it out at the same time.
If zboot ends up being the way to go there would be quite a bit
of pressure to land the GRUB stuff in distros because of the NX
requirements being pushed into the EFI ecosystem.

They wouldn't be able to work on a system that enforces NX which
is anticipated to balloon.

>
> But hacking/building/running GRUB is a rather painful experience, so I
> have been kicking this can down the road.