linux-kernel - Re: [PATCH v2 0/2] ARM: decompressor: support AUTO

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: <aYNAAsD6dlMi-35Q@shell.armlinux.org.uk>
Date: Wed, 4 Feb 2026 12:48:02 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Linus Walleij <linusw@...nel.org>, Marc Zyngier <maz@...nel.org>,
	"Christian Marangi (Ansuel)" <ansuelsmth@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jonathan Corbet <corbet@....net>,
	"Mike Rapoport (IBM)" <rppt@...nel.org>,
	Eric DeVolder <eric.devolder@...cle.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Kees Cook <keescook@...omium.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...ainline.org>,
	John Crispin <john@...ozen.org>
Subject: Re: [PATCH v2 0/2] ARM: decompressor: support AUTO_ZRELADDR and
 appended DTB

On Wed, Feb 04, 2026 at 11:54:59AM +0000, Russell King (Oracle) wrote:
> On Wed, Feb 04, 2026 at 11:53:30AM +0100, Geert Uytterhoeven wrote:
> > Hi Russell,
> > 
> > On Wed, 4 Feb 2026 at 02:27, Russell King (Oracle)
> > <linux@...linux.org.uk> wrote:
> > > On Wed, Feb 04, 2026 at 01:36:29AM +0100, Linus Walleij wrote:
> > > > However, I think it is a thick requirement to put on hobbyist
> > > > contributors to go and write entite boot loaders from scratch,
> > > > I think it's a fine requirement to put on Qualcomm or Renesas
> > > > paid maintainers.
> > >
> > > If we're talking about older boards, then why have they only recently
> > > became a problem, when, presumably, they've been working fine for a
> > > decade or so?
> > 
> > These boards may have been working fine, given the right "legacy"
> > kernel config options were used.  However, some of these option make
> > the resulting kernel limited to that platform or even to a specific
> > board (e.g. when CONFIG_CMDLINE needs to be used).
> 
> The 32-git ARM kernel has had a way to pass the command line to the
> kernel from the boot loader since day one.
> 
> 	First it was the struct param_struct.
> 	Then it was the ATAGs that was introduced pre-git.
> 	Now it is DT.
> 
> The kernel retains code to parse all three methods of passing data
> from the boot loader to the kernel. The decompressor has support
> for merging the ATAGs into the appended DTB, which includes merging
> the command line into the DTB.
> 
> Without an appended DTB, the pointer to one of the above will be
> passed to the kernel, the kernel will figure out what it has and
> parse one of the three ways, and use the command line there.
> 
> The only case where CONFIG_CMDLINE should be used is when there is
> no command line passed, no way to change it, etc. At that point
> there are two options:
> 
> 1. Augment the kernel's generated FDT with the command line node
>    and load that modified FDT or append it to the compressed image.
> 
> 2. Use CONFIG_CMDLINE, which means that the kernel _will_ become
>    specific to the platform that needs those arguments. No getting
>    away from that in this case.
> 
> Maybe you haven't explained the problem very well, but I don't see
> any issue with this.
> 
> > The KZM-A9-GT I "need" this for never had upstream U-Boot (I don't
> > think I ever had any U-Boot sources).  I can boot a shmobile_defconfig
> > multi-platform kernel[*] fine, iff the first patch is applied.
> 
> So, what have you been doing for the last 14 years to boot this
> platform (merged in 2012) without this patch?
> 
> Please explain:
> 
> - how it worked before - I want to know how the DTB is passed to the
>   kernel, what information is provided from the boot loader, whether
>   that gets merged into the DTB, etc. All the fine nitty gritty of
>   how it worked and what doesn't work, what the problems were etc.
> 
> - what changed (it sounds like you want extra features)
> 
> - why (in detail) it doesn't work now.

I want to know:

- Where RAM is located.
- Where the kernel is being loaded.
- Whether the platform reserves any RAM that may overlap with the kernel
  or where the kernel wants to locate itself in RAM.

>From what I can see from arch/arm/boot/dts/renesas/sh73a0-kzm9g.dts,
memory is at 0x4000000..0x5fffffff - 512MiB.

So, provided you load and execute the compressed kernel image within
the first 128Mi of memory (0x40000000 - 0x48000000), then it will select
0x40008000 to decompress itself. I can find no mention of any reserved
memory regions in the DT file, so this should be fine.

If you're loading the compressed kernel at some wildly different
address, then yes, it probably won't work.

This is documented in Documentation/arch/arm/booting.rst:

 The zImage may also be placed in system RAM and called there.  The
 kernel should be placed in the first 128MiB of RAM.  It is recommended
 that it is loaded above 32MiB in order to avoid the need to relocate
 prior to decompression, which will make the boot process slightly
 faster.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!