linux-kernel - Re: [RFT PATCH v3 1/9] RISC-V: Move DT mapping outof fixmap

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:   Sat, 18 Jul 2020 11:24:39 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Atish Patra <atishp@...shpatra.org>
Cc:     Atish Patra <atish.patra@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Anup Patel <anup.patel@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Greentime Hu <greentime.hu@...ive.com>,
        Kees Cook <keescook@...omium.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Mark Rutland <mark.rutland@....com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Will Deacon <will@...nel.org>, Zong Li <zong.li@...ive.com>,
        Heinrich Schuchardt <xypron.glpk@....de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFT PATCH v3 1/9] RISC-V: Move DT mapping outof fixmap

On Sat, Jul 18, 2020 at 3:05 AM Atish Patra <atishp@...shpatra.org> wrote:
> On Thu, Jul 16, 2020 at 11:32 PM Arnd Bergmann <arnd@...db.de> wrote:
> > On Fri, Jul 17, 2020 at 1:41 AM Atish Patra <atish.patra@....com> wrote:
> > > +#define DTB_EARLY_SIZE         SZ_1M
> > > +static char early_dtb[DTB_EARLY_SIZE] __initdata;
> >
> > Hardcoding the size in .bss seems slightly problematic both for
> > small and for big systems. On machines with very little memory,
> > this can lead to running out of free pages before .initdata gets freed,
> > and it increases the size of the uncompressed vmlinux file by quite
> > a bit.
> >
> > On some systems, the 1MB limit may get too small. While most dtbs
> > would fall into the range between 10KB and 100KB, it can also be
> > much larger than that, e.g. when there are DT properties that include
> > blobs like device firmware that gets loaded into hardware by a kernel
> > driver.
> >
> I was not aware that we can do such things. Is there a current example of that ?

I worked on a product in the distant past where the host firmware
included the ethernet controller firmware as a DT property[1] to get around
restrictions on redistributing the blob in the linux-firmware package.

For the .dts files we distribute with the kernel, that would not make
sense, and I don't know of any current machines that do this in their
system firmware.

> > Is there anything stopping you from parsing the FDT in its original
> > location without the extra copy before it gets unflattened?
>
> That's what the original code was doing. A fixmap entry was added to
> map the original fdt
> location to a virtual so that parse_dtb can be operated on a virtual
> address. But we can't map
> both FDT & early ioremap within a single PMD region( 2MB ). That's why
> we removed the DT
> mapping from the fixmap to .bss section. The other alternate option is
> to increase the fixmap space to 4MB which seems more fragile.

Could the original location just be part of the regular linear mapping of all
RAM? I'm not too familiar with the early mapping code myself, so it may not
be possible, but that would be the most logical place where I'd put it.

        Arnd

[1] drivers/net/ethernet/toshiba/spider_net.c