linux-hardening - Re: [PATCH v4 0/1] Seal 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: <7494c3aa-378f-4bb6-bc44-59ea49ccc5e6@lucifer.local>
Date: Tue, 26 Nov 2024 16:39:51 +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, adhemerval.zanella@...aro.org,
        oleg@...hat.com, linux-kernel@...r.kernel.org,
        linux-hardening@...r.kernel.org, linux-mm@...ck.org,
        jorgelo@...omium.org, sroettger@...gle.com, ojeda@...nel.org,
        adobriyan@...il.com, anna-maria@...utronix.de, mark.rutland@....com,
        linus.walleij@...aro.org, Jason@...c4.com, deller@....de,
        rdunlap@...radead.org, davem@...emloft.net, hch@....de,
        peterx@...hat.com, hca@...ux.ibm.com, f.fainelli@...il.com,
        gerg@...nel.org, dave.hansen@...ux.intel.com, mingo@...nel.org,
        ardb@...nel.org, Liam.Howlett@...cle.com, 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, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH v4 0/1] Seal system mappings

+Vlastimil

Jeff... :)

Please review
https://www.kernel.org/doc/html/latest/process/submitting-patches.html

You didn't cc- mantainers of code you are changing. And you reference my
name without cc'ing me here. I'm sure there's some relevant Taylor Swift
lyric...


On Mon, Nov 25, 2024 at 08:20:20PM +0000, jeffxu@...omium.org wrote:
> From: Jeff Xu <jeffxu@...omium.org>
>
> Seal vdso, vvar, sigpage, uprobes and vsyscall.
>
> Those mappings are readonly or executable only, sealing can protect
> them from ever changing or unmapped during the life time of the process.
> For complete descriptions of memory sealing, please see mseal.rst [1].
>
> System mappings such as vdso, vvar, and sigpage (for arm) are
> generated by the kernel during program initialization, and are
> sealed after creation.
>
> Unlike the aforementioned mappings, the uprobe mapping is not
> established during program startup. However, its lifetime is the same
> as the process's lifetime [2]. It is sealed from creation.
>
> The vdso, vvar, sigpage, and uprobe mappings all invoke the
> _install_special_mapping() function. As no other mappings utilize this
> function, it is logical to incorporate sealing logic within
> _install_special_mapping(). This approach avoids the necessity of
> modifying code across various architecture-specific implementations.
>
> The vsyscall mapping, which has its own initialization function, is
> sealed in the XONLY case, it seems to be the most common and secure
> case of using vsyscall.
>
> It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may
> alter the mapping of vdso, vvar, and sigpage during restore
> operations. Consequently, this feature cannot be universally enabled
> across all systems.
>
> Currently, memory sealing is only functional in a 64-bit kernel
> configuration.
>
> To enable this feature, the architecture needs to be tested to
> confirm that it doesn't unmap/remap system mappings during the
> the life time of the process. After the architecture enables
> ARCH_HAS_SEAL_SYSTEM_MAPPINGS, a distribution can set
> CONFIG_SEAL_SYSTEM_MAPPING to manage access to the feature.
> Alternatively, kernel command line (exec.seal_system_mappings)
> enables this feature also.
>
> This feature is tested using ChromeOS and Android on X86_64 and ARM64,
> therefore ARCH_HAS_SEAL_SYSTEM_MAPPINGS is set for X86_64 and ARM64.
> Other architectures can enable this after testing. No specific hardware
> features from the CPU are needed.
>
> This feature's security enhancements will benefit ChromeOS, Android,
> and other secure-by-default systems.
>
> [1] Documentation/userspace-api/mseal.rst
> [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@mail.gmail.com/
>
> History:
> V4:
>   ARCH_HAS_SEAL_SYSTEM_MAPPINGS (Lorenzo Stoakes)
>   test info (Lorenzo Stoakes)
>   Update  mseal.rst (Liam R. Howlett)
>   Update test_mremap_vdso.c (Liam R. Howlett)
>   Misc. style, comments, doc update (Liam R. Howlett)
>
> V3:
>   https://lore.kernel.org/all/20241113191602.3541870-1-jeffxu@google.com/
>   Revert uprobe to v1 logic (Oleg Nesterov)
>   use CONFIG_SEAL_SYSTEM_MAPPINGS instead of _ALWAYS/_NEVER (Kees Cook)
>   Move kernel cmd line from fs/exec.c to mm/mseal.c and misc. refactor (Liam R. Howlett)
>
> V2:
>   https://lore.kernel.org/all/20241014215022.68530-1-jeffxu@google.com/
>   Seal uprobe always (Oleg Nesterov)
>   Update comments and description (Randy Dunlap, Liam R.Howlett, Oleg Nesterov)
>   Rebase to linux_main
>
> V1:
> https://lore.kernel.org/all/20241004163155.3493183-1-jeffxu@google.com/
>
> Jeff Xu (1):
>   exec: seal system mappings
>
>  .../admin-guide/kernel-parameters.txt         | 11 ++++++
>  Documentation/userspace-api/mseal.rst         |  4 ++
>  arch/arm64/Kconfig                            |  1 +
>  arch/x86/Kconfig                              |  1 +
>  arch/x86/entry/vsyscall/vsyscall_64.c         |  8 +++-
>  include/linux/mm.h                            | 12 ++++++
>  init/Kconfig                                  | 25 ++++++++++++
>  mm/mmap.c                                     | 10 +++++
>  mm/mseal.c                                    | 39 +++++++++++++++++++
>  security/Kconfig                              | 24 ++++++++++++
>  10 files changed, 133 insertions(+), 2 deletions(-)
>
> --
> 2.47.0.338.g60cca15819-goog
>