On 7/18/2024 3:39 PM, Michael S. Tsirkin wrote:
On Thu, Jul 18, 2024 at 08:45:31AM +0800, Jason Wang wrote:
For example:
1) old owner pass fd to new owner which is another process
2) the new owner do VHOST_NEW_OWNER
3) new owner doesn't do remap correctly
There's no way for the old owner to remove/unpin the mappings as we
have the owner check in IOTLB_UPDATE. Looks like a potential way for
DOS.
This is a bug in the second cooperating process, not a DOS. The application
must fix it. Sometimes you cannot recover from an application bug at run time.
BTW, at one time vfio enforced the concept of an owner, but Alex deleted it.
It adds no value, because possession of the fd is the key.
ffed0518d871 ("vfio: remove useless judgement")
This seems to be a great relaxation of the ownership check. I would
like to hear from Michael first.
Thanks
It could be that the ownership model is too restrictive.
But again, this is changing a security assumption.
Looks like yes another reason to tie this to the switch to iommufd.
iommufd, like vfio, does not impose an ownership requirement. If vdpa has a
stricter requirement, such as allowing the vhost-net sharing that Jason
described, then we need to surface that now, and extend it to allow change
of ownership for live update.
Is the vhost-net scenario currently used, or aspirational?
Copying from Jason's email:
1) Two processes (A and B) share a part of the memory
2) A is the owner of the vhost-net who is in charge of building memory
mappings via IOTLB
3) A passes vhost-net fd to process B
- Steve
