On Fri, Jul 26, 2024 at 1:15 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Fri, Jul 26, 2024 at 10:47:59AM +0800, Jason Wang wrote: > > On Wed, Jul 24, 2024 at 11:45 AM Srivatsa Vaddagiri > > <quic_svaddagi@xxxxxxxxxxx> wrote: > > > > > > Currently vduse does not seem to support configuration space writes > > > (vduse_vdpa_set_config does nothing). Is there any plan to lift that > > > limitation? I am aware of the discussions that took place here: > > > > > > https://patchwork.kernel.org/project/netdevbpf/patch/20210615141331.407-11-xieyongji@xxxxxxxxxxxxx/ > > > > > > Perhaps writes can be supported *selectively* without violating safety concerns > > > expressed in the above email discussion? > > > > Adding more relevant people here. > > > > It can probably be done case by case. The main reason for avoiding > > config writing is > > > > 1) to prevent buggy/malicious userspace from hanging kernel driver for ever > > 2) to prevent buggy/malicious userspace device to break the semantic > > > > Basically, it is the traditional trust model where the kernel doesn't > > trust userspace. > > > > E.g current virtio-blk has the following codes: > > > > tatic ssize_t > > cache_type_store(struct device *dev, struct device_attribute *attr, > > const char *buf, size_t count) > > { > > struct gendisk *disk = dev_to_disk(dev); > > struct virtio_blk *vblk = disk->private_data; > > struct virtio_device *vdev = vblk->vdev; > > int i; > > > > BUG_ON(!virtio_has_feature(vblk->vdev, VIRTIO_BLK_F_CONFIG_WCE)); > > i = sysfs_match_string(virtblk_cache_types, buf); > > if (i < 0) > > return i; > > > > virtio_cwrite8(vdev, offsetof(struct virtio_blk_config, wce), i); > > virtblk_update_cache_mode(vdev); > > return count; > > } > > To be fair, I think if you allow a block device in userspace you have already > allowed said userspace to crash the kernel unless you have > also restricted the filesystems mounted on this device to FUSE. I'm not sure I will get here, I think the kernel should be able to survive from the buggy device no matter if it is a real one or something emulated in the userspace? And if we can manage to do that, we should have an extra safe layer (e.g we've agreed that we need to use shadow cvq for VDUSE networking devices). THanks > > -- > MST >
