On 3/14/2024 10:09 PM, Dave Hansen wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On 3/14/24 09:29, Borislav Petkov wrote:
That argument breaks down a bit on the flags though:
xc.xfeat_flags
IMHO you should split the changes to replace ARCH_HAVE_EXTRA_ELF_NOTES
with CONFIG_ARCH_HAVE_EXTRA_ELF_NOTES into a lead-up patch.
cheers
Thanks for the input and i will take care in next version.
regards,
vigneshbalu.
Otherwise looks reasonable, though I see Dave has feedback to address
too. :)
Thanks for working on this!
-Kees
Thank you for the review.
I will address all this on next version.
thanks,
vigneshbalu.
--
Kees Cook
On Sat, Mar 16, 2024 at 12:51:28AM +0100, Thomas Gleixner wrote:
> Anything which is not enumerated in CPUID does not exist in
> XSTATE. Period and end of story.
But why not have a simple buffer definition which doesn't need CPUID?
Also, doing the CPUID thing would need extending the gdb remote
On Thu, Mar 14 2024 at 17:29, Borislav Petkov wrote:
> On Thu, Mar 14, 2024 at 09:19:15AM -0700, Dave Hansen wrote:
>> Are you envisioning an *XSAVE* state component that's not described by
>> CPUID?
>
> I want to be prepared. You can imagine some of the short cuts and
> corners cutting hw guys
-files/20240314-192650
base: linus/master
patch link:
https://lore.kernel.org/r/20240314112359.50713-2-vigbalas%40amd.com
patch subject: [PATCH 1/1] x86/elf: Add a new .note section containing
Xfeatures information to x86 core files
config: x86_64-randconfig-122-20240315
(https://download.01
-files/20240314-192650
base: linus/master
patch link:
https://lore.kernel.org/r/20240314112359.50713-2-vigbalas%40amd.com
patch subject: [PATCH 1/1] x86/elf: Add a new .note section containing
Xfeatures information to x86 core files
config: i386-buildonly-randconfig-001-20240315
(https
On 3/14/24 10:10 AM, Dave Hansen wrote:
On 3/14/24 09:45, John Baldwin wrote:
On 3/14/24 8:37 AM, Dave Hansen wrote:
On 3/14/24 04:23, Vignesh Balasubramanian wrote:
Add a new .note section containing type, size, offset and flags of
every xfeature that is present.
Mechanically, I'd much
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
On 3/14/24 8:37 AM, Dave Hansen wrote:
On 3/14/24 04:23, Vignesh Balasubramanian wrote:
Add a new .note section containing type, size, offset and flags of
every xfeature that is present.
Mechanically, I'd much rather have all of that info in the cover letter
in the actual changelog instead.
Add a new .note section containing type, size, offset and flags of
every xfeature that is present.
This information will be used by the debuggers to understand the XSAVE
layout of the machine where the core file is dumped, and to read XSAVE
registers, especially during cross-platform debugging.
Hi Vignesh,
Vignesh Balasubramanian writes:
> Add a new .note section containing type, size, offset and flags of
> every xfeature that is present.
>
> This information will be used by the debuggers to understand the XSAVE
> layout of the machine where the core file is dumped, and to read XSAVE
>
On 3/14/24 09:45, John Baldwin wrote:
> On 3/14/24 8:37 AM, Dave Hansen wrote:
>> On 3/14/24 04:23, Vignesh Balasubramanian wrote:
>>> Add a new .note section containing type, size, offset and flags of
>>> every xfeature that is present.
>>
>> Mechanically, I'd much rather have all of that info in
On 3/14/24 09:29, Borislav Petkov wrote:
>
>> 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, , , , );
>> ...
>> xstate_flags[i] =
On Thu, Mar 14, 2024 at 09:19:15AM -0700, Dave Hansen wrote:
> Are you envisioning an *XSAVE* state component that's not described by
> CPUID?
I want to be prepared. You can imagine some of the short cuts and
corners cutting hw guys would do so I'd want to be prepared there and
not tie this to
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
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
On Thu, Mar 14, 2024 at 04:53:28PM +0530, Vignesh Balasubramanian wrote:
> Add a new .note section containing type, size, offset and flags of
> every xfeature that is present.
>
> This information will be used by the debuggers to understand the XSAVE
> layout of the machine where the core file is
On 3/14/24 04:23, Vignesh Balasubramanian wrote:
> Add a new .note section containing type, size, offset and flags of
> every xfeature that is present.
Mechanically, I'd much rather have all of that info in the cover letter
in the actual changelog instead.
I'd also love to see a practical
19 matches
Mail list logo
