All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: linux-kernel@vger.kernel.org
Cc: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, dave.hansen@intel.com,
	hpa@zytor.com, linux-kselftest@vger.kernel.org,
	mizhang@google.com, chang.seok.bae@intel.com
Subject: [PATCH 1/2] x86/fpu/xstate: Prevent false-positive warning in __copy_xstate_uabi_buf()
Date: Mon, 27 Feb 2023 13:05:03 -0800	[thread overview]
Message-ID: <20230227210504.18520-2-chang.seok.bae@intel.com> (raw)
In-Reply-To: <20230227210504.18520-1-chang.seok.bae@intel.com>

__copy_xstate_to_uabi_buf() copies either from the tasks XSAVE buffer
or from init_fpstate into the ptrace buffer. Dynamic features, like
XTILEDATA, have an all zeroes init state and are not saved in
init_fpstate, which means the corresponding bit is not set in the
xfeatures bitmap of the init_fpstate header.

But __copy_xstate_to_uabi_buf() retrieves addresses for both the tasks
xstate and init_fpstate unconditionally via __raw_xsave_addr().

So if the tasks XSAVE buffer has a dynamic feature set, then the
address retrieval for init_fpstate triggers the warning in
__raw_xsave_addr() which checks the feature bit in the init_fpstate
header.

Remove the address retrieval from init_fpstate for extended features.
They have an all zeroes init state so init_fpstate has zeros for them.
Then zeroing the user buffer for the init state is the same as copying
them from init_fpstate.

Fixes: 2308ee57d93d ("x86/fpu/amx: Enable the AMX feature in 64-bit mode")
Reported-by: Mingwei Zhang <mizhang@google.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Tested-by: Mingwei Zhang <mizhang@google.com>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/kvm/20230221163655.920289-2-mizhang@google.com/
---
Thanks, Mingwei for detecting the issue and Thomas for explaining the
problem with the well-written description. The background and problem
sections in this changelog came from his write-up.

I acknowledge that Mingwei's patch (in the link above) can solve the
problem. But, I would rather propose this approach as it simplifies
the code which is considered good in this sensitive copy function.

This mostly zeroed init_fpstate is still useful, e.g., when copying
the init state between buffers with the same format -- like in
fpu_clone(). But, this case between different XSAVE formats looks a
bit different than that.
---
 arch/x86/kernel/fpu/xstate.c | 30 ++++++++++++++----------------
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 714166cc25f2..0bab497c9436 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1118,21 +1118,20 @@ void __copy_xstate_to_uabi_buf(struct membuf to, struct fpstate *fpstate,
 	zerofrom = offsetof(struct xregs_state, extended_state_area);
 
 	/*
-	 * The ptrace buffer is in non-compacted XSAVE format.  In
-	 * non-compacted format disabled features still occupy state space,
-	 * but there is no state to copy from in the compacted
-	 * init_fpstate. The gap tracking will zero these states.
-	 */
-	mask = fpstate->user_xfeatures;
-
-	/*
-	 * Dynamic features are not present in init_fpstate. When they are
-	 * in an all zeros init state, remove those from 'mask' to zero
-	 * those features in the user buffer instead of retrieving them
-	 * from init_fpstate.
+	 * This 'mask' indicates which states to copy from fpstate.
+	 * Those extended states that are not present in fpstate are
+	 * either disabled or initialized:
+	 *
+	 * In non-compacted format, disabled features still occupy
+	 * state space but there is no state to copy from in the
+	 * compacted init_fpstate. The gap tracking will zero these
+	 * states.
+	 *
+	 * The extended features have an all zeroes init state. Thus,
+	 * remove them from 'mask' to zero those features in the user
+	 * buffer instead of retrieving them from init_fpstate.
 	 */
-	if (fpu_state_size_dynamic())
-		mask &= (header.xfeatures | xinit->header.xcomp_bv);
+	mask = header.xfeatures;
 
 	for_each_extended_xfeature(i, mask) {
 		/*
@@ -1151,9 +1150,8 @@ void __copy_xstate_to_uabi_buf(struct membuf to, struct fpstate *fpstate,
 			pkru.pkru = pkru_val;
 			membuf_write(&to, &pkru, sizeof(pkru));
 		} else {
-			copy_feature(header.xfeatures & BIT_ULL(i), &to,
+			membuf_write(&to,
 				     __raw_xsave_addr(xsave, i),
-				     __raw_xsave_addr(xinit, i),
 				     xstate_sizes[i]);
 		}
 		/*
-- 
2.17.1


  reply	other threads:[~2023-02-27 21:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24 19:12 [PATCH 0/3] x86/fpu: Improve the init_fpstate setup code Chang S. Bae
2022-08-24 19:12 ` [PATCH 1/3] x86/fpu: Configure init_fpstate attributes orderly Chang S. Bae
2022-10-03 21:18   ` Neel Natu
2022-10-17 13:47   ` [tip: x86/urgent] " tip-bot2 for Chang S. Bae
2022-08-24 19:12 ` [PATCH 2/3] x86/fpu: Fix the init_fpstate size check with the actual size Chang S. Bae
2022-10-17 13:47   ` [tip: x86/urgent] " tip-bot2 for Chang S. Bae
2022-08-24 19:12 ` [PATCH 3/3] x86/fpu: Exclude dynamic states from init_fpstate Chang S. Bae
2022-10-17 13:47   ` [tip: x86/urgent] " tip-bot2 for Chang S. Bae
2022-10-18 22:13 ` [PATCH 0/1] x86/fpu: Follow up on the init_fpstate fix Chang S. Bae
2022-10-18 22:13   ` [PATCH 1/1] x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly Chang S. Bae
2022-10-20 16:57     ` Dave Hansen
2022-10-20 18:52       ` Chang S. Bae
2022-10-21 18:58     ` [PATCH v2] " Chang S. Bae
2022-10-21 22:25       ` [tip: x86/urgent] " tip-bot2 for Chang S. Bae
2022-10-22  6:23         ` Ingo Molnar
2022-10-22 13:02           ` Chang S. Bae
2023-02-27 21:05   ` [PATCH 0/2] x86/fpu/xstate: Follow up on the init_fpstate fallout again Chang S. Bae
2023-02-27 21:05     ` Chang S. Bae [this message]
2023-02-27 21:05     ` [PATCH 2/2] selftests/x86/amx: Add a ptrace test Chang S. Bae

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230227210504.18520-2-chang.seok.bae@intel.com \
    --to=chang.seok.bae@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mizhang@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.