lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 12 Jan 2015 16:56:54 -0500
From:	Chris Metcalf <cmetcalf@...hip.com>
To:	"Michael S. Tsirkin" <mst@...hat.com>,
	<linux-kernel@...r.kernel.org>
CC:	Arnd Bergmann <arnd@...db.de>, <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v2 22/40] tile: fix put_user sparse errors

Nack for this patch as-is.

On 1/6/2015 10:44 AM, Michael S. Tsirkin wrote:
> virtio wants to write bitwise types to userspace using put_user.
> At the moment this triggers sparse errors, since the value is passed
> through an integer.
>
> For example:
>
> 	__le32 __user *p;
> 	__le32 x;
> 	put_user(x, p);
>
> is safe, but currently triggers a sparse warning on tile.
>
> The reason has to do with this code:
> 	__typeof((x)-(x))
> which seems to be a way to force check for an integer type.

No, it's purely a way to avoid

   warning: cast from pointer to integer of different size

at every place we invoke put_user() with a pointer - which is
in fact pretty frequent throughout the kernel.  The idiom of
casting to the difference of the type converts it to a type
of the same size as the input (whether integral or pointer),
but guaranteed to be an integral type.  Then from there it's safe
to cast it on to a u64 without generating a warning.

I agree that letting sparse work correctly in this case seems
like an important goal.  But I don't think we can tolerate
adding a raft of warnings to the standard kernel build for this
case, and we also can't just delete the put_user_8 case altogether,
since it's used for various things even in 32-bit kernels.

I suppose we could do something like the following.  It's mildly
unfortunate that we'd lose out on some inlining optimization, though:

--- a/arch/tile/include/asm/uaccess.h
+++ b/arch/tile/include/asm/uaccess.h
@@ -244,24 +244,8 @@ extern int __get_user_bad(void)
  #define __put_user_1(x, ptr, ret) __put_user_asm(sb, x, ptr, ret)
  #define __put_user_2(x, ptr, ret) __put_user_asm(sh, x, ptr, ret)
  #define __put_user_4(x, ptr, ret) __put_user_asm(sw, x, ptr, ret)
-#define __put_user_8(x, ptr, ret)                                      \
-       ({                                                              \
-               u64 __x = (__typeof((x)-(x)))(x);                       \
-               int __lo = (int) __x, __hi = (int) (__x >> 32);         \
-               asm volatile("1: { sw %1, %2; addi %0, %1, 4 }\n"       \
-                            "2: { sw %0, %3; movei %0, 0 }\n"          \
-                            ".pushsection .fixup,\"ax\"\n"             \
-                            "0: { movei %0, %4; j 9f }\n"              \
-                            ".section __ex_table,\"a\"\n"              \
-                            ".align 4\n"                               \
-                            ".word 1b, 0b\n"                           \
-                            ".word 2b, 0b\n"                           \
-                            ".popsection\n"                            \
-                            "9:"                                       \
-                            : "=&r" (ret)                              \
-                            : "r" (ptr), "r" (__lo32(__lo, __hi)),     \
-                            "r" (__hi32(__lo, __hi)), "i" (-EFAULT));  \
-       })
+#define __put_user_8(x, ptr, ret) \
+  (ret = __copy_to_user_inatomic(ptr, &x, 8) == 0 ? 0 : -EFAULT)
  #endif

  extern int __put_user_bad(void)


> Since this is part of __put_user_8 which is only ever used
> for unsigned and signed char types, this seems unnecessary -
> I also note that no other architecture has such protections.

Maybe because none of the other 32-bit kernel architectures provide
a 64-bit inline for put_user().

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ