Messages in this thread | | | Date | Fri, 21 Apr 2023 11:01:26 +0200 | From | Jan Kara <> | Subject | Re: [RFC PATCH 0/3] permit write-sealed memfd read-only shared mappings |
| |
Hi!
On Mon 03-04-23 23:28:29, Lorenzo Stoakes wrote: > This patch series is in two parts:- > > 1. Currently there are a number of places in the kernel where we assume > VM_SHARED implies that a mapping is writable. Let's be slightly less > strict and relax this restriction in the case that VM_MAYWRITE is not > set. > > This should have no noticeable impact as the lack of VM_MAYWRITE implies > that the mapping can not be made writable via mprotect() or any other > means. > > 2. Align the behaviour of F_SEAL_WRITE and F_SEAL_FUTURE_WRITE on mmap(). > The latter already clears the VM_MAYWRITE flag for a sealed read-only > mapping, we simply extend this to F_SEAL_WRITE too. > > For this to have effect, we must also invoke call_mmap() before > mapping_map_writable(). > > As this is quite a fundamental change on the assumptions around VM_SHARED > and since this causes a visible change to userland (in permitting read-only > shared mappings on F_SEAL_WRITE mappings), I am putting forward as an RFC > to see if there is anything terribly wrong with it.
So what I miss in this series is what the motivation is. Is it that you need to map F_SEAL_WRITE read-only? Why?
Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR
| |