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, 7 Nov 2019 12:31:34 +0100
From:   Daniel Kiper <daniel.kiper@...cle.com>
To:     hpa@...or.com
Cc:     Borislav Petkov <bp@...en8.de>, linux-efi@...r.kernel.org,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        xen-devel@...ts.xenproject.org, ard.biesheuvel@...aro.org,
        boris.ostrovsky@...cle.com, corbet@....net,
        dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
        eric.snowberg@...cle.com, jgross@...e.com,
        kanth.ghatraju@...cle.com, konrad.wilk@...cle.com,
        mingo@...hat.com, rdunlap@...radead.org, ross.philipson@...cle.com,
        tglx@...utronix.de
Subject: Re: [PATCH v5 0/3] x86/boot: Introduce the kernel_info et consortes

On Wed, Nov 06, 2019 at 09:56:48AM -0800, hpa@...or.com wrote:
> On November 6, 2019 9:03:33 AM PST, Borislav Petkov <bp@...en8.de> wrote:
> >On Mon, Nov 04, 2019 at 04:13:51PM +0100, Daniel Kiper wrote:
> >> Hi,
> >>
> >> Due to very limited space in the setup_header this patch series introduces new
> >> kernel_info struct which will be used to convey information from the kernel to
> >> the bootloader. This way the boot protocol can be extended regardless of the
> >> setup_header limitations. Additionally, the patch series introduces some
> >> convenience features like the setup_indirect struct and the
> >> kernel_info.setup_type_max field.
> >
> >That's all fine and dandy but I'm missing an example about what that'll
> >be used for, in practice.
> >
> >Thx.
>
> For one thing, we already have people asking for more than 4 GiB worth
> of initramfs, and especially with initramfs that huge it would make a
> *lot* of sense to allow loading it in chunks without having to
> concatenate them. I have been asking for a long time for initramfs
> creators to split the kernel-dependent and kernel independent parts
> into separate initramfs modules.

Another user of this patchset is the TrenchBoot project on which we are
working on. We have to introduce separate entry point for Intel TXT MLE
startup code. That is why we need the kernel_info struct.

Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ