Date: Fri, 31 May 2024 14:49:40 +0530
From: "Balasubrmanian, Vignesh" <vigbalas@....com>
To: Borislav Petkov <bp@...en8.de>,
 "Balasubrmanian, Vignesh" <Vignesh.Balasubrmanian@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-toolchains@...r.kernel.org" <linux-toolchains@...r.kernel.org>,
 "mpe@...erman.id.au" <mpe@...erman.id.au>,
 "npiggin@...il.com" <npiggin@...il.com>,
 "christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
 "aneesh.kumar@...nel.org" <aneesh.kumar@...nel.org>,
 "naveen.n.rao@...ux.ibm.com" <naveen.n.rao@...ux.ibm.com>,
 "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
 "keescook@...omium.org" <keescook@...omium.org>,
 "x86@...nel.org" <x86@...nel.org>,
 "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 "George, Jini Susan" <JiniSusan.George@....com>, "matz@...e.de"
 <matz@...e.de>, "binutils@...rceware.org" <binutils@...rceware.org>,
 "jhb@...eBSD.org" <jhb@...ebsd.org>,
 "felix.willgerodt@...el.com" <felix.willgerodt@...el.com>
Subject: Re: [PATCH v2 1/1] x86/elf: Add a new .note section containing
 Xfeatures information to x86 core files


On 5/26/2024 2:35 PM, Borislav Petkov wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On Sun, May 26, 2024 at 10:24:41AM +0530, Balasubrmanian, Vignesh wrote:
>> If we can add a new enum only when we extend, then as Thomas suggested can
>> we use other kernel variables as in the first version of the patch until we
>> extend for other/new features?
> I assume by "other kernel variables" you mean CPUID?
>
> If so, can you change the layout of your buffer once you export it to
> userspace?
In a couple of the previous review mails
(https://lore.kernel.org/lkml/24f71d52-0891-4cfc-8dec-9f13ed618eee@intel.com/
and
https://lore.kernel.org/lkml/20240314162954.GAZfMmAnYQoRjRbRzc@fat_crate.local/),
it was suggested that the new .note should not use any internal definitions
like "xstate_sizes", "xstate_offsets" and ""xstate_flags" which are also the
direct output of cpuid instruction.

Also, the feature ID in .note records should be independent of the existing
XSAVE feature IDs (this was the comment as I understood). I defined the 
new enum
and mapping function to ensure that these remain independent of each other.

Thomas' comments on this version are that we should use existing variables
instead of re-evaluating cpuid. Also, to avoid the new enum and mapping
function which will make not any sense unless it is extended for
newer/different features.

That will be like our first version of the patch
https://lore.kernel.org/lkml/20240314112359.50713-2-vigbalas@amd.com/

So other than with the new enum (custom_feature) and the new mapping 
function
(get_sub_leaf), we are unsure as to how to maintain the layout to be
independent of x86' cpuid.

In the current version of the patch, the fields -- type, size, and offset
are derived from the cpuid instruction currently (and could be derived from
existing kernel variables in the future). The xsave flags are not used
currently, it can be zero(reserved) for now and its layout can be modified
(as per the need at that time) when the need arises.

If there are other ways to maintain the independence of the layout of a 
record
in .note section from the cpuid instruction other than depending on a 
new enum
and a new mapping function, we would be glad to follow it.

thanks
vigneshbalu
> --
> Regards/Gruss,
>      Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists