| Message ID | 20250224225246.3712295-7-jeffxu@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mseal system mappings | expand |
On Mon, Feb 24, 2025 at 10:52:45PM +0000, jeffxu@chromium.org wrote: > From: Jeff Xu <jeffxu@chromium.org> > > Provide support to mseal the uprobe mapping. > > Unlike other system mappings, the uprobe mapping is not > established during program startup. However, its lifetime is the same > as the process's lifetime. It could be sealed from creation. > I thought we agreed not to enable this for uprobes for now? What testing have you done to ensure this is functional? I mean is this literally _all_ uprobe mappings now being sealed? I'd really like some more assurances on this one. And what are you mitigating by sealing these? I get VDSO (kinda) but uprobes? You really need to provide more justification here. > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > --- > kernel/events/uprobes.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > index 2ca797cbe465..8dcdfa0d306b 100644 > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -1662,6 +1662,7 @@ static const struct vm_special_mapping xol_mapping = { > static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) > { > struct vm_area_struct *vma; > + unsigned long vm_flags; > int ret; > > if (mmap_write_lock_killable(mm)) > @@ -1682,8 +1683,10 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) > } > } > > + vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO; > + vm_flags |= VM_SEALED_SYSMAP; > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > + vm_flags, > &xol_mapping); > if (IS_ERR(vma)) { > ret = PTR_ERR(vma); > -- > 2.48.1.658.g4767266eb4-goog >
On Mon, Feb 24, 2025 at 10:24 PM Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote: > > On Mon, Feb 24, 2025 at 10:52:45PM +0000, jeffxu@chromium.org wrote: > > From: Jeff Xu <jeffxu@chromium.org> > > > > Provide support to mseal the uprobe mapping. > > > > Unlike other system mappings, the uprobe mapping is not > > established during program startup. However, its lifetime is the same > > as the process's lifetime. It could be sealed from creation. > > > > I thought we agreed not to enable this for now? What testing > have you done to ensure this is functional? > I honestly don't know much about uprobe. I don't recall that I agree to ignore that though. As indicated in the cover letter, it is my understanding that uprobe's mapping's lifetime are the same as process's lifetime, thus sealable. [1] Oleg Nesterov, also cc, seems OK with mseal it in the early version of this patch [2] Are there any potential downsides of doing this? If yes, I can remove it. I'm also looking at Oleg to give more guidance on this :-), or if there are some functional tests that I need to do for uprobe. [1] https://lore.kernel.org/all/20241005200741.GA24353@redhat.com/ [2] https://lore.kernel.org/all/20241005200741.GA24353@redhat.com/ > I mean is this literally _all_ uprobe mappings now being sealed? > > I'd really like some more assurances on this one. And what are you > mitigating by sealing these? I get VDSO (kinda) but uprobes? > > You really need to provide more justification here. Sure. In our threat model, we need to seal all r-x, r--, and --x mappings to prevent them from becoming writable. This applies to all mappings, regardless of whether they're created by the kernel or dynamic linker. > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > --- > > kernel/events/uprobes.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > > index 2ca797cbe465..8dcdfa0d306b 100644 > > --- a/kernel/events/uprobes.c > > +++ b/kernel/events/uprobes.c > > @@ -1662,6 +1662,7 @@ static const struct vm_special_mapping xol_mapping = { > > static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) > > { > > struct vm_area_struct *vma; > > + unsigned long vm_flags; > > int ret; > > > > if (mmap_write_lock_killable(mm)) > > @@ -1682,8 +1683,10 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) > > } > > } > > > > + vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO; > > + vm_flags |= VM_SEALED_SYSMAP; > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > > + vm_flags, > > &xol_mapping); > > if (IS_ERR(vma)) { > > ret = PTR_ERR(vma); > > -- > > 2.48.1.658.g4767266eb4-goog > >
On Tue, Feb 25, 2025 at 04:06:37PM -0800, Jeff Xu wrote: > On Mon, Feb 24, 2025 at 10:24 PM Lorenzo Stoakes > <lorenzo.stoakes@oracle.com> wrote: > > > > On Mon, Feb 24, 2025 at 10:52:45PM +0000, jeffxu@chromium.org wrote: > > > From: Jeff Xu <jeffxu@chromium.org> > > > > > > Provide support to mseal the uprobe mapping. > > > > > > Unlike other system mappings, the uprobe mapping is not > > > established during program startup. However, its lifetime is the same > > > as the process's lifetime. It could be sealed from creation. > > > > > > > I thought we agreed not to enable this for now? What testing > > have you done to ensure this is functional? > > > I honestly don't know much about uprobe. I don't recall that I agree > to ignore that though. OK sorry I realise you have done this from an early version of the series, my mistake! Apologies. I'm concerned you don't feel you know much about uprobe, but I guess you defer to Oleg's views here? If he's confirmed this is ok, then fine. > > As indicated in the cover letter, it is my understanding that uprobe's > mapping's lifetime are the same as process's lifetime, thus sealable. > [1] > Oleg Nesterov, also cc, seems OK with mseal it in the early version of > this patch [2] > > Are there any potential downsides of doing this? If yes, I can remove it. > > I'm also looking at Oleg to give more guidance on this :-), or if > there are some functional tests that I need to do for uprobe. Yeah, apologies, my mistake I forgot that this was from early, I thought it was scope creep... but I double-checked and yeah, no haha. > > > [1] https://lore.kernel.org/all/20241005200741.GA24353@redhat.com/ > [2] https://lore.kernel.org/all/20241005200741.GA24353@redhat.com/ > > > I mean is this literally _all_ uprobe mappings now being sealed? > > > > I'd really like some more assurances on this one. And what are you > > mitigating by sealing these? I get VDSO (kinda) but uprobes? > > > > You really need to provide more justification here. > > Sure. In our threat model, we need to seal all r-x, r--, and --x > mappings to prevent them from becoming writable. This applies to all > mappings, regardless of whether they're created by the kernel or > dynamic linker. All mappings? :P I mean I guess you mean somehow, all 'system' mappings right? I guess you mean that somehow some malicious user could manipulate these mappings from a sandbox or such using a series of exploits that are maybe more achievable that arbitrary code execution (rop with syscalls or sth? I am not a security person - obviously! :) And then un-sandboxed code could innocently touch and bang. I mean that to me makes sense and cool, we're good. Something like this in the doc, just a brief sentence like this for idiots (or perhaps you might say, idiots when it comes to security :) like me would be great, thanks! > > > > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > > --- > > > kernel/events/uprobes.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > > > index 2ca797cbe465..8dcdfa0d306b 100644 > > > --- a/kernel/events/uprobes.c > > > +++ b/kernel/events/uprobes.c > > > @@ -1662,6 +1662,7 @@ static const struct vm_special_mapping xol_mapping = { > > > static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) > > > { > > > struct vm_area_struct *vma; > > > + unsigned long vm_flags; > > > int ret; > > > > > > if (mmap_write_lock_killable(mm)) > > > @@ -1682,8 +1683,10 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) > > > } > > > } > > > > > > + vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO; > > > + vm_flags |= VM_SEALED_SYSMAP; > > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > > > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > > > + vm_flags, > > > &xol_mapping); > > > if (IS_ERR(vma)) { > > > ret = PTR_ERR(vma); > > > -- > > > 2.48.1.658.g4767266eb4-goog > > >
On 02/24, jeffxu@chromium.org wrote: > > Unlike other system mappings, the uprobe mapping is not > established during program startup. However, its lifetime is the same > as the process's lifetime. It could be sealed from creation. Agreed, VM_SEALED should be always for the "[uprobes]" vma, regardless of config options. ACK, but can't we do #ifdef CONFIG_64BIT /* VM is sealed, in vm_flags */ #define VM_SEALED _BITUL(63) + #else + #define VM_SEALED 0 #endif and then simply vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, + VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED, ? But I am fine either way, feel free to ignore. Oleg.
On 02/26, Oleg Nesterov wrote: > > On 02/24, jeffxu@chromium.org wrote: > > > > Unlike other system mappings, the uprobe mapping is not > > established during program startup. However, its lifetime is the same > > as the process's lifetime. It could be sealed from creation. > > Agreed, VM_SEALED should be always for the "[uprobes]" vma, regardless > of config options. > > ACK, > > but can't we do > > #ifdef CONFIG_64BIT > /* VM is sealed, in vm_flags */ > #define VM_SEALED _BITUL(63) > + #else > + #define VM_SEALED 0 > #endif > > and then simply > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > + VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED, > > ? > > But I am fine either way, feel free to ignore. Yes, but either way, why your patch adds "unsigned long vm_flags" ? OK, perhaps it makes sense for readability, but vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO; vm_flags |= VM_SEALED_SYSMAP; looks a bit strange, why not vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED_SYSMAP; ? Oleg.
On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote: > On 02/24, jeffxu@chromium.org wrote: > > > > Unlike other system mappings, the uprobe mapping is not > > established during program startup. However, its lifetime is the same > > as the process's lifetime. It could be sealed from creation. > > Agreed, VM_SEALED should be always for the "[uprobes]" vma, regardless > of config options. If you think this ought to be the case generally, then perhaps we should drop this patch from the commit and just do this separately as a permanent-on thing, if you are sure this is fine + want it? An aside - we _definitely_ cannot allow this -system mapping stuff- to be enabled without a config option, this is emphatic, for the reason that it breaks userspace and is only known-good on some arches. A config flag that checks arch gives a big warning saying 'hey this breaks userspace' means users use it knowing this to be the case. > > > ACK, > > but can't we do > > #ifdef CONFIG_64BIT > /* VM is sealed, in vm_flags */ > #define VM_SEALED _BITUL(63) > + #else > + #define VM_SEALED 0 > #endif This has been raised a few times. Jeff objects to this (for reasons I don't agree with, honestly) but it's been implemented in this way from the start (in order to catch the case of 32-bit systems trying to use mseal but it not happening). Anyway I agree, but I'm not going to push this at least in this series. > > and then simply > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > + VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED, > > ? Nah you'd have to do: > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO #ifdef CONFIG_64BIT VM_SEALED #endif , Or something similar :) Beautiful no? > > But I am fine either way, feel free to ignore. > > Oleg. > Ideally We should hear what the security use case is here. I mean I'm less bothered with it behind a flag, but it seems odd that an attacker would break out of a sandbox into a process currently being debugged... seems unlikely. I'm not sure under what other circumstances this would be a problem. Jeff, Kees? Anyway as I said before, I don't overly object to this as-is, as long as you are ok with it Oleg and can absolutely confirm this will never break anything, you don't need to remap, unmap (until process teardown), adjust the VMA in any way etc.? A quick glance at uprobe code suggests it's fine.
On 02/26, Lorenzo Stoakes wrote: > > On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote: > > On 02/24, jeffxu@chromium.org wrote: > > > > > > Unlike other system mappings, the uprobe mapping is not > > > established during program startup. However, its lifetime is the same > > > as the process's lifetime. It could be sealed from creation. > > > > Agreed, VM_SEALED should be always for the "[uprobes]" vma, regardless > > of config options. > > If you think this ought to be the case generally, then perhaps we should > drop this patch from the commit and just do this separately as a > permanent-on thing, if you are sure this is fine + want it? See below... > An aside - we _definitely_ cannot allow this -system mapping stuff- to be > enabled without a config option, This is clear. But as for uprobes in particular I do think that VM_SEALED is always fine. Do we really want it? I dunno. If a task unmaps its "[uprobes]" vma it will crash when it hits the uprobes bp next time. Unless the probed insn can be emulated and it is not ret-probe. Do we really care? Again, I don't know. Should this change come as a separate patch? I don't understand why it should but I am fine either way. In short. please do what you think is right, VM_SEALED can't hurt uprobes ;) > > #ifdef CONFIG_64BIT > > /* VM is sealed, in vm_flags */ > > #define VM_SEALED _BITUL(63) > > + #else > > + #define VM_SEALED 0 > > #endif > > This has been raised a few times. Jeff objects to this OK, > > and then simply > > > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > > + VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED, > > > > ? > > Nah you'd have to do: > > > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO > #ifdef CONFIG_64BIT > VM_SEALED > #endif > , Why??? With the proposed change above VM_SEALED == 0 if !CONFIG_64BIT. Oleg.
On Wed, Feb 26, 2025 at 07:01:36PM +0100, Oleg Nesterov wrote: > On 02/26, Lorenzo Stoakes wrote: > > > > On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote: > > > On 02/24, jeffxu@chromium.org wrote: > > > > > > > > Unlike other system mappings, the uprobe mapping is not > > > > established during program startup. However, its lifetime is the same > > > > as the process's lifetime. It could be sealed from creation. > > > > > > Agreed, VM_SEALED should be always for the "[uprobes]" vma, regardless > > > of config options. > > > > If you think this ought to be the case generally, then perhaps we should > > drop this patch from the commit and just do this separately as a > > permanent-on thing, if you are sure this is fine + want it? > > See below... > > > An aside - we _definitely_ cannot allow this -system mapping stuff- to be > > enabled without a config option, > > This is clear. > > But as for uprobes in particular I do think that VM_SEALED is always fine. > > Do we really want it? I dunno. If a task unmaps its "[uprobes]" vma it > will crash when it hits the uprobes bp next time. Unless the probed insn > can be emulated and it is not ret-probe. Do we really care? Again, I don't > know. > > Should this change come as a separate patch? I don't understand why it should > but I am fine either way. > > In short. please do what you think is right, VM_SEALED can't hurt uprobes ;) > > > > #ifdef CONFIG_64BIT > > > /* VM is sealed, in vm_flags */ > > > #define VM_SEALED _BITUL(63) > > > + #else > > > + #define VM_SEALED 0 > > > #endif > > > > This has been raised a few times. Jeff objects to this > > OK, > > > > and then simply > > > > > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > > > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > > > + VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED, > > > > > > ? > > > > Nah you'd have to do: > > > > > > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > > VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO > > #ifdef CONFIG_64BIT > > VM_SEALED > > #endif > > , > > Why??? With the proposed change above VM_SEALED == 0 if !CONFIG_64BIT. > Like I said, Jeff opposes the change. I disagree with him, and agree with you, because this is very silly. But I don't want to hold up this series with that discussion (this is for his sake...) > Oleg. > Jeff - perhaps drop this and let's return to it in a follow up so this series isn't held up? Thanks.
* Lorenzo Stoakes <lorenzo.stoakes@oracle.com> [250226 13:06]: > On Wed, Feb 26, 2025 at 07:01:36PM +0100, Oleg Nesterov wrote: > > On 02/26, Lorenzo Stoakes wrote: > > > > > > On Wed, Feb 26, 2025 at 05:26:04PM +0100, Oleg Nesterov wrote: > > > > On 02/24, jeffxu@chromium.org wrote: > > > > > > > > > > Unlike other system mappings, the uprobe mapping is not > > > > > established during program startup. However, its lifetime is the same > > > > > as the process's lifetime. It could be sealed from creation. > > > > > > > > Agreed, VM_SEALED should be always for the "[uprobes]" vma, regardless > > > > of config options. > > > > > > If you think this ought to be the case generally, then perhaps we should > > > drop this patch from the commit and just do this separately as a > > > permanent-on thing, if you are sure this is fine + want it? > > > > See below... > > > > > An aside - we _definitely_ cannot allow this -system mapping stuff- to be > > > enabled without a config option, > > > > This is clear. > > > > But as for uprobes in particular I do think that VM_SEALED is always fine. > > > > Do we really want it? I dunno. If a task unmaps its "[uprobes]" vma it > > will crash when it hits the uprobes bp next time. Unless the probed insn > > can be emulated and it is not ret-probe. Do we really care? Again, I don't > > know. > > > > Should this change come as a separate patch? I don't understand why it should > > but I am fine either way. > > > > In short. please do what you think is right, VM_SEALED can't hurt uprobes ;) > > > > > > #ifdef CONFIG_64BIT > > > > /* VM is sealed, in vm_flags */ > > > > #define VM_SEALED _BITUL(63) > > > > + #else > > > > + #define VM_SEALED 0 nit, we have VM_NONE for this (it's also 0, so no real difference) > > > > #endif > > > > > > This has been raised a few times. Jeff objects to this > > > > OK, > > > > > > and then simply > > > > > > > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > > > > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > > > > + VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED, > > > > > > > > ? > > > > > > Nah you'd have to do: > > > > > > > > > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > > > VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO > > > #ifdef CONFIG_64BIT > > > VM_SEALED > > > #endif > > > , > > > > Why??? With the proposed change above VM_SEALED == 0 if !CONFIG_64BIT. > > > > Like I said, Jeff opposes the change. I disagree with him, and agree with you, > because this is very silly. Discussion here [1]. > > But I don't want to hold up this series with that discussion (this is for his > sake...) > > > Oleg. > > > > Jeff - perhaps drop this and let's return to it in a follow up so this series > isn't held up? > ... Thanks, Liam [1]. https://lore.kernel.org/all/CABi2SkVKhjShryG0K-NSjjBvGs0UOVsY-6MQVOuQCkfuph5K8Q@mail.gmail.com/
On 02/26, Lorenzo Stoakes wrote: > > Like I said, Jeff opposes the change. I disagree with him, and agree with you, > because this is very silly. > > But I don't want to hold up this series with that discussion (this is for his > sake...) Neither me, so lets go with VM_SEALED_SYSMAP. My only objection is that vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO; vm_flags |= VM_SEALED_SYSMAP; looks unnecessarily confusing to me, vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED_SYSMAP; or just vma = _install_special_mapping(..., VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED_SYSMAP, ... looks more readable. But this is cosmetic/subjective, so I won't argue/insist. > Jeff - perhaps drop this and let's return to it in a follow up so this series > isn't held up? Up to you and Jeff. But this patch looks "natural" to me in this series. Oleg.
On Wed, Feb 26, 2025 at 07:20:50PM +0100, Oleg Nesterov wrote: > On 02/26, Lorenzo Stoakes wrote: > > > > Like I said, Jeff opposes the change. I disagree with him, and agree with you, > > because this is very silly. > > > > But I don't want to hold up this series with that discussion (this is for his > > sake...) > > Neither me, so lets go with VM_SEALED_SYSMAP. > > My only objection is that > > vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO; > vm_flags |= VM_SEALED_SYSMAP; > > looks unnecessarily confusing to me, > > vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED_SYSMAP; > > or just > > vma = _install_special_mapping(..., > VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED_SYSMAP, > ... > > looks more readable. But this is cosmetic/subjective, so I won't argue/insist. Agreed. This would be good. > > > Jeff - perhaps drop this and let's return to it in a follow up so this series > > isn't held up? > > Up to you and Jeff. > > But this patch looks "natural" to me in this series. OK, I mean in that case I'm ok with it as-is, as you confirms there's no issue, I've looked at the code and there's no issue. It was only if we wanted to try the VM_SEALED thing, i.e. _always_ seal then it'd do better outside of the series as there'd be a discussion about maybe changing this CONFIG_64BIT thing yada yada. > > Oleg. > Jeff - in that case, do NOT drop this one :P but do please look at the above style nit. Let's keep things moving... :)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 2ca797cbe465..8dcdfa0d306b 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -1662,6 +1662,7 @@ static const struct vm_special_mapping xol_mapping = { static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) { struct vm_area_struct *vma; + unsigned long vm_flags; int ret; if (mmap_write_lock_killable(mm)) @@ -1682,8 +1683,10 @@ static int xol_add_vma(struct mm_struct *mm, struct xol_area *area) } } + vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO; + vm_flags |= VM_SEALED_SYSMAP; vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, + vm_flags, &xol_mapping); if (IS_ERR(vma)) { ret = PTR_ERR(vma);