search for: array_index_nospec

..."BUILD_BUG_ON failed: " #condition) ^~~~~~~~~~~~~~~~ >> include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON' BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \ ^~~~~~~~~~~~ >> drivers/vhost/vhost.c:2076:5: note: in expansion of macro 'array_index_nospec' array_index_nospec(addr - node->start, ^~~~~~~~~~~~~~~~~~ >> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_2077' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long) _compiletime_assert(condition, msg, __...

iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the address is not validated out of node range. Signed-off-by: Michael S. Tsirkin <ms...

iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the address is not validated out of node range. Signed-off-by: Michael S. Tsirkin <ms...

iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the address is not validated out of node range. Signed-off-by: Michael S. Tsirkin <ms...

iovec addresses coming from vhost are assumed to be pre-validated, but in fact can be speculated to a value out of range. Userspace address are later validated with array_index_nospec so we can be sure kernel info does not leak through these addresses, but vhost must also not leak userspace info outside the allowed memory table to guests. Following the defence in depth principle, make sure the address is not validated out of node range. Signed-off-by: Michael S. Tsirkin <ms...

...M +0800, Jason Wang wrote: > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not leak through these addresses, but vhost > > must also not leak userspace info outside the allowed memory table to > > guests. > > > > Following the defence in depth principle, make sure > > the address is not validated...

...M +0800, Jason Wang wrote: > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not leak through these addresses, but vhost > > must also not leak userspace info outside the allowed memory table to > > guests. > > > > Following the defence in depth principle, make sure > > the address is not validated...

...??7:05, Michael S. Tsirkin wrote: > > > > iovec addresses coming from vhost are assumed to be > > > > pre-validated, but in fact can be speculated to a value > > > > out of range. > > > > > > > > Userspace address are later validated with array_index_nospec so we can > > > > be sure kernel info does not leak through these addresses, but vhost > > > > must also not leak userspace info outside the allowed memory table to > > > > guests. > > > > > > > > Following the defence in depth principle,...

...+0200, Michal Hocko wrote: > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not leak through these addresses, but vhost > > must also not leak userspace info outside the allowed memory table to > > guests. > > > > Following the defence in depth principle, make sure > > the address is not validated...

...+0200, Michal Hocko wrote: > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote: > > iovec addresses coming from vhost are assumed to be > > pre-validated, but in fact can be speculated to a value > > out of range. > > > > Userspace address are later validated with array_index_nospec so we can > > be sure kernel info does not leak through these addresses, but vhost > > must also not leak userspace info outside the allowed memory table to > > guests. > > > > Following the defence in depth principle, make sure > > the address is not validated...

...oblem here in access will now be speculated. > > This effectively disables the defence in depth effect of > > b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd > > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec > > > > > > So now we need to sprinkle array_index_nospec or barrier_nospec over the > > code whenever we use an index we got from userspace. > > See below for some examples. > > > > > > > hardware feature toggling (e.g SMAP). The > > > extra cost will be more obvious when transferring small packets since > &...

...arriers, So if we drop speculation barrier, there's a problem here in access will now be speculated. This effectively disables the defence in depth effect of b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec So now we need to sprinkle array_index_nospec or barrier_nospec over the code whenever we use an index we got from userspace. See below for some examples. > hardware feature toggling (e.g SMAP). The > extra cost will be more obvious when transferring small packets since > the time spent on metadata accessing become more significant....

...arriers, So if we drop speculation barrier, there's a problem here in access will now be speculated. This effectively disables the defence in depth effect of b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec So now we need to sprinkle array_index_nospec or barrier_nospec over the code whenever we use an index we got from userspace. See below for some examples. > hardware feature toggling (e.g SMAP). The > extra cost will be more obvious when transferring small packets since > the time spent on metadata accessing become more significant....

...:10:00, Michael S. Tsirkin wrote: > > > > iovec addresses coming from vhost are assumed to be > > > > pre-validated, but in fact can be speculated to a value > > > > out of range. > > > > > > > > Userspace address are later validated with array_index_nospec so we can > > > > be sure kernel info does not leak through these addresses, but vhost > > > > must also not leak userspace info outside the allowed memory table to > > > > guests. > > > > > > > > Following the defence in depth principle,...

...:10:00, Michael S. Tsirkin wrote: > > > > iovec addresses coming from vhost are assumed to be > > > > pre-validated, but in fact can be speculated to a value > > > > out of range. > > > > > > > > Userspace address are later validated with array_index_nospec so we can > > > > be sure kernel info does not leak through these addresses, but vhost > > > > must also not leak userspace info outside the allowed memory table to > > > > guests. > > > > > > > > Following the defence in depth principle,...

On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > iovec addresses coming from vhost are assumed to be > pre-validated, but in fact can be speculated to a value > out of range. > > Userspace address are later validated with array_index_nospec so we can > be sure kernel info does not leak through these addresses, but vhost > must also not leak userspace info outside the allowed memory table to > guests. > > Following the defence in depth principle, make sure > the address is not validated out of node range. > > Si...

...on Wang wrote: >> On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: >>> iovec addresses coming from vhost are assumed to be >>> pre-validated, but in fact can be speculated to a value >>> out of range. >>> >>> Userspace address are later validated with array_index_nospec so we can >>> be sure kernel info does not leak through these addresses, but vhost >>> must also not leak userspace info outside the allowed memory table to >>> guests. >>> >>> Following the defence in depth principle, make sure >>> the address...

On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote: > iovec addresses coming from vhost are assumed to be > pre-validated, but in fact can be speculated to a value > out of range. > > Userspace address are later validated with array_index_nospec so we can > be sure kernel info does not leak through these addresses, but vhost > must also not leak userspace info outside the allowed memory table to > guests. > > Following the defence in depth principle, make sure > the address is not validated out of node range. > >...

On Wed, Sep 11, 2019 at 08:10:00AM -0400, Michael S. Tsirkin wrote: > iovec addresses coming from vhost are assumed to be > pre-validated, but in fact can be speculated to a value > out of range. > > Userspace address are later validated with array_index_nospec so we can > be sure kernel info does not leak through these addresses, but vhost > must also not leak userspace info outside the allowed memory table to > guests. > > Following the defence in depth principle, make sure > the address is not validated out of node range. > >...

...vers/vhost/vhost.c index acabf20b069e..102a0c877007 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -2074,7 +2074,7 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len, _iov->iov_base = (void __user *) ((unsigned long)node->userspace_addr + array_index_nospec((unsigned long)(addr - node->start), - node->size)); + (unsigned long)node->size)); s += size; addr += size; ++ret; -- 2.7.4