linux-kernel - Re: [PATCH 2/3] riscv: Remove non-standard linux,elfcorehdr handling

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] [day] [month] [year] [list]

Message-ID: <008ddfd79d256dcddd7c802e4eef6b5a@mailhost.ics.forth.gr>
Date:   Fri, 02 Jul 2021 18:56:55 +0300
From:   Nick Kossifidis <mick@....forth.gr>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     robh+dt@...nel.org, mick@....forth.gr, geert@...ux-m68k.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, frowand.list@...il.com,
        catalin.marinas@....com, will@...nel.org,
        devicetree@...r.kernel.org, linux-riscv@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] riscv: Remove non-standard linux,elfcorehdr handling

Στις 2021-07-01 05:52, Palmer Dabbelt έγραψε:
> On Wed, 16 Jun 2021 07:47:46 PDT (-0700), robh+dt@...nel.org wrote:
>> On Wed, Jun 16, 2021 at 4:43 AM Nick Kossifidis <mick@....forth.gr> 
>> wrote:
>>> 
>>> Στις 2021-06-16 10:56, Geert Uytterhoeven έγραψε:
>>> >
>>> > I can't comment on the duplication on arm64, but to me, /chosen
>>> > sounds like the natural place for both "linux,elfcorehdr" and
>>> > "linux,usable-memory-range".  First rule of DT is "DT describes
>>> > hardware, not software policy", with /chosen describing some software
>>> > configuration.
>>> >
>>> 
>>> We already have "linux,usable-memory" on /memory node:
>>> https://elixir.bootlin.com/linux/v5.13-rc6/source/drivers/of/fdt.c#L1011
>>> and it makes perfect sense to be there since it overrides /memory's 
>>> reg
>>> property.
>>> 
>>> Why define another binding for the same thing on /chosen ?
>> 
>> Go look at the thread adding "linux,usable-memory-range". There were
>> only 35 versions of it[1]. I wasn't happy with a 2nd way either, but
>> as I've mentioned before we don't always have /memory node.
> 
> I don't really understand what's going on here, but IIUC what I merged
> in 5.13 doesn't match the behavior that other architectures have.  In
> that case I'm happy moving RISC-V over to the more standard way of
> doing things and just calling what we have in 5.13 a screwup.
> 
> Sorry for the confusion.

Long story short:

a) We use "linux,usable-memory" on /memory node to limit the memory of 
the kdump kernel, it's a standard binding defined at:
https://elixir.bootlin.com/linux/v5.13-rc6/source/drivers/of/fdt.c#L1011

b) We used a reserved region (again a standard binding) named 
"linux,elfcorehdr" which has the same name as a property on /chosen used 
by arm64 for the same thing. With this patch we 'll use arm64's 
approach, although it's a bit worse since we'll need to add the same 
region twice on the fdt (once in /chosen as a property and another one 
in the reservation map so that it gets reserved during early boot).

Fortunately I (still) haven't posted the kexec-tools patches on the 
mailing list so we don't break userspace by doing this.