linux-kernel - Re: [PATCH v7 1/7] mseal, system mappings: kernel config and header change

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5797d6f7-51e9-4610-9305-0ac4a82ba577@lucifer.local>
Date: Fri, 28 Feb 2025 10:32:24 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jeff Xu <jeffxu@...omium.org>
Cc: akpm@...ux-foundation.org, keescook@...omium.org, jannh@...gle.com,
        torvalds@...ux-foundation.org, vbabka@...e.cz, 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 1/7] mseal, system mappings: kernel config and header
 change

On Thu, Feb 27, 2025 at 04:04:03PM -0800, Jeff Xu wrote:
> On Tue, Feb 25, 2025 at 10:04 PM Lorenzo Stoakes
> <lorenzo.stoakes@...cle.com> wrote:
> >
> > On Tue, Feb 25, 2025 at 05:33:24PM -0800, Jeff Xu wrote:
> > > On Mon, Feb 24, 2025 at 10:05 PM Lorenzo Stoakes
> > > <lorenzo.stoakes@...cle.com> wrote:
> > > > > +config ARCH_HAS_MSEAL_SYSTEM_MAPPINGS
> > > > > +     bool
> > > > > +     help
> > > > > +       Control MSEAL_SYSTEM_MAPPINGS access based on architecture.
> > > > > +
> > > > > +       A 64-bit kernel is required for the memory sealing feature.
> > > > > +       No specific hardware features from the CPU are needed.
> > > > > +
> > > > > +       To enable this feature, the architecture needs to update their
> > > > > +       special mappings calls to include the sealing flag and confirm
> > > > > +       that it doesn't unmap/remap system mappings during the life
> > > > > +       time of the process. After the architecture enables this, a
> > > > > +       distribution can set CONFIG_MSEAL_SYSTEM_MAPPING to manage access
> > > > > +       to the feature.
> > > >
> > > > Architectures also need to be confirmed not to require any form of VDSO
> > > > relocation, which as discussed in previous series some arches appear to
> > > > need to do. I'd mention that here.
> > > >
> > > This might need clarification, the system mapping includes vdso, right
> > > ? Why the focus on vdso ?
> >
> > My mistake, I thought scope was more limited than this when I first
> > looked. Please disregard the focus on VDSO here... :)
> >
> > >
> > > The sentence  "... it doesn't unmap/remap system mappings during the
> > > lifetime of the process."  already cover what you want here, I think.
> > >
> >
> > Right, I guess it just doesn't quite _emphasise_ it enough for me. Something
> > like the below would really help bring that out:
> >
> >         The existing of this flag for an architecture implies that it does not
> >         require the remapping of these system mappings during process lifetime,
> >         so sealing these mappings is safe from a kernel perspective.
> >
> I'm not sure I get the difference, but I can add it,  is below OK ?
>
> To enable this feature, the architecture needs to update their
> special mappings calls to include the sealing flag and confirm
> that it doesn't unmap/remap system mappings during the life
> time of the process. The existence of this flag for an architecture
> implies that it does not require the remapping of these system
> mappings during process lifetime, so sealing these mappings is
> safe from a kernel perspective. After the architecture enables this,
> a distribution can set CONFIG_MSEAL_SYSTEM_MAPPING to
> manage access to the feature.

Sounds great, cheers!

>
> Thanks
> -Jeff