(I don't think this needs "RFC" any more) On Mon, Oct 14, 2024 at 09:50:20PM +0000, [email protected] wrote: > From: Jeff Xu <[email protected]> > > Seal vdso, vvar, sigpage, uprobes and vsyscall. > > Those mappings are readonly or executable only, sealing can protect > them from ever changing 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. These mappings > are designated as non-writable, and sealing them will prevent them > from ever becoming writeable. > > 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], thus sealable. > > 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. Note, uprobe > is always sealed and not controlled by this kernel configuration. > > [1] Documentation/userspace-api/mseal.rst > [2] > https://lore.kernel.org/all/cabi2sku9brunqf70-nksumcq+yyiwjo3fm4xkrkl-nrczxy...@mail.gmail.com/ > > Signed-off-by: Jeff Xu <[email protected]> > --- > .../admin-guide/kernel-parameters.txt | 10 ++++ > arch/x86/entry/vsyscall/vsyscall_64.c | 9 +++- > fs/exec.c | 53 +++++++++++++++++++ > include/linux/fs.h | 1 + > kernel/events/uprobes.c | 2 +- > mm/mmap.c | 1 + > security/Kconfig | 26 +++++++++ > 7 files changed, 99 insertions(+), 3 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index e7bfe1bde49e..02e5eb23d76f 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: { never | always } > + Seal system mappings: vdso, vvar, sigpage, uprobes, > + vsyscall. > + This overwrites KCONFIG CONFIG_SEAL_SYSTEM_MAPPINGS_* > + - 'never': never seal system mappings. > + - 'always': always seal system mappings. > + If not specified or invalid, default is the KCONFIG > value. > + This option has no effect if CONFIG_64BIT=n > +
Any reason for "always"/"never" instead of the more traditional y/n enabled/disabled, etc? Otherwise, this all makes sense to me. -- Kees Cook
