From: "Michael S. Tsirkin" <mst@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
netdev@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
bijan.mottahedeh@oracle.com, gedwards@ddn.com, joe@perches.com,
lenaic@lhuard.fr, liang.z.li@intel.com, mhocko@kernel.org,
mhocko@suse.com, stefanha@redhat.com, wei.w.wang@intel.com
Subject: Re: [PULL] vhost: cleanups and fixes
Date: Fri, 2 Nov 2018 09:04:11 -0400 [thread overview]
Message-ID: <20181102083018-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20181102114635.hi3q53kzmz4qljsf@lakrids.cambridge.arm.com>
On Fri, Nov 02, 2018 at 11:46:36AM +0000, Mark Rutland wrote:
> On Thu, Nov 01, 2018 at 04:06:19PM -0700, Linus Torvalds wrote:
> > On Thu, Nov 1, 2018 at 4:00 PM Kees Cook <keescook@chromium.org> wrote:
> > >
> > > + memset(&rsp, 0, sizeof(rsp));
> > > + rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED;
> > > + resp = vq->iov[out].iov_base;
> > > + ret = __copy_to_user(resp, &rsp, sizeof(rsp));
> > >
> > > Is it actually safe to trust that iov_base has passed an earlier
> > > access_ok() check here? Why not just use copy_to_user() instead?
> >
> > Good point.
> >
> > We really should have removed those double-underscore things ages ago.
>
> FWIW, on arm64 we always check/sanitize the user address as a result of
> our sanitization of speculated values. Almost all of our uaccess
> routines have an explicit access_ok().
>
> All our uaccess routines mask the user pointer based on addr_limit,
> which prevents speculative or architectural uaccess to kernel addresses
> when addr_limit it USER_DS:
>
> 4d8efc2d5ee4c9cc ("arm64: Use pointer masking to limit uaccess speculation")
>
> We also inhibit speculative stores to addr_limit being forwarded under
> speculation:
>
> c2f0ad4fc089cff8 ("arm64: uaccess: Prevent speculative use of the current addr_limit")
>
> ... and given all that, we folded explicit access_ok() checks into
> __{get,put}_user():
>
> 84624087dd7e3b48 ("arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user")
>
> IMO we could/should do the same for __copy_{to,from}_user().
>
> Thanks,
> Mark.
I've tried making access_ok mask the parameter it gets. Works because
access_ok is a macro. Most users pass in a variable so that will block
attempts to use speculation to bypass the access_ok checks.
Not 100% as someone can copy the value before access_ok, but
then it's all mitigation anyway.
Places which call access_ok on a non-lvalue need to be fixed then but
there are not too many of these.
The advantage here is that a code like this:
access_ok
for(...)
__get_user
isn't slowed down as the masking is outside the loop.
OTOH macros changing their arguments are kind of ugly.
What do others think?
Just to show what I mean:
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index aae77eb8491c..c4d12c8f47d7 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -7,6 +7,7 @@
#include <linux/compiler.h>
#include <linux/kasan-checks.h>
#include <linux/string.h>
+#include <linux/nospec.h>
#include <asm/asm.h>
#include <asm/page.h>
#include <asm/smap.h>
@@ -69,6 +70,33 @@ static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size, un
__chk_range_not_ok((unsigned long __force)(addr), size, limit); \
})
+/*
+ * Test whether a block of memory is a valid user space address.
+ * Returns 0 if the range is valid, address itself otherwise.
+ */
+static inline unsigned long __verify_range_nospec(unsigned long addr,
+ unsigned long size,
+ unsigned long limit)
+{
+ /* Be careful about overflow */
+ limit = array_index_nospec(limit, size);
+
+ /*
+ * If we have used "sizeof()" for the size,
+ * we know it won't overflow the limit (but
+ * it might overflow the 'addr', so it's
+ * important to subtract the size from the
+ * limit, not add it to the address).
+ */
+ if (__builtin_constant_p(size)) {
+ return array_index_nospec(addr, limit - size + 1);
+ }
+
+ /* Arbitrary sizes? Be careful about overflow */
+ return array_index_mask_nospec(limit, size) &
+ array_index_nospec(addr, limit - size + 1);
+}
+
#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
# define WARN_ON_IN_IRQ() WARN_ON_ONCE(!in_task())
#else
@@ -95,12 +123,46 @@ static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size, un
* checks that the pointer is in the user space range - after calling
* this function, memory access functions may still return -EFAULT.
*/
-#define access_ok(type, addr, size) \
+#define unsafe_access_ok(type, addr, size) \
({ \
WARN_ON_IN_IRQ(); \
likely(!__range_not_ok(addr, size, user_addr_max())); \
})
+/**
+ * access_ok_nospec: - Checks if a user space pointer is valid
+ * @type: Type of access: %VERIFY_READ or %VERIFY_WRITE. Note that
+ * %VERIFY_WRITE is a superset of %VERIFY_READ - if it is safe
+ * to write to a block, it is always safe to read from it.
+ * @addr: User space pointer to start of block to check
+ * @size: Size of block to check
+ *
+ * Context: User context only. This function may sleep if pagefaults are
+ * enabled.
+ *
+ * Checks if a pointer to a block of memory in user space is valid.
+ *
+ * Returns address itself (nonzero) if the memory block may be valid,
+ * zero if it is definitely invalid.
+ *
+ * To prevent speculation, the returned value must then be used
+ * for accesses.
+ *
+ * Note that, depending on architecture, this function probably just
+ * checks that the pointer is in the user space range - after calling
+ * this function, memory access functions may still return -EFAULT.
+ */
+#define access_ok_nospec(type, addr, size) \
+({ \
+ WARN_ON_IN_IRQ(); \
+ __chk_user_ptr(addr); \
+ addr = (typeof(addr) __force) \
+ __verify_range_nospec((unsigned long __force)(addr), \
+ size, user_addr_max()); \
+})
+
+#define access_ok(type, addr, size) access_ok_nospec(type, addr, size)
+
/*
* These are the main single-value transfer routines. They automatically
* use the right size if we just have the right pointer type.
--
MST
next prev parent reply other threads:[~2018-11-02 13:04 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-01 21:19 [PULL] vhost: cleanups and fixes Michael S. Tsirkin
2018-11-01 21:44 ` Linus Torvalds
2018-11-01 23:00 ` Kees Cook
2018-11-01 23:06 ` Linus Torvalds
2018-11-01 23:55 ` Michael S. Tsirkin
2018-11-02 11:46 ` Mark Rutland
2018-11-02 13:04 ` Michael S. Tsirkin [this message]
2018-11-02 16:14 ` Linus Torvalds
2018-11-02 16:59 ` Michael S. Tsirkin
2018-11-02 17:10 ` Linus Torvalds
2018-11-02 17:15 ` Linus Torvalds
2018-11-02 19:01 ` Al Viro
2018-11-02 17:21 ` Michael S. Tsirkin
2018-11-02 18:02 ` Linus Torvalds
2018-11-02 18:12 ` Michael S. Tsirkin
2018-11-30 13:44 ` Michael S. Tsirkin
2018-11-30 19:01 ` Bijan Mottahedeh
2018-11-30 19:55 ` Michael S. Tsirkin
2018-11-01 23:38 ` Michael S. Tsirkin
[not found] <20200210010252-mutt-send-email-mst@kernel.org>
2020-02-11 2:07 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2019-10-15 21:19 Michael S. Tsirkin
2019-10-15 22:25 ` pr-tracker-bot
2019-05-14 21:11 Michael S. Tsirkin
2019-05-14 21:20 ` pr-tracker-bot
2018-06-11 16:23 Michael S. Tsirkin
2018-06-11 18:32 ` Linus Torvalds
2018-06-11 18:44 ` Linus Torvalds
2018-06-12 1:36 ` Michael S. Tsirkin
2018-06-12 1:59 ` Linus Torvalds
2018-06-12 11:05 ` Wei Wang
2018-06-14 15:01 ` Nitesh Narayan Lal
2018-06-15 3:53 ` Wei Wang
2018-06-12 1:57 ` Michael S. Tsirkin
2017-12-08 15:47 Michael S. Tsirkin
2017-12-04 13:25 Michael S. Tsirkin
2017-08-25 18:47 Michael S. Tsirkin
2017-04-10 21:36 Michael S. Tsirkin
2017-03-02 5:49 Michael S. Tsirkin
2017-02-03 21:43 Michael S. Tsirkin
2017-01-23 15:05 Michael S. Tsirkin
2017-01-23 21:50 ` Linus Torvalds
2017-01-24 2:45 ` Michael S. Tsirkin
2016-05-24 11:57 Michael S. Tsirkin
2015-12-21 7:58 Michael S. Tsirkin
2015-12-07 17:07 Michael S. Tsirkin
2015-09-18 10:42 Michael S. Tsirkin
2015-09-09 9:15 Michael S. Tsirkin
2015-07-28 10:00 Michael S. Tsirkin
2015-07-15 10:50 Michael S. Tsirkin
2015-07-15 11:26 ` Michael S. Tsirkin
2015-06-01 19:18 Michael S. Tsirkin
2015-06-01 19:45 ` Michael S. Tsirkin
2015-01-08 7:51 Michael S. Tsirkin
2015-01-01 12:26 Michael S. Tsirkin
2014-12-18 10:46 Michael S. Tsirkin
2014-11-13 21:22 Michael S. Tsirkin
2014-06-25 11:05 Michael S. Tsirkin
2013-07-15 18:31 Michael S. Tsirkin
2013-07-22 8:07 ` Michael S. Tsirkin
2013-07-08 11:45 Michael S. Tsirkin
2013-05-02 10:53 Michael S. Tsirkin
2013-05-02 18:55 ` Nicholas A. Bellinger
2013-05-02 19:33 ` Michael S. Tsirkin
2013-05-02 19:49 ` Linus Torvalds
2013-06-05 15:53 ` Michael S. Tsirkin
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=20181102083018-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bijan.mottahedeh@oracle.com \
--cc=gedwards@ddn.com \
--cc=joe@perches.com \
--cc=keescook@chromium.org \
--cc=kvm@vger.kernel.org \
--cc=lenaic@lhuard.fr \
--cc=liang.z.li@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=netdev@vger.kernel.org \
--cc=stefanha@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wei.w.wang@intel.com \
/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).