[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7e1bfbf2-3115-408d-a40c-ae51a7ffffe4@lucifer.local>
Date: Tue, 25 Feb 2025 06:07:11 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: 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 v6 7/7] mseal, system mappings: update mseal.rst
On Mon, Feb 24, 2025 at 05:45:13PM +0000, jeffxu@...omium.org wrote:
> From: Jeff Xu <jeffxu@...omium.org>
>
> Update memory sealing documentation to include details about system
> mappings.
>
> Signed-off-by: Jeff Xu <jeffxu@...omium.org>
> ---
> Documentation/userspace-api/mseal.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst
> index 41102f74c5e2..10147281bf2d 100644
> --- a/Documentation/userspace-api/mseal.rst
> +++ b/Documentation/userspace-api/mseal.rst
> @@ -130,6 +130,13 @@ Use cases
>
> - Chrome browser: protect some security sensitive data structures.
>
> +- System mappings:
> + If supported by an architecture (via CONFIG_ARCH_HAS_MSEAL_SYSTEM_MAPPINGS),
> + the CONFIG_MSEAL_SYSTEM_MAPPINGS seals system mappings, e.g. vdso, vvar,
> + uprobes, sigpage, vectors, etc. CHECKPOINT_RESTORE, UML, gVisor, rr are
> + known to relocate or unmap system mapping, therefore this config can't be
> + enabled universally.
Thanks for adding this.
Similar comments to the Kconfig update - you are listing features that do not
exist yet, please just list what you're doing, specifically, and avoid the vague
'etc.', we don't need to be vague.
As per the Kconfig comment - you need to be a lot more clear, I think you're
duplicating the text from there to here, so again I suggest something like:
WARNING: This feature breaks programs which rely on relocating or
unmapping system mappings.
Known broken software at the time of writing includes
CHECKPOINT_RESTORE, UML, gVisor and rr.
You also seem to be writing very little here, it's a documentation page, you can
be as verbose as you like :)
You really need to add some more detail here in general - you aren't explaining
why people would want to enable this, what you're mitigating, etc. from that you
explain _why_ it doesn't work for some things.
You're also not mentioning architectural limitations here, for instance that you
can only do this on arches that don't require VDSO relocation and listing
known-good arches.
This is a documentation file, you can go wild :) the more information here the
better.
WARNING
=======
> +
> When not to use mseal
> =====================
> Applications can apply sealing to any virtual memory region from userspace,
> --
> 2.48.1.601.g30ceb7b040-goog
>
Powered by blists - more mailing lists