linux-kernel - Re: [RFC RESEND] binfmt_elf: preserve original ELF e

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: <202508071414.5A5AB6B2@keescook>
Date: Thu, 7 Aug 2025 14:14:46 -0700
From: Kees Cook <kees@...nel.org>
To: Svetlana Parfenova <svetlana.parfenova@...tacore.com>
Cc: linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	brauner@...nel.org, jack@...e.cz, akpm@...ux-foundation.org,
	david@...hat.com, lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org,
	surenb@...gle.com, mhocko@...e.com
Subject: Re: [RFC RESEND] binfmt_elf: preserve original ELF e_flags in core
 dumps

On Thu, Aug 07, 2025 at 07:13:50PM +0600, Svetlana Parfenova wrote:
> On 07/08/2025 00.57, Kees Cook wrote:
> > On Wed, Aug 06, 2025 at 10:18:14PM +0600, Svetlana Parfenova wrote:
> > > Preserve the original ELF e_flags from the executable in the core dump
> > > header instead of relying on compile-time defaults (ELF_CORE_EFLAGS or
> > > value from the regset view). This ensures that ABI-specific flags in
> > > the dump file match the actual binary being executed.
> > > 
> > > Save the e_flags field during ELF binary loading (in load_elf_binary())
> > > into the mm_struct, and later retrieve it during core dump generation
> > > (in fill_note_info()). Use this saved value to populate the e_flags in
> > > the core dump ELF header.
> > > 
> > > Add a new Kconfig option, CONFIG_CORE_DUMP_USE_PROCESS_EFLAGS, to guard
> > > this behavior. Although motivated by a RISC-V use case, the mechanism is
> > > generic and can be applied to all architectures.
> > 
> > In the general case, is e_flags mismatched? i.e. why hide this behind a
> > Kconfig? Put another way, if I enabled this Kconfig and dumped core from
> > some regular x86_64 process, will e_flags be different?
> > 
> 
> The Kconfig option is currently restricted to the RISC-V architecture
> because it's not clear to me whether other architectures need actual e_flags
> value from ELF header. If this option is disabled, the core dump will always
> use a compile time value for e_flags, regardless of which method is
> selected: ELF_CORE_EFLAGS or CORE_DUMP_USE_REGSET. And this constant does
> not necessarily reflect the actual e_flags of the running process (at least
> on RISC-V), which can vary depending on how the binary was compiled. Thus, I
> made a third method to obtain e_flags that reflects the real value. And it
> is gated behind a Kconfig option, as not all users may need it.

Can you check if the ELF e_flags and the hard-coded e_flags actually
differ on other architectures? I'd rather avoid using the Kconfig so we
can have a common execution path for all architectures.

-- 
Kees Cook