On Mon, Aug 23, 2021 at 5:38 PM Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote:
I didn't see any problem adding this validation in the device driver.
On 8/23/2021 12:27 PM, Yongji Xie wrote:
On Mon, Aug 23, 2021 at 5:04 PM Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote:So you add a workaround in the guest kernel drivers instead of checking
On 8/23/2021 11:35 AM, Yongji Xie wrote:A userspace daemon will initialize the device configuration space and
On Mon, Aug 23, 2021 at 4:07 PM Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote:who is emulating the device configuration space ?
On 8/23/2021 7:31 AM, Yongji Xie wrote:VDUSE kernel module would not touch (be aware of) the device specific
On Mon, Aug 23, 2021 at 7:17 AM Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote:if it's a userspace device, why don't you fix its control path code
On 8/9/2021 1:16 PM, Xie Yongji wrote:A buggy device, the devices in an encrypted VM, or a userspace device
An untrusted device might presents an invalid block sizeThis is not clear to me. What is untrusted device ? is it a buggy device ?
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.
created by VDUSE [1].
[1] https://lore.kernel.org/kvm/20210818120642.165-1-xieyongji@xxxxxxxxxxxxx/
instead of adding workarounds in the kernel driver ?
configuration space. It should be more reasonable to fix it in the
device driver. There is also some existing interface (.validate()) for
doing that.
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).
these quirks in the hypervisor ?
VDUSE kernel should enforce the security for the devices itI agree that the VDUSE kernel should enforce the security for the
emulates/presents to the VM.
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.
IIUC this is the case for the encrypted VMs.If the host doesn't trust a device, why it continues using it ?No, there isn't now. But this could be a potential attack surface ifAnd 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 ?
the host doesn't trust the device.
Do you suggest we do these workarounds in all device drivers in the kernel ?Isn't it the driver's job to validate some unreasonable configuration?
Thanks,
Yongji