search for: uaccess_try_nospec

...> 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 deletions(-) > > > &...

...> 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 deletions(-) > > > &...

...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, then sure, feel free to...

...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, then sure, feel free to...

...ity 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

...t; > > > 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&...

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

...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 obvious when transferring small packets since > the time spen...

...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 obvious when transferring small packets since > the time spen...

...>> 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...

...riers, > > 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 > > &gt...

Hi: Per request from Michael and Jason, the metadata accelreation is reverted in this version and rework in next version. Please review. Thanks Jason Wang (2): Revert "vhost: access vq metadata through kernel virtual address" vhost: re-introducing metadata acceleration through kernel virtual address drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------

Hi: Per request from Michael and Jason, the metadata accelreation is reverted in this version and rework in next version. Please review. Thanks Jason Wang (2): Revert "vhost: access vq metadata through kernel virtual address" vhost: re-introducing metadata acceleration through kernel virtual address drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------