linux-kernel - Re: [PATCH RFC v1 06/11] x86/fpu/mpx: Remove MPX xstate component support

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]

Message-ID: <9985fe50-3ea5-411c-846a-dba3fe1fa451@intel.com>
Date: Thu, 20 Mar 2025 16:47:02 -0700
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Ingo Molnar <mingo@...nel.org>
CC: <linux-kernel@...r.kernel.org>, <x86@...nel.org>, <tglx@...utronix.de>,
	<mingo@...hat.com>, <bp@...en8.de>, <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH RFC v1 06/11] x86/fpu/mpx: Remove MPX xstate component
 support

On 2/27/2025 7:12 PM, Chang S. Bae wrote:
> On 2/27/2025 11:12 AM, Ingo Molnar wrote:
>>
>> So can this patch be moved further up in the series (without breaking
>> anything), to make it easier to review the impact of the APX changes?
> 
> Will do it.

If the xfeature_noncompact_order[] table is dynamically populated at 
boot time, the kernel should be able to maintain the order list flexibly 
enough without dropping MPX bits.

So, I posted V2 [1] with this patch removed -- after observing MPX being 
exposed to a KVM guest when running this version on an Skylake machine 
and confirming that APX support passed self-tests on an APX-emulated system.

I also considered handling MPX removal up to the KVM code in a separate 
series, which would eliminate about 220 lines. However, given previous 
discussions like [2], posting that cleanup now might appear to disregard 
those concerns. Perhaps it’s something to revisit in five years or more.

In the meantime, kernel memory usage could be improved by treating MPX 
as VCPU-only, aligning with the ongoing supervisor CET state handling 
work [3].

Thanks,
Chang

[1] 
https://lore.kernel.org/lkml/20250320234301.8342-1-chang.seok.bae@intel.com/
[2] 
https://lore.kernel.org/lkml/CALMp9eTD+GeiKK9E5_JUOy7YXPTq9z2f2LcyXZL5ypQ6vBHrHg@mail.gmail.com/
[3] 
https://lore.kernel.org/lkml/20250318153316.1970147-1-chao.gao@intel.com/