[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABi2SkX3YjU-soYqRahjV07cAw1bB0ukUNiUFkc-APNN3DvJ6A@mail.gmail.com>
Date: Wed, 16 Oct 2024 17:58:48 -0700
From: Jeff Xu <jeffxu@...omium.org>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, jeffxu@...omium.org, 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, mhocko@...e.com, 42.hyeyoo@...il.com, peterz@...radead.org,
ardb@...gle.com, enh@...gle.com, rientjes@...gle.com, groeck@...omium.org,
lorenzo.stoakes@...cle.com
Subject: Re: [RFC PATCH v2 0/1] seal system mappings
On Wed, Oct 16, 2024 at 4:18 PM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
>
> * jeffxu@...omium.org <jeffxu@...omium.org> [241014 17:50]:
> > 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 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.
> ^ or ever removed.
>
> This is a pretty big deal. Platforms are trying to make it so that vdso
> is the fast path, but if they are removed then things stop using them
> and it's not a problem. This description is robbing them of the
> information they need to know that, and it's not in your change log
> either.
>
> I had said before that you need to be clear about the inability to
> remove the mappings that are sealed, as the description above heavily
> implies that it is only stopping them from becoming writeable.
>
The mseal.rst has the full description about memory sealing, I don't
see the point to repeat all the blocked operations in the commit
message here.
I don't know why you would think this heavily implies that only
stopping them from becoming writable, There is already reminder: **
For complete descriptions ** of memory sealing, please see mseal.rst
> >
> > 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.
> >
> > I tested CONFIG_SEAL_SYSTEM_MAPPINGS_ALWAYS with ChromeOS,
> > which doesn’t use CHECKPOINT_RESTORE.
> >
> > [1] Documentation/userspace-api/mseal.rst
> > [2] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4XkRkL-NrCZxYAyg@mail.gmail.com/
> >
> > History:
> > V2:
> > Seal uprobe always (Oleg Nesterov)
> > Update comments and description (Randy Dunlap, Liam R.Howlett, Oleg Nesterov)
>
> The only update to the comment I see is the pointer to mseal.rst for a
> complete description?
>
> > 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 | 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(-)
> >
> > --
> > 2.47.0.rc1.288.g06298d1525-goog
> >
Powered by blists - more mailing lists