linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Kyle Huey <me@kylehuey.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>, 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>,
	Sean Christopherson <seanjc@google.com>,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	Robert O'Callahan <robert@ocallahan.org>,
	David Manouchehri <david.manouchehri@riseup.net>,
	Borislav Petkov <bp@suse.de>,
	stable@vger.kernel.org
Subject: Re: [RESEND PATCH v6 1/2] x86/fpu: Allow PKRU to be (once again) written by ptrace.
Date: Thu, 10 Nov 2022 17:37:58 -0800	[thread overview]
Message-ID: <b41b6a33-7fdc-bd54-8b15-02bf4e713ed7@intel.com> (raw)
In-Reply-To: <CAP045ArEuTmA6DGoVEgeSRd-F+oQCqRaeyzwgdxuCnOP0jgqWA@mail.gmail.com>

On 11/10/22 16:03, Kyle Huey wrote:
> On Tue, Nov 8, 2022 at 10:23 AM Dave Hansen <dave.hansen@intel.com> wrote:
...
>> At a high level, this patch does a *LOT*.  Generally, it's nice when
>> bugfixes can be encapsulted in one patch, but I think there's too much
>> going on here for one patch.
> 
> Ok. How about I break the first part into two pieces, one that changes the
> signatures of copy_uabi_from_kernel_to_xstate() and
> copy_sigframe_from_user_to_xstate(), and one that moves the relevant
> KVM code from fpu_copy_uabi_to_guest_fpstate() to copy_uabi_to_xstate()
> and deals with the edge case behavior of the mask?

Sounds like a good start.  My gut says there's another patch or two that
could be broken out, but that sounds like a reasonable next step.

>>> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
>>> index 3b28c5b25e12..c273669e8a00 100644
>>> --- a/arch/x86/kernel/fpu/core.c
>>> +++ b/arch/x86/kernel/fpu/core.c
>>> @@ -391,8 +391,6 @@ int fpu_copy_uabi_to_guest_fpstate(struct fpu_guest *gfpu, const void *buf,
>>>  {
>>>       struct fpstate *kstate = gfpu->fpstate;
>>>       const union fpregs_state *ustate = buf;
>>> -     struct pkru_state *xpkru;
>>> -     int ret;
>>>
>>>       if (!cpu_feature_enabled(X86_FEATURE_XSAVE)) {
>>>               if (ustate->xsave.header.xfeatures & ~XFEATURE_MASK_FPSSE)
>>> @@ -406,16 +404,16 @@ int fpu_copy_uabi_to_guest_fpstate(struct fpu_guest *gfpu, const void *buf,
>>>       if (ustate->xsave.header.xfeatures & ~xcr0)
>>>               return -EINVAL;
>>>
>>> -     ret = copy_uabi_from_kernel_to_xstate(kstate, ustate);
>>> -     if (ret)
>>> -             return ret;
>>> +     /*
>>> +      * Nullify @vpkru to preserve its current value if PKRU's bit isn't set
>>> +      * in the header.  KVM's odd ABI is to leave PKRU untouched in this
>>> +      * case (all other components are eventually re-initialized).
>>> +      * (Not clear that this is actually necessary for compat).
>>> +      */
>>> +     if (!(ustate->xsave.header.xfeatures & XFEATURE_MASK_PKRU))
>>> +             vpkru = NULL;
>>
>> I'm not a big fan of hunks that are part of bugfixes where it is not
>> clear that the hunk is necessary.
> 
> This is necessary to avoid changing KVM's behavior at the same time
> that we change
> ptrace, since KVM doesn't want the same behavior as ptrace.

Your "This is necessary" doesn't really match with "Not clear that this
is actually necessary" from the comment, right?

Rather than claim whether it is necessary or not, maybe just say why
it's there: it's there to preserve wonky KVM behavior.

BTW, I'd love to know if KVM *REALLY* depends on this.  It'd be nice to
kill if not.
>> Would something like this be more clear?
>>
>>         if (hdr.xfeatures & XFEATURE_MASK_PKRU) {
>>                 struct pkru_state *xpkru;
>>
>>                 xpkru = __raw_xsave_addr(xsave, XFEATURE_PKRU);
>>                 *pkru = xpkru->pkru;
>>         } else {
>>                 /*
>>                  * KVM may pass a NULL 'pkru' to indicate
>>                  * that it does not need PKRU updated.
>>                  */
>>                 if (pkru)
>>                         *pkru = 0;
>>         }
> 
> Yeah, Sean Christopherson suggested this (with the else and if
> collapsed into a single level) when I submitted this previously.

I generally agree with Sean, but he's also been guilty of an atrocity or
two over the years.  :)  While I generally like low levels of
indentation I also think my version is much more clear in this case.


  reply	other threads:[~2022-11-11  1:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-07  6:38 [RESEND PATCH v6] x86/fpu: Trying to fix writing PKRU through ptrace Kyle Huey
2022-11-07  6:38 ` [RESEND PATCH v6 1/2] x86/fpu: Allow PKRU to be (once again) written by ptrace Kyle Huey
2022-11-08 18:23   ` Dave Hansen
2022-11-11  0:03     ` Kyle Huey
2022-11-11  1:37       ` Dave Hansen [this message]
2022-11-11 16:37         ` Kyle Huey
2022-11-11 17:00         ` Sean Christopherson
2022-11-07  6:38 ` [RESEND PATCH v6 2/2] selftests/vm/pkeys: Add a regression test for setting PKRU through ptrace Kyle Huey
2022-11-07 20:49 ` [RESEND PATCH v6] x86/fpu: Trying to fix writing " Slade Watkins
2022-11-07 20:52   ` Dave Hansen
2022-11-10  3:09     ` Slade Watkins

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=b41b6a33-7fdc-bd54-8b15-02bf4e713ed7@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bp@alien8.de \
    --cc=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.manouchehri@riseup.net \
    --cc=hpa@zytor.com \
    --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=seanjc@google.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).