| 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
| ||
|
Message-ID: <CABi2SkUEd5xPhghhgYCTN_dG4aG0yE6-2dfVHPT+E+CP-C6tjw@mail.gmail.com>
Date: Tue, 19 Nov 2024 15:49:35 -0800
From: Jeff Xu <jeffxu@...omium.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
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
Subject: Re: [PATCH v3 1/1] exec: seal system mappings
Hi Lorenzo
On Wed, Nov 13, 2024 at 12:47 PM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> I'd prefer not to move forward with this until we have confirmation that
> adequate testing has been performed, given how invasive this change is,
> even if behind a flag (unless we explicitly mention it is untested in the
> Kconfig).
>
> We are touching arch-specific stuff with VDSO, VVAR, etc. so we need to be
> cautious when we're in effect hooking an arch-specific function in mm.
>
> Other than that, the actual patch isn't too crazy overall.
>
> I think a sensible approach might be to only enable on known-good arches.
>
I responded to this in the other email where you raised the same point.
> On Wed, Nov 13, 2024 at 07:16:02PM +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 [1]. 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. To address this, a kernel configuration option has
> > been introduced to enable or disable this functionality.
> >
> > [1] Documentation/userspace-api/mseal.rst
>
> It'd be nice to explicitly refer to this in the docs, it's not quite urgent
> though would be nice to be part of this series.
>
will update mseal.rst next version.
> > [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@mail.gmail.com/
> > Signed-off-by: Jeff Xu <jeffxu@...omium.org>
> > ---
> > .../admin-guide/kernel-parameters.txt | 10 +++++
> > arch/x86/entry/vsyscall/vsyscall_64.c | 9 ++++-
> > include/linux/mm.h | 12 ++++++
> > mm/mmap.c | 10 +++++
> > mm/mseal.c | 39 +++++++++++++++++++
> > security/Kconfig | 11 ++++++
> > 6 files changed, 89 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index e7bfe1bde49e..469a65b3cf50 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -1538,6 +1538,16 @@
> > Permit 'security.evm' to be updated regardless of
> > current integrity status.
> >
> > + exec.seal_system_mappings = [KNL]
> > + Format: { no | yes }
> > + Seal system mappings: vdso, vvar, sigpage, vsyscall,
> > + uprobe.
> > + This overwrites KCONFIG CONFIG_SEAL_SYSTEM_MAPPINGS
> > + - 'no': do not seal system mappings.
> > + - 'yes': seal system mappings.
> > + If not specified or invalid, default is the KCONFIG value.
> > + This option has no effect if CONFIG_64BIT=n
>
> Or if CONFIG_CHECKPOINT_RESTORE is not set. Please update to reference this
> also.
>
I will update this part. Liam has a similar comment.
> > +
> > early_page_ext [KNL,EARLY] Enforces page_ext initialization to earlier
> > stages so cover more early boot allocations.
> > Please note that as side effect some optimizations
> > diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
> > index 2fb7d53cf333..185553376f39 100644
> > --- a/arch/x86/entry/vsyscall/vsyscall_64.c
> > +++ b/arch/x86/entry/vsyscall/vsyscall_64.c
> > @@ -366,8 +366,13 @@ void __init map_vsyscall(void)
> > set_vsyscall_pgtable_user_bits(swapper_pg_dir);
> > }
> >
> > - if (vsyscall_mode == XONLY)
> > - vm_flags_init(&gate_vma, VM_EXEC);
> > + if (vsyscall_mode == XONLY) {
> > + unsigned long vm_flags = VM_EXEC;
> > +
> > + vm_flags |= seal_system_mappings();
> > +
> > + vm_flags_init(&gate_vma, vm_flags);
>
> Nit: remove weird whitespace above. Also might be worth adding a comment as
> to what we're doing here similar to the one in _install_special_mapping().
>
Done.
> > + }
> >
> > BUILD_BUG_ON((unsigned long)__fix_to_virt(VSYSCALL_PAGE) !=
> > (unsigned long)VSYSCALL_ADDR);
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index df0a5eac66b7..f787d6c85cbb 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -4238,4 +4238,16 @@ int arch_get_shadow_stack_status(struct task_struct *t, unsigned long __user *st
> > int arch_set_shadow_stack_status(struct task_struct *t, unsigned long status);
> > int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status);
> >
> > +#ifdef CONFIG_64BIT
> > +/*
> > + * return VM_SEALED if seal system mapping is enabled.
> > + */
> > +unsigned long seal_system_mappings(void);
> > +#else
> > +static inline unsigned long seal_system_mappings(void)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
> > #endif /* _LINUX_MM_H */
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 57fd5ab2abe7..bc694c555805 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2133,6 +2133,16 @@ struct vm_area_struct *_install_special_mapping(
> > unsigned long addr, unsigned long len,
> > unsigned long vm_flags, const struct vm_special_mapping *spec)
> > {
> > + /*
> > + * At present, all mappings (vdso, vvar, sigpage, and uprobe) that
> > + * invoke the _install_special_mapping function can be sealed.
> > + * Therefore, it is logical to call the seal_system_mappings_enabled()
> > + * function here. In the future, if this is not the case, i.e. if certain
> > + * mappings cannot be sealed, then it would be necessary to move this
> > + * check to the calling function.
> > + */
>
> Nice comment!
>
> > + vm_flags |= seal_system_mappings();
> > +
> > return __install_special_mapping(mm, addr, len, vm_flags, (void *)spec,
> > &special_mapping_vmops);
> > }
> > diff --git a/mm/mseal.c b/mm/mseal.c
> > index ece977bd21e1..0a9d1e9faa28 100644
> > --- a/mm/mseal.c
> > +++ b/mm/mseal.c
> > @@ -7,6 +7,7 @@
> > * Author: Jeff Xu <jeffxu@...omium.org>
> > */
> >
> > +#include <linux/fs_parser.h>
> > #include <linux/mempolicy.h>
> > #include <linux/mman.h>
> > #include <linux/mm.h>
> > @@ -266,3 +267,41 @@ SYSCALL_DEFINE3(mseal, unsigned long, start, size_t, len, unsigned long,
> > {
> > return do_mseal(start, len, flags);
> > }
> > +
> > +/*
> > + * Kernel cmdline overwrite for CONFIG_SEAL_SYSTEM_MAPPINGS
> > + */
> > +enum seal_system_mappings_type {
> > + SEAL_SYSTEM_MAPPINGS_DISABLED,
> > + SEAL_SYSTEM_MAPPINGS_ENABLED
> > +};
> > +
> > +static enum seal_system_mappings_type seal_system_mappings_v __ro_after_init =
> > + IS_ENABLED(CONFIG_SEAL_SYSTEM_MAPPINGS) ? SEAL_SYSTEM_MAPPINGS_ENABLED :
> > + SEAL_SYSTEM_MAPPINGS_DISABLED;
> > +
> > +static const struct constant_table value_table_sys_mapping[] __initconst = {
> > + { "no", SEAL_SYSTEM_MAPPINGS_DISABLED},
> > + { "yes", SEAL_SYSTEM_MAPPINGS_ENABLED},
> > + { }
> > +};
> > +
> > +static int __init early_seal_system_mappings_override(char *buf)
> > +{
> > + if (!buf)
> > + return -EINVAL;
> > +
> > + seal_system_mappings_v = lookup_constant(value_table_sys_mapping,
> > + buf, seal_system_mappings_v);
> > + return 0;
> > +}
> > +
> > +early_param("exec.seal_system_mappings", early_seal_system_mappings_override);
> > +
> > +unsigned long seal_system_mappings(void)
> > +{
> > + if (seal_system_mappings_v == SEAL_SYSTEM_MAPPINGS_ENABLED)
> > + return VM_SEALED;
> > +
> > + return 0;
> > +}
> > diff --git a/security/Kconfig b/security/Kconfig
> > index 28e685f53bd1..63b87a218943 100644
> > --- a/security/Kconfig
> > +++ b/security/Kconfig
> > @@ -51,6 +51,17 @@ config PROC_MEM_NO_FORCE
> >
> > endchoice
> >
> > +config SEAL_SYSTEM_MAPPINGS
> > + bool "seal system mappings"
> > + default n
> > + depends on 64BIT
> > + depends on !CHECKPOINT_RESTORE
>
> Would prefer to depend on actually tested architectures only.
>
I responded in the other email where you raised the same point.
Thanks for reviewing
-Jeff
> > + help
> > + Seal system mappings such as vdso, vvar, sigpage, vsyscall, uprobes.
> > + Note: CHECKPOINT_RESTORE might relocate vdso mapping during restore,
> > + and remap will fail if the mapping is sealed, therefore
> > + !CHECKPOINT_RESTORE is added as dependency.
> > +
> > config SECURITY
> > bool "Enable different security models"
> > depends on SYSFS
> > --
> > 2.47.0.277.g8800431eea-goog
> >
Powered by blists - more mailing lists