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:   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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ