linux-kernel - Re: [PATCH -fixes] riscv: Fix BUILTIN

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: <mhng-f1a76f5f-ad66-40ae-aad3-cd2f669f33bf@palmerdabbelt-glaptop>
Date:   Fri, 04 Jun 2021 08:51:08 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     alex@...ti.fr, robh+dt@...nel.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        aou@...s.berkeley.edu, devicetree@...r.kernel.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject:     Re: [PATCH -fixes] riscv: Fix BUILTIN_DTB for sifive and microchip soc

On Fri, 04 Jun 2021 06:08:05 PDT (-0700), Arnd Bergmann wrote:
> On Fri, Jun 4, 2021 at 2:06 PM Alexandre Ghiti <alex@...ti.fr> wrote:
>>
>> Fix BUILTIN_DTB config which resulted in a dtb that was actually not built
>> into the Linux image: in the same manner as Canaan soc does, create an object
>> file from the dtb file that will get linked into the Linux image.
>>
>> Signed-off-by: Alexandre Ghiti <alex@...ti.fr>
>
> Along the same lines as the comment that Jisheng Zhang made on the fixed
> address, building a dtb into the kernel itself fundamentally breaks generic
> kernel images.
>
> I can understand using it on K210, which is extremely limited and wouldn't
> run a generic kernel anyway, but for normal platforms like microchip and
> sifive, it would be better to disallow CONFIG_BUILTIN_DTB in Kconfig
> and require a non-broken boot loader.

When we first added BUILTIN_DTB we actually had a compatibility 
mechanism in there.  There isn't enough in the ISA to handle board 
compatibility, but we were hoping to get something to deal with that.  
It didn't pan out so we dropped the compatibility mechanism, which is 
how we ended up here.

Maybe the right thing to do here is to add some sort of "be compatible 
with the platform spec" Kconfig, which we could then use to disallow all 
these features that result in non-portable kernels?