linux-kernel - Re: [PATCH] initrd: Remove erroneous comment

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: <CAP6exYJ64Hy9y3Dzh9Asrq8Y0oDWYk+tf4UAcasEc-ZxTY8DAw@mail.gmail.com>
Date:   Mon, 22 Jun 2020 13:02:16 -0700
From:   ron minnich <rminnich@...il.com>
To:     Tom Rini <trini@...sulko.com>
Cc:     lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Borislav Petkov <bp@...e.de>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        "H . Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] initrd: Remove erroneous comment

The other thing you ought to consider fixing:
initrd is documented as follows:

        initrd=         [BOOT] Specify the location of the initial ramdisk

for bootloaders only.

UEFI consumes initrd from the command line as well. As ARM servers
increasingly use UEFI, there may be situations in which the initrd
option doesn't make its way to the kernel? I don't know, UEFI is such
a black box to me. But I've seen this "initrd consumption" happen.

Based on docs, and the growing use of bootloaders that are happy to
consume initrd= and not pass it to the kernel, you might be better off
trying to move to the new command line option anyway.

IOW, this comment may not be what people want to see, but ... it might
also be right. Or possibly changed to:

/*
 * The initrd keyword is in use today on ARM, PowerPC, and MIPS.
 * It is also reserved for use by bootloaders such as UEFI and may
 * be consumed by them and not passed on to the kernel.
 * The documentation also shows it as reserved for bootloaders.
 * It is advised to move to the initrdmem= option whereever possible.
 */

On Fri, Jun 19, 2020 at 7:31 AM Tom Rini <trini@...sulko.com> wrote:
>
> Most architectures have been passing the location of an initrd via the
> initrd= option since their inception.  Remove the comment as it's both
> wrong and unrelated to the commit that introduced it.
>
> Fixes: 694cfd87b0c8 ("x86/setup: Add an initrdmem= option to specify initrd physical address")
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Borislav Petkov <bp@...e.de>
> Cc: Dominik Brodowski <linux@...inikbrodowski.net>
> Cc: H. Peter Anvin (Intel) <hpa@...or.com>
> Cc: Ronald G. Minnich <rminnich@...il.com>
> Signed-off-by: Tom Rini <trini@...sulko.com>
> ---
> For a bit more context, I assume there's been some confusion between
> "initrd" being a keyword in things like extlinux.conf and also that for
> quite a long time now initrd information is passed via device tree and
> not the command line on relevant architectures.  But it's still true
> that it's been a valid command line option to the kernel since the 90s.
> It's just the case that in 2018 the code was consolidated from under
> arch/ and in to this file.
> ---
>  init/do_mounts_initrd.c | 5 -----
>  1 file changed, 5 deletions(-)
>
> diff --git a/init/do_mounts_initrd.c b/init/do_mounts_initrd.c
> index d72beda824aa..53314d7da4be 100644
> --- a/init/do_mounts_initrd.c
> +++ b/init/do_mounts_initrd.c
> @@ -45,11 +45,6 @@ static int __init early_initrdmem(char *p)
>  }
>  early_param("initrdmem", early_initrdmem);
>
> -/*
> - * This is here as the initrd keyword has been in use since 11/2018
> - * on ARM, PowerPC, and MIPS.
> - * It should not be; it is reserved for bootloaders.
> - */
>  static int __init early_initrd(char *p)
>  {
>         return early_initrdmem(p);
> --
> 2.17.1
>