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. -- MST
