From: Thomas Gleixner <tglx@linutronix.de>
To: Kyle Huey <me@kylehuey.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Borislav Petkov <bp@alien8.de>
Cc: Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
Robert O'Callahan <robert@ocallahan.org>,
David Manouchehri <david.manouchehri@riseup.net>,
Kyle Huey <me@kylehuey.com>, Borislav Petkov <bp@suse.de>,
kvm@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v5 1/2] x86/fpu: Allow PKRU to be (once again) written by ptrace.
Date: Thu, 18 Aug 2022 12:57:04 +0200 [thread overview]
Message-ID: <87ilmpzunz.ffs@tglx> (raw)
In-Reply-To: <20220808141538.102394-1-khuey@kylehuey.com>
Kyle!
On Mon, Aug 08 2022 at 07:15, Kyle Huey wrote:
> When management of the PKRU register was moved away from XSTATE, emulation
> of PKRU's existence in XSTATE was added for APIs that read XSTATE, but not
> for APIs that write XSTATE. This can be seen by running gdb and executing
> `p $pkru`, `set $pkru = 42`, and `p $pkru`. On affected kernels (5.14+) the
> write to the PKRU register (which gdb performs through ptrace) is ignored.
>
> There are three relevant APIs: PTRACE_SETREGSET with NT_X86_XSTATE,
> sigreturn, and KVM_SET_XSAVE. KVM_SET_XSAVE has its own special handling to
> make PKRU writes take effect (in fpu_copy_uabi_to_guest_fpstate). Push that
> down into copy_uabi_to_xstate and have PTRACE_SETREGSET with NT_X86_XSTATE
> and sigreturn pass in pointers to the appropriate PKRU value.
>
> This also adds code to initialize the PKRU value to the hardware init value
> (namely 0) if the PKRU bit is not set in the XSTATE header to match XRSTOR.
> This is a change to the current KVM_SET_XSAVE behavior.
You are stating a fact here, but provide 0 justification why this is
correct.
>
> Changelog since v4:
Can you please put the change log past the --- seperator line, so it
gets stripped off when the patch is applied? That spares manual fixups.
>
> Signed-off-by: Kyle Huey <me@kylehuey.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: kvm@vger.kernel.org # For edge case behavior of KVM_SET_XSAVE
> Cc: stable@vger.kernel.org # 5.14+
> Fixes: e84ba47e313d ("x86/fpu: Hook up PKRU into ptrace()")
Can you please use the documented tag ordering?
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-submission-notes
> @@ -1235,6 +1235,24 @@ static int copy_uabi_to_xstate(struct fpstate *fpstate, const void *kbuf,
> for (i = 0; i < XFEATURE_MAX; i++) {
> mask = BIT_ULL(i);
>
> + if (i == XFEATURE_PKRU) {
> + /*
> + * Retrieve PKRU if not in init state, otherwise
> + * initialize it.
> + */
> + if (hdr.xfeatures & mask) {
> + struct pkru_state xpkru = {0};
> +
> + if (copy_from_buffer(&xpkru, xstate_offsets[i],
> + sizeof(xpkru), kbuf, ubuf))
> + return -EFAULT;
> +
> + *pkru = xpkru.pkru;
> + } else {
> + *pkru = 0;
> + }
> + }
That's really horrible and there is no point in copying the stuff from
the buffer twice:
@@ -1246,6 +1246,15 @@ static int copy_uabi_to_xstate(struct fp
}
}
+ /* Update the user protection key storage */
+ *pkru = 0;
+ if (hdr.xfeatures & XFEATURE_MASK_PKRU) {
+ struct pkru_state *xpkru;
+
+ xpkru = get_xsave_addr(xsave, XFEATURE_PKRU);
+ *pkru = xpkru->pkru;
+ }
+
Hmm?
Thanks,
tglx
next prev parent reply other threads:[~2022-08-18 10:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 14:15 [PATCH v5 1/2] x86/fpu: Allow PKRU to be (once again) written by ptrace Kyle Huey
2022-08-08 14:15 ` [PATCH v5 2/2] selftests/vm/pkeys: Add a regression test for setting PKRU through ptrace Kyle Huey
2022-08-18 4:02 ` [PATCH v5 1/2] x86/fpu: Allow PKRU to be (once again) written by ptrace Kyle Huey
2022-08-18 10:57 ` Thomas Gleixner [this message]
2022-08-18 19:48 ` Kyle Huey
2022-08-18 21:19 ` Sean Christopherson
2022-08-26 4:47 ` Kyle Huey
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=87ilmpzunz.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=david.manouchehri@riseup.net \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@kernel.org \
--cc=me@kylehuey.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=robert@ocallahan.org \
--cc=stable@vger.kernel.org \
--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.