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
| ||
|
Message-ID: <CAKMK7uFYDSqnNp_xpohzCEidw_iLufNSoX4v55sNZj-nwTckSg@mail.gmail.com> Date: Sun, 1 Nov 2020 11:30:49 +0100 From: Daniel Vetter <daniel.vetter@...ll.ch> To: John Hubbard <jhubbard@...dia.com> Cc: DRI Development <dri-devel@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>, KVM list <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>, Daniel Vetter <daniel.vetter@...el.com>, Jason Gunthorpe <jgg@...pe.ca>, Pawel Osciak <pawel@...iak.com>, Marek Szyprowski <m.szyprowski@...sung.com>, Kyungmin Park <kyungmin.park@...sung.com>, Tomasz Figa <tfiga@...omium.org>, Mauro Carvalho Chehab <mchehab@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, Jérôme Glisse <jglisse@...hat.com>, Jan Kara <jack@...e.cz>, Dan Williams <dan.j.williams@...el.com> Subject: Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM On Sun, Nov 1, 2020 at 6:22 AM John Hubbard <jhubbard@...dia.com> wrote: > > On 10/31/20 7:45 AM, Daniel Vetter wrote: > > On Sat, Oct 31, 2020 at 3:55 AM John Hubbard <jhubbard@...dia.com> wrote: > >> On 10/30/20 3:08 AM, Daniel Vetter wrote: > ... > >> By removing this check from this location, and changing from > >> pin_user_pages_locked() to pin_user_pages_fast(), I *think* we end up > >> losing the check entirely. Is that intended? If so it could use a comment > >> somewhere to explain why. > > > > Yeah this wasn't intentional. I think I needed to drop the _locked > > version to prep for FOLL_LONGTERM, and figured _fast is always better. > > But I didn't realize that _fast doesn't have the vma checks, gup.c got > > me a bit confused. > > Actually, I thought that the change to _fast was a very nice touch, btw. > > > > > I'll remedy this in all the patches where this applies (because a > > VM_IO | VM_PFNMAP can point at struct page backed memory, and that > > exact use-case is what we want to stop with the unsafe_follow_pfn work > > since it wreaks things like cma or security). > > > > Aside: I do wonder whether the lack for that check isn't a problem. > > VM_IO | VM_PFNMAP generally means driver managed, which means the > > driver isn't going to consult the page pin count or anything like that > > (at least not necessarily) when revoking or moving that memory, since > > we're assuming it's totally under driver control. So if pup_fast can > > get into such a mapping, we might have a problem. > > -Daniel > > > > Yes. I don't know why that check is missing from the _fast path. > Probably just an oversight, seeing as how it's in the slow path. Maybe > the appropriate response here is to add a separate patch that adds the > check. > > I wonder if I'm overlooking something, but it certainly seems correct to > do that. You'll need the mmap_sem to get at the vma to be able to do this check. If you add that to _fast, you made it as fast as the slow one. Plus there's _fast_only due to locking recurion issues in fast-paths (I assume, I didn't check all the callers). I'm just wondering whether we have a bug somewhere with device drivers. For CMA regions we always check in try_grab_page, but for dax I'm not seeing where the checks in the _fast fastpaths are, and that all still leaves random device driver mappings behind which aren't backed by CMA but still point to something with a struct page behind it. I'm probably just missing something, but no idea what. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Powered by blists - more mailing lists