Message-ID: <2c196c3f-4d49-494c-898e-8a1f6249ce24@syntacore.com>
Date: Fri, 8 Aug 2025 21:54:30 +0600
From: Svetlana Parfenova <svetlana.parfenova@...tacore.com>
To: Kees Cook <kees@...nel.org>
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 08/08/2025 03.14, Kees Cook wrote:
> 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.
> 

I checked various architectures, and most don’t use e_flags in core
dumps - just zero value. For x86 this is valid since it doesn’t define
values for e_flags. However, architectures like ARM do have meaningful
e_flags, yet still they are set to zero in core dumps. I guess the real
question isn't about core dump correctness, but whether tools like GDB
actually rely on e_flags to provide debug information. Seems like most
architectures either don’t use it or can operate without it. RISC-V
looks like black sheep here ... GDB relies on e_flags to determine the
ABI and interpret the core dump correctly.

What if I rework my patch the following way:
- remove Kconfig option;
- add function/macro that would override e_flags with value taken from
process, but it would only be applied if architecture specifies that.

Would that be a better approach?

-- 
Best regards,
Svetlana Parfenova

Powered by blists - more mailing lists