On 11/10/23 8:23 PM, Jason Gunthorpe wrote: > On Fri, Nov 10, 2023 at 08:19:23PM +0530, Aneesh Kumar K.V wrote: >> >> Hello, >> >> Some architectures can now support EXEC_ONLY mappings and I am wondering >> what get_user_pages() on those addresses should return. > > -EPERM > >> Earlier PROT_EXEC implied PROT_READ and pte_access_permitted() >> returned true for that. But arm64 does have this explicit comment >> that says >> >> /* >> * p??_access_permitted() is true for valid user mappings (PTE_USER >> * bit set, subject to the write permission check). For execute-only >> * mappings, like PROT_EXEC with EPAN (both PTE_USER and PTE_UXN bits >> * not set) must return false. PROT_NONE mappings do not have the >> * PTE_VALID bit set. >> */ >> >> Is that correct? We should be able to get struct page for PROT_EXEC >> mappings? > > If the memory is unreadable then providing a back door through > O_DIRECT and everthing else to read it sounds wrong to me. > > If there is some case where a get_user_pages caller is exec-only > compatible then a new FOLL_EXEC flag to permit it would make sense. >
I was expecting pin_user_pages() to return -EPERM and get_user_pages() return struct page. This was based on Documentation/core-api/pin_user_pages.rst "Another way of thinking about these flags is as a progression of restrictions: FOLL_GET is for struct page manipulation, without affecting the data that the struct page refers to. FOLL_PIN is a *replacement* for FOLL_GET, and is for short term pins on pages whose data *will* get accessed. " May be we can clarify PROT_EXEC details in the documentation? -aneesh
