linux-kernel - Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 12 Feb 2021 08:38:44 -0600
From:   Rob Herring <robh@...nel.org>
To:     Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>
Cc:     Thiago Jung Bauermann <bauerman@...ux.ibm.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Will Deacon <will@...nel.org>, Joe Perches <joe@...ches.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Michael Ellerman <mpe@...erman.id.au>,
        James Morse <james.morse@....com>,
        Sasha Levin <sashal@...nel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Frank Rowand <frowand.list@...il.com>,
        vincenzo.frascino@....com, Mark Rutland <mark.rutland@....com>,
        dmitry.kasatkin@...il.com, James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Pavel Tatashin <pasha.tatashin@...een.com>,
        Allison Randal <allison@...utok.net>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Matthias Brugger <mbrugger@...e.com>,
        Hsin-Yi Wang <hsinyi@...omium.org>, tao.li@...o.com,
        Christophe Leroy <christophe.leroy@....fr>,
        Prakhar Srivastava <prsriva@...ux.microsoft.com>,
        balajib@...ux.microsoft.com, linux-integrity@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        devicetree@...r.kernel.org,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function

On Thu, Feb 11, 2021 at 7:17 PM Lakshmi Ramasubramanian
<nramas@...ux.microsoft.com> wrote:
>
> On 2/11/21 5:09 PM, Thiago Jung Bauermann wrote:
> >
> > There's actually a complication that I just noticed and needs to be
> > addressed. More below.
> >
>
> <...>
>
> >> +
> >> +/*
> >> + * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
> >> + *
> >> + * @image:          kexec image being loaded.
> >> + * @initrd_load_addr:       Address where the next initrd will be loaded.
> >> + * @initrd_len:             Size of the next initrd, or 0 if there will be none.
> >> + * @cmdline:                Command line for the next kernel, or NULL if there will
> >> + *                  be none.
> >> + *
> >> + * Return: fdt on success, or NULL errno on error.
> >> + */
> >> +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
> >> +                               unsigned long initrd_load_addr,
> >> +                               unsigned long initrd_len,
> >> +                               const char *cmdline)
> >> +{
> >> +    void *fdt;
> >> +    int ret, chosen_node;
> >> +    const void *prop;
> >> +    unsigned long fdt_size;
> >> +
> >> +    fdt_size = fdt_totalsize(initial_boot_params) +
> >> +               (cmdline ? strlen(cmdline) : 0) +
> >> +               FDT_EXTRA_SPACE;
> >
> > Just adding 4 KB to initial_boot_params won't be enough for crash
> > kernels on ppc64. The current powerpc code doubles the size of
> > initial_boot_params (which is normally larger than 4 KB) and even that
> > isn't enough. A patch was added to powerpc/next today which uses a more
> > precise (but arch-specific) formula:
> >
> > https://lore.kernel.org/linuxppc-dev/161243826811.119001.14083048209224609814.stgit@hbathini/
> >
> > So I believe we need a hook here where architectures can provide their
> > own specific calculation for the size of the fdt. Perhaps a weakly
> > defined function providing a default implementation which an
> > arch-specific file can override (a la arch_kexec_kernel_image_load())?
> >
> > Then the powerpc specific hook would be the kexec_fdt_totalsize_ppc64()
> > function from the patch I linked above.
> >
>
> Do you think it'd better to add "fdt_size" parameter to
> of_kexec_alloc_and_setup_fdt() so that the caller can provide the
> desired FDT buffer size?

Yes, I guess so. But please define the param as extra size, not total
size. The kernel command line size addition can be in the common code.

The above change is also going to conflict, so I think this may have
to wait. Or I'll take the common and arm bits and powerpc can be
converted next cycle (or after the merge window).

Rob