[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201007184705.GY5177@ziepe.ca>
Date: Wed, 7 Oct 2020 15:47:05 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Daniel Vetter <daniel.vetter@...ll.ch>
Cc: DRI Development <dri-devel@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>, kvm@...r.kernel.org,
Linux MM <linux-mm@...ck.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@...r.kernel.org>, linux-s390@...r.kernel.org,
Daniel Vetter <daniel.vetter@...el.com>,
Kees Cook <keescook@...omium.org>,
Dan Williams <dan.j.williams@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
John Hubbard <jhubbard@...dia.com>,
Jérôme Glisse <jglisse@...hat.com>,
Jan Kara <jack@...e.cz>,
Alex Williamson <alex.williamson@...hat.com>,
Cornelia Huck <cohuck@...hat.com>
Subject: Re: [PATCH 13/13] vfio/type1: Mark follow_pfn as unsafe
On Wed, Oct 07, 2020 at 08:14:06PM +0200, Daniel Vetter wrote:
> Hm, but wouldn't need that the semi-nasty vma_open trick to make sure
> that vma doesn't untimely disappear? Or is the idea to look up the
> underlying vfio object, and refcount that directly?
Ah, the patches Alex was working on had the refcount I think, it does
need co-ordination across multiple VFIO instances IIRC.
At least a simple check would guarentee we only have exposed PCI BAR
pages which is not as bad security wise as the other stuff.
Jason
Powered by blists - more mailing lists