linux-kernel - Re: [PATCH 1/1] x86/elf: Add a new .note section containing Xfeatures information to x86 core files

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 14 Mar 2024 09:19:15 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Vignesh Balasubramanian <vigbalas@....com>, linux-kernel@...r.kernel.org,
 linux-toolchains@...r.kernel.org, mpe@...erman.id.au, npiggin@...il.com,
 christophe.leroy@...roup.eu, aneesh.kumar@...nel.org,
 naveen.n.rao@...ux.ibm.com, ebiederm@...ssion.com, keescook@...omium.org,
 x86@...nel.org, linuxppc-dev@...ts.ozlabs.org, linux-mm@...ck.org,
 bpetkov@....com, jinisusan.george@....com, matz@...e.de,
 binutils@...rceware.org, jhb@...ebsd.org, felix.willgerodt@...el.com
Subject: Re: [PATCH 1/1] x86/elf: Add a new .note section containing Xfeatures
 information to x86 core files

On 3/14/24 09:08, Borislav Petkov wrote:
> On Thu, Mar 14, 2024 at 08:37:09AM -0700, Dave Hansen wrote:
>> This is pretty close to just a raw dump of the XSAVE CPUID leaves.
>> Rather than come up with an XSAVE-specific ABI that depends on CPUID
>> *ANYWAY* (because it dumps the "flags" register aka. ECX), maybe we
>> should just bite the bullet and dump out (some of) the raw CPUID space.
> 
> Funny you should say that. This was what they had done originally but if
> you dump CPUID and you want to add another component in the future which
> is *not* described by CPUID, your scheme breaks.

Are you envisioning an *XSAVE* state component that's not described by
CPUID?

Or some _other_ (non-XSAVE) component in a core dump that isn't
described by CPUID?

> So the idea is to have a self-describing buffers layout, independent
> from any x86-ism. You can extend this in a straight-forward way then
> later.

That argument breaks down a bit on the flags though:

	xc.xfeat_flags = xstate_flags[i];

Because it comes _directly_ from CPUID with zero filtering:

	cpuid_count(XSTATE_CPUID, i, &eax, &ebx, &ecx, &edx);
	...
	xstate_flags[i] = ecx;

So this layout is quite dependent on what's in x86's CPUID.