* question on [uprobes] special vma
@ 2024-08-01 23:38 Jeff Xu
2024-08-02 9:00 ` Oleg Nesterov
0 siblings, 1 reply; 4+ messages in thread
From: Jeff Xu @ 2024-08-01 23:38 UTC (permalink / raw)
To: Kees Cook, srikar, Ryan Roberts, adrian.hunter, glider,
Matthew Wilcox, zokeefe, hughd, luto, oleg, jmarchan, rientjes,
Thomas Gleixner, Ingo Molnar
Cc: LKML, linux-mm, Andrew Morton
Hi
__create_xol_area() calls _install_special_mapping() to create a vma
named [uprobes].
I'm trying to find out the lifetime of this uprobes vma, e.g. when it
is created, will it ever be unmapped/remapped/changed during the
lifetime of the process.
If the uprobes vma remains the same during the lifetime of the
process, I can call mseal on it so user space can't change it, i.e.
blocking munmap/mremap/mprotect/mmap, etc.
Thanks
Best regards
-Jeff
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: question on [uprobes] special vma
2024-08-01 23:38 question on [uprobes] special vma Jeff Xu
@ 2024-08-02 9:00 ` Oleg Nesterov
2024-08-02 14:59 ` Jeff Xu
0 siblings, 1 reply; 4+ messages in thread
From: Oleg Nesterov @ 2024-08-02 9:00 UTC (permalink / raw)
To: Jeff Xu
Cc: Kees Cook, srikar, Ryan Roberts, adrian.hunter, glider,
Matthew Wilcox, zokeefe, hughd, luto, jmarchan, rientjes,
Thomas Gleixner, Ingo Molnar, LKML, linux-mm, Andrew Morton
Hi Jeff,
On 08/01, Jeff Xu wrote:
>
> __create_xol_area() calls _install_special_mapping() to create a vma
> named [uprobes].
>
> I'm trying to find out the lifetime of this uprobes vma, e.g. when it
> is created, will it ever be unmapped/remapped/changed during the
> lifetime of the process.
>
> If the uprobes vma remains the same during the lifetime of the
> process,
Yes,
> I can call mseal on it so user space can't change it, i.e.
> blocking munmap/mremap/mprotect/mmap, etc.
I didn't even know about mm/mseal.c...
at first glance do_mseal() just adds VM_SEALED for can_modify_vma().
So it seems that xol_add_vma() can just pass the additional VM_SEALED
flag to _install_special_mapping(), no?
But why it depends on CONFIG_64_BIT?
Oleg.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: question on [uprobes] special vma
2024-08-02 9:00 ` Oleg Nesterov
@ 2024-08-02 14:59 ` Jeff Xu
2024-08-02 22:21 ` Oleg Nesterov
0 siblings, 1 reply; 4+ messages in thread
From: Jeff Xu @ 2024-08-02 14:59 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Kees Cook, srikar, Ryan Roberts, adrian.hunter, glider,
Matthew Wilcox, zokeefe, hughd, luto, jmarchan, rientjes,
Thomas Gleixner, Ingo Molnar, LKML, linux-mm, Andrew Morton
Hi Oleg
On Fri, Aug 2, 2024 at 2:00 AM Oleg Nesterov <oleg@redhat.com> wrote:
>
> Hi Jeff,
>
> On 08/01, Jeff Xu wrote:
> >
> > __create_xol_area() calls _install_special_mapping() to create a vma
> > named [uprobes].
> >
> > I'm trying to find out the lifetime of this uprobes vma, e.g. when it
> > is created, will it ever be unmapped/remapped/changed during the
> > lifetime of the process.
> >
> > If the uprobes vma remains the same during the lifetime of the
> > process,
>
> Yes,
>
That is nice.
> > I can call mseal on it so user space can't change it, i.e.
> > blocking munmap/mremap/mprotect/mmap, etc.
>
> I didn't even know about mm/mseal.c...
>
The TLDR: once the memory area is sealed,
mmap/munmap/mremap/mprotect/some of madvise will be blocked.
https://docs.kernel.org/userspace-api/mseal.html
On a related topic, Adhemerval Zanella has an RFC adding mseal support
for dynamic linker.
https://public-inbox.org/libc-alpha/20240731200307.2269811-1-adhemerval.zanella@linaro.org/
> at first glance do_mseal() just adds VM_SEALED for can_modify_vma().
>
> So it seems that xol_add_vma() can just pass the additional VM_SEALED
> flag to _install_special_mapping(), no?
>
Yes. Before I make that change, I want to confirm that [uprobes] VMA
is immutable during the lifetime of the process, hence this email.
> But why it depends on CONFIG_64_BIT?
>
It needn't, but the vm_flags_t in the vma struct for 32 bit is full,
adding 32 bit support will make split/merge code more complex, (at one
point of RFC process, 32 bit is included but later removed),
If we like to have 32 bit support, perhaps we need to refactor the mm
code to expand vm_flags first.
Thanks for your help !
-Jeff
> Oleg.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: question on [uprobes] special vma
2024-08-02 14:59 ` Jeff Xu
@ 2024-08-02 22:21 ` Oleg Nesterov
0 siblings, 0 replies; 4+ messages in thread
From: Oleg Nesterov @ 2024-08-02 22:21 UTC (permalink / raw)
To: Jeff Xu
Cc: Kees Cook, srikar, Ryan Roberts, adrian.hunter, glider,
Matthew Wilcox, zokeefe, hughd, luto, jmarchan, rientjes,
Thomas Gleixner, Ingo Molnar, LKML, linux-mm, Andrew Morton
On 08/02, Jeff Xu wrote:
>
> > So it seems that xol_add_vma() can just pass the additional VM_SEALED
> > flag to _install_special_mapping(), no?
> >
> Yes. Before I make that change, I want to confirm that [uprobes] VMA
> is immutable during the lifetime of the process, hence this email.
OK, thanks,
> > But why it depends on CONFIG_64_BIT?
> >
> It needn't, but the vm_flags_t in the vma struct for 32 bit is full,
Ah, indeed ;)
Thanks!
Oleg.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-08-02 22:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-01 23:38 question on [uprobes] special vma Jeff Xu
2024-08-02 9:00 ` Oleg Nesterov
2024-08-02 14:59 ` Jeff Xu
2024-08-02 22:21 ` Oleg Nesterov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox