[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202502241703.10E2F5926F@keescook>
Date: Mon, 24 Feb 2025 17:03:41 -0800
From: Kees Cook <kees@...nel.org>
To: jeffxu@...omium.org
Cc: akpm@...ux-foundation.org, jannh@...gle.com,
torvalds@...ux-foundation.org, vbabka@...e.cz,
lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
adhemerval.zanella@...aro.org, oleg@...hat.com, avagin@...il.com,
benjamin@...solutions.net, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org, linux-mm@...ck.org,
jorgelo@...omium.org, sroettger@...gle.com, hch@....de,
ojeda@...nel.org, thomas.weissschuh@...utronix.de,
adobriyan@...il.com, johannes@...solutions.net,
pedro.falcato@...il.com, hca@...ux.ibm.com, willy@...radead.org,
anna-maria@...utronix.de, mark.rutland@....com,
linus.walleij@...aro.org, Jason@...c4.com, deller@....de,
rdunlap@...radead.org, davem@...emloft.net, peterx@...hat.com,
f.fainelli@...il.com, gerg@...nel.org, dave.hansen@...ux.intel.com,
mingo@...nel.org, ardb@...nel.org, mhocko@...e.com,
42.hyeyoo@...il.com, peterz@...radead.org, ardb@...gle.com,
enh@...gle.com, rientjes@...gle.com, groeck@...omium.org,
mpe@...erman.id.au, aleksandr.mikhalitsyn@...onical.com,
mike.rapoport@...il.com
Subject: Re: [PATCH v7 3/7] mseal, system mappings: enable x86-64
On Mon, Feb 24, 2025 at 10:52:42PM +0000, jeffxu@...omium.org wrote:
> From: Jeff Xu <jeffxu@...omium.org>
>
> 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 <jeffxu@...omium.org>
> ---
> arch/x86/Kconfig | 1 +
> arch/x86/entry/vdso/vma.c | 16 ++++++++++------
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 87198d957e2f..8fa17032ca46 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -26,6 +26,7 @@ config X86_64
> depends on 64BIT
> # Options that are inherently 64-bit kernel only:
> select ARCH_HAS_GIGANTIC_PAGE
> + select ARCH_HAS_MSEAL_SYSTEM_MAPPINGS
> select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
> select ARCH_SUPPORTS_PER_VMA_LOCK
> select ARCH_SUPPORTS_HUGE_PFNMAP if TRANSPARENT_HUGEPAGE
> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
> index 39e6efc1a9ca..1b1c009f20a8 100644
> --- a/arch/x86/entry/vdso/vma.c
> +++ b/arch/x86/entry/vdso/vma.c
> @@ -247,6 +247,7 @@ static int map_vdso(const struct vdso_image *image, unsigned long addr)
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> unsigned long text_start;
> + unsigned long vm_flags;
> int ret = 0;
>
> if (mmap_write_lock_killable(mm))
> @@ -264,11 +265,12 @@ static int map_vdso(const struct vdso_image *image, unsigned long addr)
> /*
> * MAYWRITE to allow gdb to COW and set breakpoints
> */
> + vm_flags = VM_READ|VM_EXEC|VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC;
> + vm_flags |= VM_SEALED_SYSMAP;
> vma = _install_special_mapping(mm,
> text_start,
> image->size,
> - VM_READ|VM_EXEC|
> - VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
> + vm_flags,
> &vdso_mapping);
I think these (in all patches) were supposed to be reworked without the
"vm_flags" variable addition?
--
Kees Cook
Powered by blists - more mailing lists