All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Max Filippov <jcmvbkbc@gmail.com>
Cc: "open list:TENSILICA XTENSA PORT (xtensa)" 
	<linux-xtensa@linux-xtensa.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xtensa: fix {get,put}_user() for 64bit values
Date: Thu, 10 Oct 2019 02:56:06 +0100	[thread overview]
Message-ID: <20191010015606.GD26530@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAMo8BfKUOmExGRMaUPmcRsy=iyRrguLF6JOLUMegNnzkF9vcvQ@mail.gmail.com>

On Wed, Oct 09, 2019 at 06:38:12PM -0700, Max Filippov wrote:

> There's also the following code in the callers of this macro, e.g. in
> __get_user_nocheck:
> 
>         long __gu_err, __gu_val;                                \
>         __get_user_size(__gu_val, (ptr), (size), __gu_err);     \
>         (x) = (__force __typeof__(*(ptr)))__gu_val;             \
> 
> the last line is important for sizes 1..4, because it takes care of
> sign extension of the value loaded by the assembly.
> At the same time the first line doesn't make sense for the size 8
> as it will result in value truncation.

Right you are...

> +       long __gu_err;                                          \
> +       __typeof__(*(ptr) + 0) __gu_val;                        \

What would __u64 __gu_val; end up with for smaller sizes?  I don't have
xtensa cross-toolchain at the moment, so I can't check it easily;
what does =r constraint generate in such case?

Another thing is, you want to zero it on failure, to avoid an uninitialized
value ending up someplace interesting....

> @@ -198,7 +200,7 @@ do {
>                          \
>         case 1: __get_user_asm(x, ptr, retval, 1, "l8ui", __cb);  break;\
>         case 2: __get_user_asm(x, ptr, retval, 2, "l16ui", __cb); break;\
>         case 4: __get_user_asm(x, ptr, retval, 4, "l32i", __cb);  break;\
> -       case 8: retval = __copy_from_user(&x, ptr, 8);    break;        \
> +       case 8: retval = __copy_from_user(&x, ptr, 8) ? -EFAULT : 0;
>  break;  \
>         default: (x) = __get_user_bad();                                \
>         }                                                               \
>  } while (0)
> 
> Here __typeof__(*(ptr) + 0) makes enough room for all cases
> in the __get_user_size and the "+0" part takes care of pointers
> to const data.

  reply	other threads:[~2019-10-10  1:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 19:21 [PATCH] xtensa: fix {get,put}_user() for 64bit values Al Viro
2019-10-10  1:38 ` Max Filippov
2019-10-10  1:56   ` Al Viro [this message]
2019-10-10  2:11     ` Max Filippov
2019-10-10 14:29       ` Al Viro
2019-10-11  3:35         ` Max Filippov

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=20191010015606.GD26530@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=jcmvbkbc@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.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.