[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240802090040.GB12343@redhat.com>
Date: Fri, 2 Aug 2024 11:00:40 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Jeff Xu <jeffxu@...omium.org>
Cc: Kees Cook <keescook@...omium.org>, srikar@...ux.vnet.ibm.com,
Ryan Roberts <ryan.roberts@....com>,
"adrian.hunter@...el.com" <adrian.hunter@...el.com>,
"glider@...gle.com" <glider@...gle.com>,
Matthew Wilcox <willy@...radead.org>, zokeefe@...gle.com,
hughd@...gle.com, luto@...capital.net,
"jmarchan@...hat.com" <jmarchan@...hat.com>,
"rientjes@...gle.com" <rientjes@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: question on [uprobes] special vma
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.
Powered by blists - more mailing lists