On Wed, Dec 13, 2017 at 10:08:30AM -0800, Linus Torvalds wrote: > On Wed, Dec 13, 2017 at 7:54 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > Which is why get_user_pages() _should_ enforce this. > > > > What use are protection keys if you can trivially circumvent them? > > No, we will *not* worry about protection keys in get_user_pages(). > > They are not "security". They are a debug aid and safety against random mis-use. > > In particular, they are very much *NOT* about "trivially circumvent > them". The user could just change their mapping thing, for chrissake! > > We already allow access to PROT_NONE for gdb and friends, very much on purpose. > > We're not going to make the VM more complex for something that > absolutely nobody cares about, and has zero security issues. OK, that might have been my phrasing that was off -- mostly because I was looking at it from the VM_NOUSER angle, but currently: - gup_pte_range() has pte_access_permitted() - follow_page_pte() has pte_access_permitted() for FOLL_WRITE only All I'm saying is that that is inconsistent and we should change follow_page_pte() to use pte_access_permitted() for FOLL_GET, such that __get_user_pages_fast() and __get_user_pages() have matching semantics. Now, if VM_NOUSER were to live, the above change would ensure write(2) cannot read from such VMAs, where the existing test for FOLL_WRITE already disallows read(2) from writing to them. But even without VM_NOUSER it makes the VM more consistent than it is today. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
