linux-kernel - Re: [PATCH 1/1] x86 support for the initrd= command line option

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]

Message-ID: <CACdnJusmAHJYauKvHEXNZKaUWPqZoabB_pSn5WokSy_gOnRtTw@mail.gmail.com>
Date:   Fri, 20 Mar 2020 11:19:19 -0700
From:   Matthew Garrett <mjg59@...gle.com>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     ron minnich <rminnich@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "maintainer:X86 ARCHITECTURE..." <x86@...nel.org>,
        lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] x86 support for the initrd= command line option

On Thu, Mar 19, 2020 at 5:59 PM <hpa@...or.com> wrote:

> It has been designated consumed by the bootloader on x86 since at least 1995. So ARM broke it.

Eh. This feels like a matter of semantics - booting the kernel via EFI
results in it being parsed by the boot stub, so in that case we're
left arguing that the boot stub isn't the kernel. I can just about buy
that, but it's a stretch. For this change to actually break something,
we'd need the bootloader to be passing something that the kernel
parses, but not actually populating the initrd fields in bootparams.
That seems unlikely?