linux-kernel - Re: [PATCH V2 5/7] vhost-vdpa: VHOST_IOTLB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACGkMEuUBbTADGL8dVHZ+J=-5d8Kkye2xHHNCwjzLnwAPz6dBA@mail.gmail.com>
Date: Fri, 19 Jul 2024 09:01:30 +0800
From: Jason Wang <jasowang@...hat.com>
To: Steven Sistare <steven.sistare@...cle.com>
Cc: "Michael S. Tsirkin" <mst@...hat.com>, virtualization@...ts.linux-foundation.org, 
	linux-kernel@...r.kernel.org, Si-Wei Liu <si-wei.liu@...cle.com>, 
	Eugenio Perez Martin <eperezma@...hat.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, 
	Dragos Tatulea <dtatulea@...dia.com>, Alex Williamson <alex.williamson@...hat.com>
Subject: Re: [PATCH V2 5/7] vhost-vdpa: VHOST_IOTLB_REMAP

On Fri, Jul 19, 2024 at 4:19 AM Steven Sistare
<steven.sistare@...cle.com> wrote:
>
> 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?

This question is very hard. But for my understanding, what Michael meant is:

1) the current proposal changes the security assumption
2) iommufd require uAPI changes which may imply security assumption
changes or other user space noticeable behaviour changes

My understanding is:

If we want to go without iommufd, we may need to find a way to stick
to the assumption (not sure how hard it is). If we want to go with
iommufd, we probably won't worry about that, as you've pointed out,
there's no ownership requirement.

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

Thanks