mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Sean Christopherson <seanjc@google.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>
Cc: the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: some apparently valid objtool clang warnings
Date: Thu, 23 Jun 2022 14:42:38 +0200	[thread overview]
Message-ID: <a387ad62-4f96-c226-d062-5e1905ef1aee@redhat.com> (raw)
In-Reply-To: <CAHk-=whUJTQuLorG=pRv1XAe_=9oWrVFkYb26q87fhkqDs5zcQ@mail.gmail.com>

On Wed, Jun 22, 2022 at 6:58 PM Linus Torvalds <torvalds@linux-foundation.org> wrote:
> In particular, the
>
>   call to __ubsan_handle_load_invalid_value() with UACCESS enabled
>
> warnings tend to be a real sign that somebody is doing something very
> wrong inside a user access region, and kvm seems to be buggy here.
> In particular, kvm does
>
>   #define emulator_try_cmpxchg_user(t, ptr, old, new) \
>         (__try_cmpxchg_user((t __user *)(ptr), (t *)(old), *(t
> *)(new), efault ## t))
>
> and look at that third argument: "*(t *)(new)". It is doing a pointer
> dereference [...] inside the __uaccess_begin_nospec()/__uaccess_end()
> region [...] and *both* of those lines are buggy, since they both do 
> memory accesses that are not to user space [...] We also do have that
>
>         if (unlikely(!success))
>                 *_old = __old;
>
> inside __try_cmpxchg_user_asm after the actual asm that also seems
> buggy and wrong for the exact same reason - it shouldn't be done
> within the STAC region.
>
> Comments? I think those old/new things should be moved out one macro
> level, and be done inside __try_cmpxchg_user() itself, outside the
> uaccess region.
>
> That may require some games for the end-game where we do that "assign
> the _old value", and maybe the __uaccess_end needs to be moved into
> the success case. But it would be good to do this right. No?

Yes, I agree that __try_cmpxchg_user should look more like this:

  /* "Returns" 0 on success, 1 on failure, -EFAULT if the access faults. */
  #define __try_cmpxchg_user(_ptr, _oldp, _nval, _label)	({		\
  	int __ret = -EFAULT;						\
+	__typeof__(_ptr) __ptr = (_ptr);				\
+	__typeof__(_ptr) __pold = (__typeof__(_ptr))(_oldp);		\
+	__typeof__(*(_ptr)) __old = *__pold;				\
+	__typeof__(*(_ptr)) __new = (_nval);				\
  	__uaccess_begin_nospec();					\
-	__ret = !unsafe_try_cmpxchg_user(_ptr, _oldp, _nval, _label);	\
+	__ret = !____try_cmpxchg_user(__ptr, __old, __new, _label);	\
  _label:									\
  	__uaccess_end();						\
+	if (unlikely(!__result))					\
+		*__pold = __old;						\
  	__ret;								\
  							})
(where I have renamed unsafe_try_cmpxchg_user because it doesn't
anymore write to *_pold; it's not a full try_cmpxchg).  I'll
clean up the rest of the macros and send it out as a patch.

Paolo


      reply	other threads:[~2022-06-23 12:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-22 16:57 Linus Torvalds
2022-06-23 12:42 ` Paolo Bonzini [this message]

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=a387ad62-4f96-c226-d062-5e1905ef1aee@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=seanjc@google.com \
    --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

all inboxes | Powered by JetHome®