On Mon, Aug 23, 2021 at 6:45 PM Max Gurtovoy [off-list ref] wrote:

On 8/23/2021 1:33 PM, Yongji Xie wrote:

quoted

On Mon, Aug 23, 2021 at 5:38 PM Max Gurtovoy [off-list ref] wrote:

quoted

On 8/23/2021 12:27 PM, Yongji Xie wrote:

quoted

On Mon, Aug 23, 2021 at 5:04 PM Max Gurtovoy [off-list ref] wrote:

quoted

On 8/23/2021 11:35 AM, Yongji Xie wrote:

quoted

On Mon, Aug 23, 2021 at 4:07 PM Max Gurtovoy [off-list ref] wrote:

quoted

On 8/23/2021 7:31 AM, Yongji Xie wrote:

quoted

On Mon, Aug 23, 2021 at 7:17 AM Max Gurtovoy [off-list ref] wrote:

quoted

On 8/9/2021 1:16 PM, Xie Yongji wrote:

quoted

An untrusted device might presents an invalid block size
in configuration space. This tries to add validation for it
in the validate callback and clear the VIRTIO_BLK_F_BLK_SIZE
feature bit if the value is out of the supported range.

This is not clear to me. What is untrusted device ? is it a buggy device ?

A buggy device, the devices in an encrypted VM, or a userspace device
created by VDUSE [1].

[1] https://lore.kernel.org/kvm/20210818120642.165-1-xieyongji@bytedance.com/ (local)

if it's a userspace device, why don't you fix its control path code
instead of adding workarounds in the kernel driver ?

VDUSE kernel module would not touch (be aware of) the device specific
configuration space. It should be more reasonable to fix it in the
device driver. There is also some existing interface (.validate()) for
doing that.

who is emulating the device configuration space ?

A userspace daemon will initialize the device configuration space and
pass the contents to the VDUSE kernel module. The VDUSE kernel module
will handle the access of the config space from the virtio device
driver, but it doesn't need to know the contents (although we can know
that).

So you add a workaround in the guest kernel drivers instead of checking
these quirks in the hypervisor ?

I didn't see any problem adding this validation in the device driver.

quoted

VDUSE kernel should enforce the security for the devices it
emulates/presents to the VM.

I agree that the VDUSE kernel should enforce the security for the
emulated devices. But I still think the virtio device driver should
handle this case since nobody can make sure the device can always set
the correct value. Adding this validation would be helpful.

It helpful if there is a justification for this.

In this case, no such HW device exist and the only device that can cause
this trouble today is user space VDUSE device that must be validated by
the emulation VDUSE kernel driver.

Otherwise, will can create 1000 commit like this in the virtio level
(for example for each feature for each virtio device).

Maybe not. Most of the configuration fields have already been
validated at the virtio level.

quoted

quoted

quoted

quoted

quoted

And regardless of userspace device, we still need to fix it for other cases.

which cases ? Do you know that there is a buggy HW we need to workaround ?

No, there isn't now. But this could be a potential attack surface if
the host doesn't trust the device.

If the host doesn't trust a device, why it continues using it ?

IIUC this is the case for the encrypted VMs.

what do you mean encrypted VM ?

The guest memory is encrypted, the host can not read or write any
guest memory not explicitly shared with it. In this case, the guest
doesn't trust the host. There are already some efforts [1] [2] to
protect this kind of guest from untrusted devices.

[1] https://lwn.net/ml/linux-kernel/20210421032117.5177-1-jasowang@redhat.com/
[2] https://www.spinics.net/lists/linux-virtualization/msg50182.html

And how this small patch causes a VM to be 100% encryption supported ?

I'm not sure if there will be some ways to leak data in an encrypted
VM with the invalid block size.

Thanks,
Yongji