sue since no caller sets a flag other
> than VM_EXEC.
>
> Cc: Andrew Morton
> Cc: Liam R. Howlett
> Cc: Yu Zhao
> Cc: linux...@kvack.org
> Fixes: 2e7ce7d354f2 ("mm/mmap: change do_brk_flags() to expand existing VMA
> and add do_brk_munmap()")
> Signed-off-by:
ng sum;
> struct vm_area_struct *vma;
>
> /* Check for overflow. */
With your nice self-documenting code, you can probably drop that
comment.
With or without the change,
Reviewed-by: Liam R. Howlett
> - if (addr + len < addr)
> +
* Jeff Xu [241008 11:01]:
> Hi Liam,
>
> On Mon, Oct 7, 2024 at 7:19 PM Liam R. Howlett
> wrote:
> >
> > * jef...@chromium.org [241004 12:32]:
> > > From: Jeff Xu
> > >
> > > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> > >
&
* jef...@chromium.org [241004 12:32]:
> From: Jeff Xu
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing during the life time of the process.
>
> System mappings such as vdso, vvar, and sigpage (
* jef...@chromium.org [241014 17:50]:
> From: Jeff Xu
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing during the life time of the process. For
> complete descriptions of memory sealing, please
* jef...@chromium.org [241014 17:50]:
> From: Jeff Xu
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing during the life time of the process. For
> complete descriptions of memory sealing, please
* Jeff Xu [24 14:10]:
> Hi Liam
>
> On Thu, Oct 17, 2024 at 9:01 AM Liam R. Howlett
> wrote:
>
> > > > Does it make sense for this to live in exec? Couldn't you put it in the
> > > > mm/mseal.c file? It's vma flags for mappings and you&#
> On Wed, Oct 16, 2024 at 6:10 PM Liam R. Howlett
> wrote:
...
> > > diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c
> > > b/arch/x86/entry/vsyscall/vsyscall_64.c
> > > index 2fb7d53cf333..20a3000550d2 100644
> > > --- a/arch/x86/entry/vsyscal
* Jeff Xu [241016 20:59]:
> On Wed, Oct 16, 2024 at 4:18 PM Liam R. Howlett
> wrote:
> >
> > * jef...@chromium.org [241014 17:50]:
> > > From: Jeff Xu
> > >
> > > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> > >
> > > Thos
* jef...@chromium.org [241113 14:16]:
> From: Jeff Xu
Thanks, this looks much better. Some minor things below.
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped during the life tim
* jef...@chromium.org [241205 20:39]:
> From: Jeff Xu
>
> No code logic change.
>
> can_do_mseal is called exclusively by mseal.c,
> and mseal.c is compiled only when CONFIG_64BIT flag is
> set in makefile. Therefore, it is unnecessary to have
> 32 bit stub function in the header file.
There i
* Kees Cook [241217 17:19]:
> On Mon, Nov 25, 2024 at 08:20:21PM +, jef...@chromium.org wrote:
> > Seal vdso, vvar, sigpage, uprobes and vsyscall.
> >
> > Those mappings are readonly or executable only, sealing can protect
> > them from ever changing or unmapped during the life time of the pr
* jef...@chromium.org [250211 22:22]:
> From: Jeff Xu
>
> Provide infrastructure to mseal system mappings. Establish
> two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
> ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and a header file (userprocess.h)
> for future patches.
>
> As discussed during mseal() upst
* Jeff Xu [241216 13:35]:
...
> >
> > I like the idea and I think the opt-out solution should work for CRIU.
> > CRIU will be able to call this prctl and re-execute itself.
> >
> Great! Let's iterate on the opt-out solution then.
>
This patch set has been NACK'ed.
Please rework your solution
* enh [250121 10:38]:
> On Fri, Jan 17, 2025 at 5:08 PM Liam R. Howlett
> wrote:
> >
> > * enh [250117 14:35]:
> > ...
> >
> > >
> > > as a maintainer of a different linux libc, i've long wanted a "tell me
> > > everything t
* enh [250117 14:35]:
...
>
> as a maintainer of a different linux libc, i've long wanted a "tell me
> everything there is to know about this vma" syscall rather than having
> to parse /proc/maps...
>
You mean an ioctl()-based API to query VMAs from /proc//maps?
Andrii had something like that
* Liam R. Howlett [250213 19:14]:
> * Jeff Xu [250213 17:00]:
> > On Thu, Feb 13, 2025 at 12:54 PM Liam R. Howlett
> > wrote:
> >
> > > > > >
> > > > > > VM_SEALED isn't defined in 32-bit systems, and mseal.c isn't part of
&g
* Jeff Xu [250213 12:17]:
> On Wed, Feb 12, 2025 at 7:05 AM Liam R. Howlett
> wrote:
> >
> ...
> > >
> > > In this version, we've improved the handling of system mapping sealing
> > > from
> > > previous versions, instead of modifying t
* Kees Cook [250212 17:05]:
> On Wed, Feb 12, 2025 at 11:24:35AM +, Lorenzo Stoakes wrote:
> > On Wed, Feb 12, 2025 at 03:21:48AM +, jef...@chromium.org wrote:
> > > From: Jeff Xu
> > >
> > > The commit message in the first patch contains the full description of
> > > this series.
> >
>
* Kees Cook [250213 14:34]:
>
>
> On February 13, 2025 10:35:21 AM PST, "Liam R. Howlett"
> wrote:
> >* Kees Cook [250212 17:05]:
> >> On Wed, Feb 12, 2025 at 11:24:35AM +, Lorenzo Stoakes wrote:
> >> > On Wed, Feb 12, 2025 at 03:21:48A
* Kees Cook [250213 15:11]:
> On Thu, Feb 13, 2025 at 01:29:46PM -0500, Liam R. Howlett wrote:
> > * Jeff Xu [250213 12:17]:
> > > On Wed, Feb 12, 2025 at 7:05 AM Liam R. Howlett
> > > wrote:
> > > >
> > > ...
> > > > >
> >
* Jeff Xu [250213 17:00]:
> On Thu, Feb 13, 2025 at 12:54 PM Liam R. Howlett
> wrote:
>
> > > > >
> > > > > VM_SEALED isn't defined in 32-bit systems, and mseal.c isn't part of
> > > > > the build. This is intentional. Any
* Kees Cook [250224 13:55]:
> On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > On 2/24/25 10:44, Jeff Xu wrote:
> > > For example:
> > > Consider the case below in src/third_party/kernel/v6.6/fs/proc/task_mmu.c,
> > >
> > > #ifdef CONFIG_64BIT
> > > [ilog2(VM_SEALED)] = "sl",
> >
* Jeff Xu [250224 14:07]:
...
> > >
> > > #ifdef CONFIG_64BIT
> > > [ilog2(VM_SEALED)] = "sl",
> > > #endif
> > >
> > > Redefining VM_SEALED to VM_NONE for 32 bit won't detect the problem
> > > in case that "#ifdef CONFIG_64BIT" line is missing.
> >
> > I don't think it is reasonable to insist
* Jeff Xu [250224 14:42]:
> On Mon, Feb 24, 2025 at 11:25 AM Kees Cook wrote:
> >
> > On Mon, Feb 24, 2025 at 11:10:22AM -0800, Jeff Xu wrote:
> > > On Mon, Feb 24, 2025 at 11:03 AM Liam R. Howlett
> > > wrote:
> > > >
> > > > * Jeff
* jef...@chromium.org [250224 12:45]:
> From: Jeff Xu
>
> Add code to detect if the vdso is memory sealed, skip the test
> if it is.
It also skips the test if fopen fails on smaps, but maybe that's super
rare?
>
> Signed-off-by: Jeff Xu
> ---
> .../testing/selftests/x86/test_mremap_vdso.c
* jef...@chromium.org [250224 12:45]:
> From: Jeff Xu
>
> Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64,
> covering the vdso, vvar, vvar_vclock.
>
> Production release testing passes on Android and Chrome OS.
>
> Signed-off-by: Jeff Xu
> ---
> arch/x86/Kconfig | 1 +
>
* Jeff Xu [250224 14:23]:
> On Mon, Feb 24, 2025 at 11:11 AM Liam R. Howlett
> wrote:
> >
> > * Kees Cook [250224 13:55]:
> > > On Mon, Feb 24, 2025 at 10:52:13AM -0800, Dave Hansen wrote:
> > > > On 2/24/25 10:44, Jeff Xu wrote:
> > > >
* Jeff Xu [250224 13:44]:
> On Mon, Feb 24, 2025 at 10:21 AM Dave Hansen wrote:
> >
> > On 2/24/25 09:45, jef...@chromium.org wrote:
> > > +/*
> > > + * mseal of userspace process's system mappings.
> > > + */
> > > +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS
> > > +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAG
* jef...@chromium.org [250224 12:45]:
> From: Jeff Xu
>
> Update memory sealing documentation to include details about system
> mappings.
>
> Signed-off-by: Jeff Xu
> ---
> Documentation/userspace-api/mseal.rst | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/use
* Jeff Xu [250224 14:40]:
> On Mon, Feb 24, 2025 at 11:18 AM Liam R. Howlett
> wrote:
> >
> > Also, do we need something like the above test for VM_SEALED_SYS?
> >
> Do you mean adding selftest for sealing vdso ? or test the
> VM_SEALED_
* Lorenzo Stoakes [250226 13:06]:
> On Wed, Feb 26, 2025 at 07:01:36PM +0100, Oleg Nesterov wrote:
> > On 02/26, Lorenzo Stoakes wrote:
> > >
> > > On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote:
> > > > On 02/24, jef...@chromium.org wrote:
> > > > >
> > > > > Unlike other system ma
* Lorenzo Stoakes [250226 00:26]:
> On Tue, Feb 25, 2025 at 02:26:50PM -0800, Jeff Xu wrote:
> > On Mon, Feb 24, 2025 at 10:20 PM Lorenzo Stoakes
> > wrote:
> > >
> > > On Mon, Feb 24, 2025 at 10:52:43PM +, jef...@chromium.org wrote:
> > > > From: Jeff Xu
> > > >
> > > > Provide support for
* jef...@chromium.org [250224 17:52]:
> From: Jeff Xu
>
> Provide infrastructure to mseal system mappings. Establish
> two kernel configs (CONFIG_MSEAL_SYSTEM_MAPPINGS,
> ARCH_HAS_MSEAL_SYSTEM_MAPPINGS) and VM_SEALED_SYSMAP
> macro for future patches.
>
> Signed-off-by: Jeff Xu
> ---
> includ
* jef...@chromium.org [250303 00:09]:
> From: Jeff Xu
>
> Update memory sealing documentation to include details about system
> mappings.
>
> Signed-off-by: Jeff Xu
> Reviewed-by: Kees Cook
Reviewed-by: Liam R. Howlett
> ---
> Documentation/u
e. It could be sealed from creation.
>
> Test was done with perf tool, and observe the uprobe mapping is sealed.
>
> Signed-off-by: Jeff Xu
Reviewed-by: Liam R. Howlett
> ---
> kernel/events/uprobes.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --gi
f-by: Jeff Xu
Reviewed-by: Liam R. Howlett
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/vdso.c | 12
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 940343beb3d4..282d6cb13cfb 1
> V8:
> - Change ARCH_SUPPORTS_MSEAL_X to ARCH_SUPPORTS_MSEAL_X (Liam R. Howlett)
It looks like this was captured wrong in just this update. Change
ARCH_HAS => ARCH_SUPPORTS. Code looks correct.
Kees also ran down the meaning of the two more than I did, so thanks
again Kees!
> -
* jef...@chromium.org [250303 00:09]:
> From: Jeff Xu
>
> Add code to detect if the vdso is memory sealed, skip the test
> if it is.
>
> Signed-off-by: Jeff Xu
> Reviewed-by: Kees Cook
> Reviewed-by: Lorenzo Stoakes
Reviewed-by: Liam R. Howlett
> ---
&
ch cleaner.
Reviewed-by: Liam R. Howlett
> ---
> arch/x86/Kconfig | 1 +
> arch/x86/entry/vdso/vma.c | 7 ---
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index be2c311f5118..c6f9ebcbe009 100644
>
f-by: Jeff Xu
Reviewed-by: Liam R. Howlett
> ---
> include/linux/mm.h | 10 ++
> init/Kconfig | 22 ++
> security/Kconfig | 21 +
> 3 files changed, 53 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/
41 matches
Mail list logo
