linux-kernel - Re: [RFC PATCH v5 0/7] mseal system mappings

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: <b114f48a-a485-4ebd-9278-6c62a1f33d9c@lucifer.local>
Date: Wed, 12 Feb 2025 11:24:35 +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: [RFC PATCH v5 0/7] mseal system mappings

On Wed, Feb 12, 2025 at 03:21:48AM +0000, jeffxu@...omium.org wrote:
> From: Jeff Xu <jeffxu@...omium.org>
>
> The commit message in the first patch contains the full description of
> this series.

Sorry to nit, but it'd be useful to reproduce in the cover letter too! But
this obviously isn't urgent, just be nice when we un-RFC.

Thanks for sending as RFC, appreciated, keen to figure out a way forward
with this series and this gives us space to discuss.

One thing that came up recently with the LWN article (...!) was that rr is
also impacted by this [0].

I think with this behind a config flag we're fine (this refers to my
'opt-in' comment in the reply on LWN) as my concerns about this being
enabled in a broken way without an explicit kernel configuration are
addressed, and actually we do expose a means by which a user can detect if
the VDSO for instance is sealed via /proc/$pid/[s]maps.

So tools like rr and such can be updated to check for this. I wonder if we
ought to try to liaise with the known problematic ones?

It'd be nice to update the documentation to have a list of 'known
problematic userland software with sealed VDSO' so we make people aware.

Hopefully we are acheiving the opt-in nature of the thing here, but it
makes me wonder whether we need a prctl() interface to optionally disable
even if the system has it enabled as a whole.

That way, rr for instance can just turn it off for debugging purposes. To
be clear I am not trying to add additional extranous tasks here - my one
and only motive is to ensure that the feature works and we address concerns
about any possible breakage.

And I _want the series to land_ :>) I suspect we're close now.

I am tied up with a number of other tasks at the moment so apologies if I
take a second to get back to this series, but just wanted to say thanks for
addressing my various points, and that I will definitely provide review
(it's on the whiteboard, the only true guarantee I will do something :P).

I will also come back to your testing series which I owe you review on,
which is equally on the same whiteboard...

Thanks, Lorenzo

[0]:https://lwn.net/Articles/1007984/

>
> ------------------
> History:
>
> V5
>   - Remove kernel cmd line (Lorenzo Stoakes)
>   - Add test info (Lorenzo Stoakes)
>   - Add threat model info (Lorenzo Stoakes)
>   - Fix x86 selftest: test_mremap_vdso
>   - Restrict code change to ARM64/x86-64/UM arch only.
>   - Add userprocess.h to include seal_system_mapping().
>   - Remove sealing vsyscall.
>   - Split the patch.
>
> V4:
>   https://lore.kernel.org/all/20241125202021.3684919-1-jeffxu@google.com/
>
> V3:
>   https://lore.kernel.org/all/20241113191602.3541870-1-jeffxu@google.com/
>
> V2:
>   https://lore.kernel.org/all/20241014215022.68530-1-jeffxu@google.com/
>
> V1:
>   https://lore.kernel.org/all/20241004163155.3493183-1-jeffxu@google.com/
>
> Jeff Xu (7):
>   mseal, system mappings: kernel config and header change
>   selftests: x86: test_mremap_vdso: skip if vdso is msealed
>   mseal, system mappings: enable x86-64
>   mseal, system mappings: enable arm64
>   mseal, system mappings: enable uml architecture
>   mseal, system mappings: uprobe mapping
>   mseal, system mappings: update mseal.rst
>
>  Documentation/userspace-api/mseal.rst         |  5 +++
>  arch/arm64/Kconfig                            |  1 +
>  arch/arm64/kernel/vdso.c                      | 23 +++++++----
>  arch/um/Kconfig                               |  1 +
>  arch/x86/Kconfig                              |  1 +
>  arch/x86/entry/vdso/vma.c                     | 17 ++++++---
>  arch/x86/um/vdso/vma.c                        |  7 +++-
>  include/linux/userprocess.h                   | 18 +++++++++
>  init/Kconfig                                  | 18 +++++++++
>  kernel/events/uprobes.c                       |  6 ++-
>  security/Kconfig                              | 18 +++++++++
>  .../testing/selftests/x86/test_mremap_vdso.c  | 38 +++++++++++++++++++
>  12 files changed, 137 insertions(+), 16 deletions(-)
>  create mode 100644 include/linux/userprocess.h
>
> --
> 2.48.1.502.g6dc24dfdaf-goog
>