search for: __uaccess_begin_nospec

...e fixes tend to be backported > even when the security implications are not really clear. The risk > should be low and better to be covered in case. This is not really a fix - more a defence in depth thing, quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec in scope. That one doesn't seem to be tagged for stable. Was it queued there in practice? > > --- > > > > changes from v1: fix build on 32 bit > > > > drivers/vhost/vhost.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 delet...

...e fixes tend to be backported > even when the security implications are not really clear. The risk > should be low and better to be covered in case. This is not really a fix - more a defence in depth thing, quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec in scope. That one doesn't seem to be tagged for stable. Was it queued there in practice? > > --- > > > > changes from v1: fix build on 32 bit > > > > drivers/vhost/vhost.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 delet...

...ecurity implications are not really clear. The risk > > > should be low and better to be covered in case. > > > > This is not really a fix - more a defence in depth thing, > > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd > > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec > > in scope. > > > > That one doesn't seem to be tagged for stable. Was it queued > > there in practice? > > not marked for stable but it went in. At least to 4.4. So I guess the answer is I don't know. If you feel it's justified...

...ecurity implications are not really clear. The risk > > > should be low and better to be covered in case. > > > > This is not really a fix - more a defence in depth thing, > > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd > > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec > > in scope. > > > > That one doesn't seem to be tagged for stable. Was it queued > > there in practice? > > not marked for stable but it went in. At least to 4.4. So I guess the answer is I don't know. If you feel it's justified...

...ce memory and handling faults. Unfortunately there does not >> appear to exist an API that whitelists a specific driver along the lines >> of "I checked this code for speculative info leaks, don't add barriers >> on data path please". > Yes that's unfortunate, __uaccess_begin_nospec() is now making > prohibitive to frequently access userland code. > > I doubt we can do like access_ok() and only check it once. access_ok > checks the virtual address, and if the virtual address is ok doesn't > wrap around and it points to userland in a safe range, it's alwa...

...ing > userspace memory and handling faults. Unfortunately there does not > appear to exist an API that whitelists a specific driver along the lines > of "I checked this code for speculative info leaks, don't add barriers > on data path please". Yes that's unfortunate, __uaccess_begin_nospec() is now making prohibitive to frequently access userland code. I doubt we can do like access_ok() and only check it once. access_ok checks the virtual address, and if the virtual address is ok doesn't wrap around and it points to userland in a safe range, it's always ok. There's no ne...

...ing > userspace memory and handling faults. Unfortunately there does not > appear to exist an API that whitelists a specific driver along the lines > of "I checked this code for speculative info leaks, don't add barriers > on data path please". Yes that's unfortunate, __uaccess_begin_nospec() is now making prohibitive to frequently access userland code. I doubt we can do like access_ok() and only check it once. access_ok checks the virtual address, and if the virtual address is ok doesn't wrap around and it points to userland in a safe range, it's always ok. There's no ne...

On 2019/1/7 ??11:28, Michael S. Tsirkin wrote: > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: >> On 2019/1/3 ??4:47, Michael S. Tsirkin wrote: >>> On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: >>>> This series tries to access virtqueue metadata through kernel virtual >>>> address instead of copy_user() friends since they had

On 2019/1/7 ??11:28, Michael S. Tsirkin wrote: > On Mon, Jan 07, 2019 at 10:19:03AM +0800, Jason Wang wrote: >> On 2019/1/3 ??4:47, Michael S. Tsirkin wrote: >>> On Sat, Dec 29, 2018 at 08:46:51PM +0800, Jason Wang wrote: >>>> This series tries to access virtqueue metadata through kernel virtual >>>> address instead of copy_user() friends since they had

On Wed, Mar 06, 2019 at 02:18:12AM -0500, Jason Wang wrote: > +static const struct mmu_notifier_ops vhost_mmu_notifier_ops = { > + .invalidate_range = vhost_invalidate_range, > +}; > + > void vhost_dev_init(struct vhost_dev *dev, > struct vhost_virtqueue **vqs, int nvqs, int iov_limit) > { I also wonder here: when page is write protected then it does not look like

On Wed, Mar 06, 2019 at 02:18:12AM -0500, Jason Wang wrote: > +static const struct mmu_notifier_ops vhost_mmu_notifier_ops = { > + .invalidate_range = vhost_invalidate_range, > +}; > + > void vhost_dev_init(struct vhost_dev *dev, > struct vhost_virtqueue **vqs, int nvqs, int iov_limit) > { I also wonder here: when page is write protected then it does not look like

...; > > > Before: 4.8Mpps > > > > > > After: 5.2Mpps > > OK so would you say it's really unsafe versus safe accesses? > > Or would you say it's just a better written code? > > > It's the effect of removing speculation barrier. You mean __uaccess_begin_nospec introduced by commit 304ec1b050310548db33063e567123fae8fd0301 ? So fundamentally we do access_ok checks when supplying the memory table to the kernel thread, and we should do the spec barrier there. Then we can just create and use a variant of uaccess macros that does not include the barrier? Or...

...> > even when the security implications are not really clear. The risk > > should be low and better to be covered in case. > > This is not really a fix - more a defence in depth thing, > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec > in scope. > > That one doesn't seem to be tagged for stable. Was it queued > there in practice? not marked for stable but it went in. At least to 4.4. -- Michal Hocko SUSE Labs

...not really clear. The risk > > > > should be low and better to be covered in case. > > > > > > This is not really a fix - more a defence in depth thing, > > > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd > > > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec > > > in scope. > > > > > > That one doesn't seem to be tagged for stable. Was it queued > > > there in practice? > > > > not marked for stable but it went in. At least to 4.4. > > So I guess the answer is I don...

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

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

...tion like vhost since it involves lots of software checks, > speculation barriers, 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...

...tion like vhost since it involves lots of software checks, > speculation barriers, 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...

...lves lots of software checks, >> speculation barriers, > 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...

...gt; > > speculation barriers, > > 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...