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: <CAK8P3a3e3SBtTocpkCybKRjkBJG26G-8YdiroJbZLZYq9f0yfw@mail.gmail.com>
Date:   Tue, 21 Jul 2020 10:57:24 +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 Tue, Jul 21, 2020 at 6:18 AM Atish Patra <atishp@...shpatra.org> wrote:
> On Sat, Jul 18, 2020 at 2:24 AM Arnd Bergmann <arnd@...db.de> wrote:
> > On Sat, Jul 18, 2020 at 3:05 AM Atish Patra <atishp@...shpatra.org> wrote:
> > > 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?
>
> No. Because we don't map the entire RAM until setup_vm_final().
> We need to parse DT before setup_vm_final() to get the memblocks and
> reserved memory regions.

Ok, I see how you create a direct mapping for the kernel image, plus
the fixmap for the dtb in setup_vm(), and how moving the dtb into the
kernel image simplifies that.

I'm still wondering why you can't do the same kind of PGD mapping
for the dtb that you do for the vmlinux, creating linear page table
entries exactly for the location that holds the dtb, from dtb_pa to
dtb_pa+((struct fdt_header*)dtb_pa)->totalsize.

      Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ