similar to: [PATCH v2] vhost: block speculation of translated descriptors

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

On Mon, Sep 09, 2019 at 03:19:55PM +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

On Mon, Sep 09, 2019 at 03:19:55PM +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

On Tue, Sep 10, 2019 at 09:52:10AM +0800, Jason Wang wrote: > > On 2019/9/9 ??10:45, Michael S. Tsirkin wrote: > > On Mon, Sep 09, 2019 at 03:19:55PM +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

On Wed, Sep 11, 2019 at 02:16:28PM +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

On Wed, Sep 11, 2019 at 02:16:28PM +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

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

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

On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote: > This is a rework on the commit 7f466032dc9e ("vhost: access vq > metadata through kernel virtual address"). > > It was noticed that the copy_to/from_user() friends that was used to > access virtqueue metdata tends to be very expensive for dataplane > implementation like vhost since it involves lots of

On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote: > This is a rework on the commit 7f466032dc9e ("vhost: access vq > metadata through kernel virtual address"). > > It was noticed that the copy_to/from_user() friends that was used to > access virtqueue metdata tends to be very expensive for dataplane > implementation like vhost since it involves lots of

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

On 2019/9/9 ??10:45, Michael S. Tsirkin wrote: > On Mon, Sep 09, 2019 at 03:19:55PM +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

On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote: > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote: > > On Wed, Sep 11, 2019 at 02:16:28PM +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

On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote: > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote: > > On Wed, Sep 11, 2019 at 02:16:28PM +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

Building vhost on 32-bit targets results in the following error. drivers/vhost/vhost.c: In function 'translate_desc': include/linux/compiler.h:549:38: error: call to '__compiletime_assert_1879' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long) Fixes: a89db445fbd7 ("vhost: block speculation of translated descriptors") Cc: Michael S.

From: Hongyong Zang <zanghongyong at huawei.com> Vhost-net uses its own vhost_memory, which results from user space (qemu) info, to translate GPA to HVA. Since kernel's kvm structure already maintains the address relationship in its member *kvm_memslots*, these patches use kernel's kvm_memslots directly without the need of initialization and maintenance of vhost_memory. Hongyong

From: Hongyong Zang <zanghongyong at huawei.com> Vhost-net uses its own vhost_memory, which results from user space (qemu) info, to translate GPA to HVA. Since kernel's kvm structure already maintains the address relationship in its member *kvm_memslots*, these patches use kernel's kvm_memslots directly without the need of initialization and maintenance of vhost_memory. Hongyong

On Mon, Sep 09, 2019 at 10:18:57AM +0800, Jason Wang wrote: > > On 2019/9/8 ??7:05, Michael S. Tsirkin wrote: > > On Thu, Sep 05, 2019 at 08:27:36PM +0800, Jason Wang wrote: > > > This is a rework on the commit 7f466032dc9e ("vhost: access vq > > > metadata through kernel virtual address"). > > > > > > It was noticed that the

This patch tries to implement an device IOTLB for vhost. This could be used with for co-operation with userspace(qemu) implementation of iommu for a secure DMA environment (DMAR) in guest. The idea is simple. When vhost meets an IOTLB miss, it will request the assistance of userspace to do the translation, this is done through: - Fill the translation request in a preset userspace address (This