On 8/24/2021 3:52 PM, Yongji Xie wrote:
On Tue, Aug 24, 2021 at 6:11 PM Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote:
On 8/24/2021 5:47 AM, Jason Wang wrote:
On Tue, Aug 24, 2021 at 6:31 AM Max Gurtovoy <mgurtovoy@xxxxxxxxxx> wrote:
On 8/23/2021 3:13 PM, Michael S. Tsirkin wrote:
On Mon, Aug 23, 2021 at 01:45:31PM +0300, Max Gurtovoy wrote:
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).
Yea, it's a lot of work but I don't think it's avoidable.
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 ?
And how this small patch causes a VM to be 100% encryption supported ?
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?
The check should be in different layer.
Virtio blk driver should not cover on some strange VDUSE stuff.
Yes I'm not convinced VDUSE is a valid use-case. I think that for
security and robustness it should validate data it gets from userspace
right there after reading it.
But I think this is useful for the virtio hardening thing.
https://lwn.net/Articles/865216/
I don't see how this change is assisting confidential computing.
Confidential computingtalks about encrypting guest memory from the host,
and not adding some quirks to devices.
In the case of confidential computing, the hypervisor and hard device
is not in the trust zone. It means the guest doesn't trust the cloud
vendor.
Confidential computing protects data during processing ("in-use" data).
Nothing to do with virtio feature negotiation.
But if a misbehaving device can corrupt the guest memory, I think it
should be avoided.
So don't say it's related to confidential computing, and fix it in the
VDUSE kernel driver in the hypervisor.
If this is existing device and we want to add a quirk to it, so be it.
But it's not the case.
Thanks,
Yongji
