[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH5Ym4jK6dHOgO10WTPrHd6w6UK7gJH-95t1Da4NooF+ORB=oA@mail.gmail.com>
Date: Tue, 26 Aug 2025 12:33:59 -0700
From: Sam Edwards <cfsworks@...il.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>, Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, Anshuman Khandual <anshuman.khandual@....com>,
Ryan Roberts <ryan.roberts@....com>, Baruch Siach <baruch@...s.co.il>,
Kevin Brodsky <kevin.brodsky@....com>, Joey Gouly <joey.gouly@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH] arm64/boot: Zero-initialize idmap PGDs before use
On Tue, Aug 26, 2025 at 3:18 AM Ard Biesheuvel <ardb@...nel.org> wrote:
> Indeed. And actually, it should still be the ELF loader's job to
> zero-initialize NOBITS sections, so ideally, we'd make these NOBITS
> rather than PROGBITS, and the bloat issue should go away.
I completely agree. NOBITS seems like the best approach:
- It doesn't meaningfully increase the size of vmlinux
- It has no runtime cost (and indeed shouldn't change the binary image at all)
- Yet it still memorializes in ELF our expectation that these tables
are pre-zeroed (and addresses some of my other "what ifs" like "What
if the user wants to use objcopy --gap-fill?")
> If the ELF loader in question relies on the executable's startup code
> to clear NOBITS sections, it needs to be fixed in any case. Clearing
> BSS like we do at startup time is really only appropriate for
> bare-metal images such as arm64's Image, but a platform that elects to
> use an ELF loader instead (even though that is not a supported
> bootable format for arm64 Linux) should at least adhere to the ELF
> spec.
Here's hoping -- I'm afraid I can't substantially change anything
about this bootloader, so I've been looking to replace it instead. But
we are in agreement that if the ELF loader isn't following the spec
and NOBITS doesn't solve my problem, then interim workarounds are
solely my responsibility.
Best,
Sam
Powered by blists - more mailing lists