Messages in this thread | | | Date | Fri, 28 Apr 2023 17:43:52 +0200 | Subject | Re: [PATCH v5] mm/gup: disallow GUP writing to file-backed mappings by default | From | David Hildenbrand <> |
| |
On 28.04.23 17:34, David Hildenbrand wrote: > On 28.04.23 17:33, Lorenzo Stoakes wrote: >> On Fri, Apr 28, 2023 at 05:23:29PM +0200, David Hildenbrand wrote: >>>>> >>>>> Security is the primary case where we have historically closed uAPI >>>>> items. >>>> >>>> As this patch >>>> >>>> 1) Does not tackle GUP-fast >>>> 2) Does not take care of !FOLL_LONGTERM >>>> >>>> I am not convinced by the security argument in regard to this patch. >>>> >>>> >>>> If we want to sells this as a security thing, we have to block it >>>> *completely* and then CC stable. >>> >>> Regarding GUP-fast, to fix the issue there as well, I guess we could do >>> something similar as I did in gup_must_unshare(): >>> >>> If we're in GUP-fast (no VMA), and want to pin a !anon page writable, >>> fallback to ordinary GUP. IOW, if we don't know, better be safe. >> >> How do we determine it's non-anon in the first place? The check is on the >> VMA. We could do it by following page tables down to folio and checking >> folio->mapping for PAGE_MAPPING_ANON I suppose? > > PageAnon(page) can be called from GUP-fast after grabbing a reference. > See gup_must_unshare().
IIRC, PageHuge() can also be called from GUP-fast and could special-case hugetlb eventually, as it's table while we hold a (temporary) reference. Shmem might be not so easy ...
-- Thanks,
David / dhildenb
| |