linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Xu <jeffxu@chromium.org>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: akpm@linux-foundation.org, keescook@chromium.org,
	jannh@google.com,  torvalds@linux-foundation.org, vbabka@suse.cz,
	Liam.Howlett@oracle.com,  adhemerval.zanella@linaro.org,
	oleg@redhat.com, avagin@gmail.com,  benjamin@sipsolutions.net,
	linux-kernel@vger.kernel.org,  linux-hardening@vger.kernel.org,
	linux-mm@kvack.org, jorgelo@chromium.org,  sroettger@google.com,
	hch@lst.de, ojeda@kernel.org,  thomas.weissschuh@linutronix.de,
	adobriyan@gmail.com,  johannes@sipsolutions.net,
	pedro.falcato@gmail.com, hca@linux.ibm.com,  willy@infradead.org,
	anna-maria@linutronix.de, mark.rutland@arm.com,
	 linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de,
	 rdunlap@infradead.org, davem@davemloft.net, peterx@redhat.com,
	 f.fainelli@gmail.com, gerg@kernel.org,
	dave.hansen@linux.intel.com,  mingo@kernel.org, ardb@kernel.org,
	mhocko@suse.com, 42.hyeyoo@gmail.com,  peterz@infradead.org,
	ardb@google.com, enh@google.com, rientjes@google.com,
	 groeck@chromium.org, mpe@ellerman.id.au,
	aleksandr.mikhalitsyn@canonical.com,  mike.rapoport@gmail.com
Subject: Re: [PATCH v7 1/7] mseal, system mappings: kernel config and header change
Date: Thu, 27 Feb 2025 16:04:03 -0800	[thread overview]
Message-ID: <CABi2SkWeXJXmuE8OETJvbmxzGjk1e+5FUT9Gi2ZC35M-TcZWEA@mail.gmail.com> (raw)
In-Reply-To: <b7a38abf-f102-47b4-b085-213298c51aae@lucifer.local>

On Tue, Feb 25, 2025 at 10:04 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.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@oracle.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.

Thanks
-Jeff


  reply	other threads:[~2025-02-28  0:04 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-24 22:52 [PATCH v7 0/7] mseal system mappings jeffxu
2025-02-24 22:52 ` [PATCH v7 1/7] mseal, system mappings: kernel config and header change jeffxu
2025-02-25  6:05   ` Lorenzo Stoakes
2025-02-26  1:33     ` Jeff Xu
2025-02-26  6:04       ` Lorenzo Stoakes
2025-02-28  0:04         ` Jeff Xu [this message]
2025-02-28 10:32           ` Lorenzo Stoakes
2025-02-25 15:22   ` Liam R. Howlett
2025-02-25 15:37     ` Lorenzo Stoakes
2025-02-26  0:04     ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 2/7] selftests: x86: test_mremap_vdso: skip if vdso is msealed jeffxu
2025-02-25  6:15   ` Lorenzo Stoakes
2025-02-25 22:37     ` Jeff Xu
2025-02-26  5:58       ` Lorenzo Stoakes
2025-02-24 22:52 ` [PATCH v7 3/7] mseal, system mappings: enable x86-64 jeffxu
2025-02-25  1:03   ` Kees Cook
2025-02-26  0:21     ` Jeff Xu
2025-02-25  8:08   ` Thomas Weißschuh
2025-02-26  0:48     ` Jeff Xu
2025-02-26  7:35       ` Thomas Weißschuh
2025-02-27 21:44         ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 4/7] mseal, system mappings: enable arm64 jeffxu
2025-02-25  6:20   ` Lorenzo Stoakes
2025-02-25 22:26     ` Jeff Xu
2025-02-26  5:25       ` Lorenzo Stoakes
2025-02-26 17:11         ` Liam R. Howlett
2025-02-26 17:17           ` Jeff Xu
2025-02-26 17:43             ` Lorenzo Stoakes
2025-02-26 18:14               ` Lorenzo Stoakes
2025-02-28  0:48               ` Jeff Xu
2025-02-28 10:31                 ` Lorenzo Stoakes
2025-02-24 22:52 ` [PATCH v7 5/7] mseal, system mappings: enable uml architecture jeffxu
2025-02-25  6:22   ` Lorenzo Stoakes
2025-02-25  8:45     ` Berg, Benjamin
2025-02-25 10:37       ` Lorenzo Stoakes
2025-02-25 12:24         ` Benjamin Berg
2025-02-25 13:41           ` Lorenzo Stoakes
2025-02-25 13:59             ` Johannes Berg
2025-02-25 15:06         ` Kees Cook
2025-02-25 15:31           ` Lorenzo Stoakes
2025-02-25 18:38             ` Kees Cook
2025-02-26  0:00               ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 6/7] mseal, system mappings: uprobe mapping jeffxu
2025-02-25  6:24   ` Lorenzo Stoakes
2025-02-26  0:06     ` Jeff Xu
2025-02-26  5:57       ` Lorenzo Stoakes
2025-02-26 16:26   ` Oleg Nesterov
2025-02-26 16:33     ` Oleg Nesterov
2025-02-26 16:45     ` Lorenzo Stoakes
2025-02-26 18:01       ` Oleg Nesterov
2025-02-26 18:06         ` Lorenzo Stoakes
2025-02-26 18:19           ` Liam R. Howlett
2025-02-26 18:20           ` Oleg Nesterov
2025-02-26 18:25             ` Lorenzo Stoakes
2025-02-27 23:38               ` Jeff Xu
2025-02-28 10:39                 ` Lorenzo Stoakes
2025-02-27 21:48             ` Jeff Xu
2025-02-24 22:52 ` [PATCH v7 7/7] mseal, system mappings: update mseal.rst jeffxu
2025-02-24 23:03 ` [PATCH v7 0/7] mseal system mappings Pedro Falcato
2025-02-24 23:07   ` Jeff Xu
2025-02-25  6:09     ` Lorenzo Stoakes
2025-02-25 10:32 ` Lorenzo Stoakes
2025-02-26  0:17   ` Jeff Xu
2025-02-26  6:00     ` Lorenzo Stoakes
2025-02-27 23:43       ` Jeff Xu
2025-02-28 10:32         ` Lorenzo Stoakes
2025-02-25 15:18 ` Lorenzo Stoakes
2025-02-26  0:12   ` Jeff Xu
2025-02-26  5:42     ` your mail Lorenzo Stoakes
2025-02-28  0:55       ` Jeff Xu
2025-02-28  9:35         ` Lorenzo Stoakes
2025-02-28 17:24           ` Jeff Xu
2025-02-28 17:30             ` Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABi2SkWeXJXmuE8OETJvbmxzGjk1e+5FUT9Gi2ZC35M-TcZWEA@mail.gmail.com \
    --to=jeffxu@chromium.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aleksandr.mikhalitsyn@canonical.com \
    --cc=anna-maria@linutronix.de \
    --cc=ardb@google.com \
    --cc=ardb@kernel.org \
    --cc=avagin@gmail.com \
    --cc=benjamin@sipsolutions.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=enh@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=gerg@kernel.org \
    --cc=groeck@chromium.org \
    --cc=hca@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=jannh@google.com \
    --cc=johannes@sipsolutions.net \
    --cc=jorgelo@chromium.org \
    --cc=keescook@chromium.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mark.rutland@arm.com \
    --cc=mhocko@suse.com \
    --cc=mike.rapoport@gmail.com \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=ojeda@kernel.org \
    --cc=oleg@redhat.com \
    --cc=pedro.falcato@gmail.com \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=sroettger@google.com \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox