| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20250226082701-9057b348-b074-488f-9aca-49ffbc78237f@linutronix.de>
Date: Wed, 26 Feb 2025 08:35:05 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Jeff Xu <jeffxu@...omium.org>
Cc: akpm@...ux-foundation.org, keescook@...omium.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, 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 Tue, Feb 25, 2025 at 04:48:47PM -0800, Jeff Xu wrote:
> On Tue, Feb 25, 2025 at 12:08 AM Thomas Weißschuh
> <thomas.weissschuh@...utronix.de> wrote:
> > 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);
> > >
> > > if (IS_ERR(vma)) {
> > > @@ -276,11 +278,12 @@ static int map_vdso(const struct vdso_image *image, unsigned long addr)
> > > goto up_fail;
> > > }
> > >
> > > + vm_flags = VM_READ|VM_MAYREAD|VM_IO|VM_DONTDUMP|VM_PFNMAP;
> > > + vm_flags |= VM_SEALED_SYSMAP;
> > > vma = _install_special_mapping(mm,
> > > addr,
> > > (__VVAR_PAGES - VDSO_NR_VCLOCK_PAGES) * PAGE_SIZE,
> > > - VM_READ|VM_MAYREAD|VM_IO|VM_DONTDUMP|
> > > - VM_PFNMAP,
> > > + vm_flags,
> > > &vvar_mapping);
> >
> > This hunk (and the vvar mapping in the arm64 patch) will conflict with my
> > "Generic vDSO datapage" series.
> > That series is already part of the tip tree (branch timers/vdso) and scheduled
> > for the next merge window.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=timers/vdso
> >
> > The conflict resolution is fairly easy:
> > Move the new flag logic into lib/vdso/datastore.c
> >
> Thank you for bringing this to my attention.
>
> In your change, it seems lib/vdso/datastore.c implements a
> vdso_install_vvar_mapping(), then all the architectures call this
> function.
Correct.
At least all the architectures using the generic vDSO infrastructure,
which are the ones you care about.
Sparc for example has its own implementation.
> So merging conflict won't be as straightforward.
Wouldn't it be enough to unconditionally use VM_SEALED_SYSMAP in
vdso_install_vvar_mapping()?
The symbol is a noop on architectures or configurations where the new
functionality is not available or enabled.
> Maybe a better
> approach is that I continue resolving all the comments, based on the
> latest main. Then wait for your change to be merged and submit another
> version.
That would work, too. As you prefer.
Powered by blists - more mailing lists