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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu, 14 Mar 2024 10:05:18 -0700
From: John Baldwin <jhb@...eBSD.org>
To: Dave Hansen <dave.hansen@...el.com>,
 Vignesh Balasubramanian <vigbalas@....com>, linux-kernel@...r.kernel.org,
 linux-toolchains@...r.kernel.org
Cc: 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, 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 8:37 AM, Dave Hansen wrote:
> On 3/14/24 04:23, Vignesh Balasubramanian wrote:
>> But this patch series depends on heuristics based on the total XSAVE
>> register set size and the XCR0 mask to infer the layouts of the
>> various register blocks for core dumps, and hence, is not a foolproof
>> mechanism to determine the layout of the XSAVE area.
> 
> It may not be theoretically foolproof.  But I'm struggling to think of a
> case where it would matter in practice.  Is there any CPU from any
> vendor where this is actually _needed_?
> 
> Sure, it's ugly as hell, but these notes aren't going to be available
> universally _ever_, so it's not like the crummy heuristic code gets to
> go away.

I forgot to mention one other use case for this note.

Today (and before my earlier patch series to add the ugly heuristic),
when the NT_X86_XSTATE core dump note grows because a CPU vendor adds
a new xfeature and OS's which just dump the entire XSAVE state start
including that, GDB fails to parse the entire note.

Having a note describing the layout (whichever format is chosen),
allows GDB to still pull registers for features it understands from
the larger note and ignoring the parts of the XSAVE block it doesn't
understand.

-- 
John Baldwin