diff mbox series

[mm-unstable,1/2] mseal sysmap: generic vdso vvar mapping

Message ID 20250311123326.2686682-2-hca@linux.ibm.com (mailing list archive)
State In Next
Commit d92fcf9a4ee352c98077a66baccad5ec9debcd71
Headers show
Series mseal system mappings fix + s390 enablement | expand

Commit Message

Heiko Carstens March 11, 2025, 12:33 p.m. UTC
With the introduction of the generic vdso data storage the VM_SEALED_SYSMAP
vm flag must be moved from the architecture specific
_install_special_mapping() call [1] [2] which maps the vvar mapping to
generic code.

[1] https://lkml.kernel.org/r/20250305021711.3867874-4-jeffxu@google.com
[2] https://lkml.kernel.org/r/20250305021711.3867874-5-jeffxu@google.com

Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
 lib/vdso/datastore.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Thomas Weißschuh March 11, 2025, 12:59 p.m. UTC | #1
Hi Heiko,

On Tue, Mar 11, 2025 at 01:33:25PM +0100, Heiko Carstens wrote:
> With the introduction of the generic vdso data storage the VM_SEALED_SYSMAP
> vm flag must be moved from the architecture specific
> _install_special_mapping() call [1] [2] which maps the vvar mapping to
> generic code.

I think this change should be part of the merge commit between the
trees carrying the generic vdso data storage and mseal for system mappings.

https://lore.kernel.org/lkml/20250307151426.5f3c0c39@canb.auug.org.au/
https://lore.kernel.org/lkml/20250311150847.5a63db36@canb.auug.org.au/


> [1] https://lkml.kernel.org/r/20250305021711.3867874-4-jeffxu@google.com
> [2] https://lkml.kernel.org/r/20250305021711.3867874-5-jeffxu@google.com
> 
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
>  lib/vdso/datastore.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/vdso/datastore.c b/lib/vdso/datastore.c
> index e227fbbcb796..b7c7386c98a9 100644
> --- a/lib/vdso/datastore.c
> +++ b/lib/vdso/datastore.c
> @@ -99,7 +99,8 @@ const struct vm_special_mapping vdso_vvar_mapping = {
>  struct vm_area_struct *vdso_install_vvar_mapping(struct mm_struct *mm, unsigned long addr)
>  {
>  	return _install_special_mapping(mm, addr, VDSO_NR_PAGES * PAGE_SIZE,
> -					VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP | VM_PFNMAP,
> +					VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP |
> +					VM_PFNMAP | VM_SEALED_SYSMAP,
>  					&vdso_vvar_mapping);
>  }
>  
> -- 
> 2.45.2
>
Heiko Carstens March 11, 2025, 1:32 p.m. UTC | #2
On Tue, Mar 11, 2025 at 01:59:21PM +0100, Thomas Weißschuh wrote:
> Hi Heiko,
> 
> On Tue, Mar 11, 2025 at 01:33:25PM +0100, Heiko Carstens wrote:
> > With the introduction of the generic vdso data storage the VM_SEALED_SYSMAP
> > vm flag must be moved from the architecture specific
> > _install_special_mapping() call [1] [2] which maps the vvar mapping to
> > generic code.
> 
> I think this change should be part of the merge commit between the
> trees carrying the generic vdso data storage and mseal for system mappings.
> 
> https://lore.kernel.org/lkml/20250307151426.5f3c0c39@canb.auug.org.au/
> https://lore.kernel.org/lkml/20250311150847.5a63db36@canb.auug.org.au/

Yes, but Andrew added your patches into his tree and on top of that
the mseal patches:
https://lore.kernel.org/all/20250306235802.ff0f406acd0117bcfe927082@linux-foundation.org/
https://web.git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/log/?h=mm-unstable

When doing that the vvar bits got lost. I don't know what Andrew's
plans for the merge window are, but right now there is no merge commit
which could be fixed.
Lorenzo Stoakes March 11, 2025, 2:36 p.m. UTC | #3
On Tue, Mar 11, 2025 at 01:33:25PM +0100, Heiko Carstens wrote:
> With the introduction of the generic vdso data storage the VM_SEALED_SYSMAP
> vm flag must be moved from the architecture specific
> _install_special_mapping() call [1] [2] which maps the vvar mapping to
> generic code.
>
> [1] https://lkml.kernel.org/r/20250305021711.3867874-4-jeffxu@google.com
> [2] https://lkml.kernel.org/r/20250305021711.3867874-5-jeffxu@google.com
>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Since CONFIG_MSEAL_SYSTEM_MAPPINGS this relies upon
ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS, this is safe to do in generic code
(otherwise VM_SEALED_SYSMAP is VM_NONE).

So all good and:

Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

> ---
>  lib/vdso/datastore.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/vdso/datastore.c b/lib/vdso/datastore.c
> index e227fbbcb796..b7c7386c98a9 100644
> --- a/lib/vdso/datastore.c
> +++ b/lib/vdso/datastore.c
> @@ -99,7 +99,8 @@ const struct vm_special_mapping vdso_vvar_mapping = {
>  struct vm_area_struct *vdso_install_vvar_mapping(struct mm_struct *mm, unsigned long addr)
>  {
>  	return _install_special_mapping(mm, addr, VDSO_NR_PAGES * PAGE_SIZE,
> -					VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP | VM_PFNMAP,
> +					VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP |
> +					VM_PFNMAP | VM_SEALED_SYSMAP,
>  					&vdso_vvar_mapping);
>  }
>
> --
> 2.45.2
>
Jeff Xu March 11, 2025, 9:54 p.m. UTC | #4
On Tue, Mar 11, 2025 at 5:33 AM Heiko Carstens <hca@linux.ibm.com> wrote:
>
> With the introduction of the generic vdso data storage the VM_SEALED_SYSMAP
> vm flag must be moved from the architecture specific
> _install_special_mapping() call [1] [2] which maps the vvar mapping to
> generic code.
>
Thanks for fixing this merging problem.
The new selftest in mseal_system_mappings should catch this :-)

Hi Andrew,
when you apply this to mm-unstable, could you please insert this between:

commit 5bda54a4f304a7c3d65a40c9c3f015901caa2ce6
selftests: x86: test_mremap_vdso: skip if vdso is msealed
and
commit 884323e928c6938923e5dfcb8a601b3363e1130b
 mseal sysmap: enable x86-64

That will make the series complete.


> [1] https://lkml.kernel.org/r/20250305021711.3867874-4-jeffxu@google.com
> [2] https://lkml.kernel.org/r/20250305021711.3867874-5-jeffxu@google.com
>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
> ---
>  lib/vdso/datastore.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/vdso/datastore.c b/lib/vdso/datastore.c
> index e227fbbcb796..b7c7386c98a9 100644
> --- a/lib/vdso/datastore.c
> +++ b/lib/vdso/datastore.c
> @@ -99,7 +99,8 @@ const struct vm_special_mapping vdso_vvar_mapping = {
>  struct vm_area_struct *vdso_install_vvar_mapping(struct mm_struct *mm, unsigned long addr)
>  {
>         return _install_special_mapping(mm, addr, VDSO_NR_PAGES * PAGE_SIZE,
> -                                       VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP | VM_PFNMAP,
> +                                       VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP |
> +                                       VM_PFNMAP | VM_SEALED_SYSMAP,
>                                         &vdso_vvar_mapping);
>  }
>
> --
> 2.45.2
>
Reviewed-by: Jeff Xu <jeffxu@chromium.org>
diff mbox series

Patch

diff --git a/lib/vdso/datastore.c b/lib/vdso/datastore.c
index e227fbbcb796..b7c7386c98a9 100644
--- a/lib/vdso/datastore.c
+++ b/lib/vdso/datastore.c
@@ -99,7 +99,8 @@  const struct vm_special_mapping vdso_vvar_mapping = {
 struct vm_area_struct *vdso_install_vvar_mapping(struct mm_struct *mm, unsigned long addr)
 {
 	return _install_special_mapping(mm, addr, VDSO_NR_PAGES * PAGE_SIZE,
-					VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP | VM_PFNMAP,
+					VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP |
+					VM_PFNMAP | VM_SEALED_SYSMAP,
 					&vdso_vvar_mapping);
 }