linux-kernel - [PATCH RFC v1 02/11] x86/fpu/xstate: Introduce xstate order table and accessor macro

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: <20250227184502.10288-3-chang.seok.bae@intel.com>
Date: Thu, 27 Feb 2025 10:44:47 -0800
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: linux-kernel@...r.kernel.org
Cc: x86@...nel.org,
	tglx@...utronix.de,
	mingo@...hat.com,
	bp@...en8.de,
	dave.hansen@...ux.intel.com,
	chang.seok.bae@...el.com
Subject: [PATCH RFC v1 02/11] x86/fpu/xstate: Introduce xstate order table and accessor macro

The kernel has largely assumed that higher xstate component numbers
correspond to later offsets in the buffer. However, this assumption does
not hold for the non-compacted format, where a newer state component may
have a lower offset.

When iterating over xstate components in offset order, using the feature
number as an index may be misleading. At the same time, the CPU exposes
each component’s size and offset based on its feature number, making it a
key for state information.

To provide flexibility in handling xstate ordering, add a mapping table:
feature order -> feature number. This new array stores feature numbers in
offset order, accompanied by an accessor macro.

The macro enables sequential traversal of xstate components based on
their actual buffer positions, given a feature bitmask. This will be
particularly useful for computing customized non-compacted format sizes
and sequentially accessing xstate offsets over non-compacted buffers.

Suggested-by: Dave Hansen <dave.hansen@...ux.intel.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@...el.com>
---
This lays the groundwork for handling APX, which has feature number 19
but appears immediately after FEATURE_YMM, occupying the space previously
reserved for the now-deprecated MPX state.
---
 arch/x86/kernel/fpu/xstate.c | 37 ++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 6a41d1610d8b..cee9a1e454b7 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -91,6 +91,43 @@ static unsigned int xstate_flags[XFEATURE_MAX] __ro_after_init;
 #define XSTATE_FLAG_SUPERVISOR	BIT(0)
 #define XSTATE_FLAG_ALIGNED64	BIT(1)
 
+/*
+ * Ordering of xstate components in non-compacted format:  The xfeature
+ * number does not necessarily indicate its position in the XSAVE buffer.
+ * This array defines the traversal order of xstate features, included in
+ * XFEATURE_MASK_USER_SUPPORTED.
+ */
+static const enum xfeature xfeature_noncompact_order[] = {
+	XFEATURE_FP,
+	XFEATURE_SSE,
+	XFEATURE_YMM,
+	XFEATURE_BNDREGS,
+	XFEATURE_BNDCSR,
+	XFEATURE_OPMASK,
+	XFEATURE_ZMM_Hi256,
+	XFEATURE_Hi16_ZMM,
+	XFEATURE_PKRU,
+	XFEATURE_XTILE_CFG,
+	XFEATURE_XTILE_DATA,
+};
+
+static inline unsigned int next_xfeature_order(unsigned int i, u64 mask)
+{
+	for (; i < ARRAY_SIZE(xfeature_noncompact_order); i++) {
+		if (mask & BIT_ULL(xfeature_noncompact_order[i]))
+			break;
+	}
+
+	return i;
+}
+
+/* Iterate xstate features in non-compacted order */
+#define for_each_extended_xfeature_in_order(i, mask)		\
+	for (i = XFEATURE_YMM;					\
+	     i = next_xfeature_order(i, mask),			\
+	     i < ARRAY_SIZE(xfeature_noncompact_order);	\
+	     i++)
+
 /*
  * Return whether the system supports a given xfeature.
  *
-- 
2.45.2