From: Eugene Syromiatnikov <esyr@redhat.com> To: Yu-cheng Yu <yu-cheng.yu@intel.com> Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@amacapital.net>, Balbir Singh <bsingharora@gmail.com>, Cyrill Gorcunov <gorcunov@gmail.com>, Dave Hansen <dave.hansen@linux.intel.com>, Florian Weimer <fweimer@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, Mike Kravetz <mike.kravetz@oracle.com>, Nadav Amit <nadav.amit@gmail.com>, Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>, Peter Zijlstra <peterz@infradead.org>, Randy Dunlap <rdunlap@infradead.org>, "Ravi V. Shankar" <ravi.v.shankar@intel.com>, Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com> Subject: Re: [RFC PATCH v4 4/9] mm/mmap: Add IBT bitmap size to address space limit check Date: Wed, 3 Oct 2018 22:21:46 +0200 [thread overview] Message-ID: <20181003202146.GG32759@asgard.redhat.com> (raw) In-Reply-To: <20180921150553.21016-5-yu-cheng.yu@intel.com> On Fri, Sep 21, 2018 at 08:05:48AM -0700, Yu-cheng Yu wrote: > The indirect branch tracking legacy bitmap takes a large address > space. This causes may_expand_vm() failure on the address limit > check. For a IBT-enabled task, add the bitmap size to the > address limit. > > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> > --- > arch/x86/include/uapi/asm/resource.h | 5 +++++ > include/uapi/asm-generic/resource.h | 3 +++ > mm/mmap.c | 12 +++++++++++- > 3 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/uapi/asm/resource.h b/arch/x86/include/uapi/asm/resource.h > index 04bc4db8921b..0741b2a6101a 100644 > --- a/arch/x86/include/uapi/asm/resource.h > +++ b/arch/x86/include/uapi/asm/resource.h > @@ -1 +1,6 @@ > +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ > +#ifdef CONFIG_X86_INTEL_CET > +#define rlimit_as_extra() current->thread.cet.ibt_bitmap_size > +#endif Does this really belong to UAPI? > + > #include <asm-generic/resource.h> > diff --git a/include/uapi/asm-generic/resource.h b/include/uapi/asm-generic/resource.h > index f12db7a0da64..8a7608a09700 100644 > --- a/include/uapi/asm-generic/resource.h > +++ b/include/uapi/asm-generic/resource.h > @@ -58,5 +58,8 @@ > # define RLIM_INFINITY (~0UL) > #endif > > +#ifndef rlimit_as_extra > +#define rlimit_as_extra() 0 > +#endif And this? > #endif /* _UAPI_ASM_GENERIC_RESOURCE_H */ > diff --git a/mm/mmap.c b/mm/mmap.c > index fa581ced3f56..397b8cb0b0af 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3237,7 +3237,17 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, > */ > bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long npages) > { > - if (mm->total_vm + npages > rlimit(RLIMIT_AS) >> PAGE_SHIFT) > + unsigned long as_limit = rlimit(RLIMIT_AS); > + unsigned long as_limit_plus = as_limit + rlimit_as_extra(); > + > + /* as_limit_plus overflowed */ > + if (as_limit_plus < as_limit) > + as_limit_plus = RLIM_INFINITY; > + > + if (as_limit_plus > as_limit) > + as_limit = as_limit_plus; > + > + if (mm->total_vm + npages > as_limit >> PAGE_SHIFT) I wonder, how realistic a scenario where a userspace application enables IBT, configures a huge prefetchable IO memory region (that just ignores bits of offset beyond 16, for example), and start repeatedly loading a legacy library there at different linear addresses. > return false; > > if (is_data_mapping(flags) && > -- > 2.17.1 >
WARNING: multiple messages have this Message-ID (diff)
From: Eugene Syromiatnikov <esyr@redhat.com> To: Yu-cheng Yu <yu-cheng.yu@intel.com> Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@amacapital.net>, Balbir Singh <bsingharora@gmail.com>, Cyrill Gorcunov <gorcunov@gmail.com>, Dave Hansen <dave.hansen@linux.intel.com>, Florian Weimer <fweimer@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, Mike Kravetz <mike.kravetz@oracle.com>, Nadav Amit <nadav.amit@gmail.com>, Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>Peter Subject: Re: [RFC PATCH v4 4/9] mm/mmap: Add IBT bitmap size to address space limit check Date: Wed, 3 Oct 2018 22:21:46 +0200 [thread overview] Message-ID: <20181003202146.GG32759@asgard.redhat.com> (raw) In-Reply-To: <20180921150553.21016-5-yu-cheng.yu@intel.com> On Fri, Sep 21, 2018 at 08:05:48AM -0700, Yu-cheng Yu wrote: > The indirect branch tracking legacy bitmap takes a large address > space. This causes may_expand_vm() failure on the address limit > check. For a IBT-enabled task, add the bitmap size to the > address limit. > > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com> > --- > arch/x86/include/uapi/asm/resource.h | 5 +++++ > include/uapi/asm-generic/resource.h | 3 +++ > mm/mmap.c | 12 +++++++++++- > 3 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/include/uapi/asm/resource.h b/arch/x86/include/uapi/asm/resource.h > index 04bc4db8921b..0741b2a6101a 100644 > --- a/arch/x86/include/uapi/asm/resource.h > +++ b/arch/x86/include/uapi/asm/resource.h > @@ -1 +1,6 @@ > +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ > +#ifdef CONFIG_X86_INTEL_CET > +#define rlimit_as_extra() current->thread.cet.ibt_bitmap_size > +#endif Does this really belong to UAPI? > + > #include <asm-generic/resource.h> > diff --git a/include/uapi/asm-generic/resource.h b/include/uapi/asm-generic/resource.h > index f12db7a0da64..8a7608a09700 100644 > --- a/include/uapi/asm-generic/resource.h > +++ b/include/uapi/asm-generic/resource.h > @@ -58,5 +58,8 @@ > # define RLIM_INFINITY (~0UL) > #endif > > +#ifndef rlimit_as_extra > +#define rlimit_as_extra() 0 > +#endif And this? > #endif /* _UAPI_ASM_GENERIC_RESOURCE_H */ > diff --git a/mm/mmap.c b/mm/mmap.c > index fa581ced3f56..397b8cb0b0af 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3237,7 +3237,17 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, > */ > bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long npages) > { > - if (mm->total_vm + npages > rlimit(RLIMIT_AS) >> PAGE_SHIFT) > + unsigned long as_limit = rlimit(RLIMIT_AS); > + unsigned long as_limit_plus = as_limit + rlimit_as_extra(); > + > + /* as_limit_plus overflowed */ > + if (as_limit_plus < as_limit) > + as_limit_plus = RLIM_INFINITY; > + > + if (as_limit_plus > as_limit) > + as_limit = as_limit_plus; > + > + if (mm->total_vm + npages > as_limit >> PAGE_SHIFT) I wonder, how realistic a scenario where a userspace application enables IBT, configures a huge prefetchable IO memory region (that just ignores bits of offset beyond 16, for example), and start repeatedly loading a legacy library there at different linear addresses. > return false; > > if (is_data_mapping(flags) && > -- > 2.17.1 >
next prev parent reply other threads:[~2018-10-03 20:21 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-21 15:05 [RFC PATCH v4 0/9] Control Flow Enforcement: Branch Tracking, PTRACE Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-09-21 15:05 ` [RFC PATCH v4 1/9] x86/cet/ibt: Add Kconfig option for user-mode Indirect Branch Tracking Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-09-21 15:05 ` [RFC PATCH v4 2/9] x86/cet/ibt: User-mode indirect branch tracking support Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-10-03 18:58 ` Eugene Syromiatnikov 2018-10-03 18:58 ` Eugene Syromiatnikov 2018-09-21 15:05 ` [RFC PATCH v4 3/9] x86/cet/ibt: Add IBT legacy code bitmap allocation function Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-10-03 19:57 ` Eugene Syromiatnikov 2018-10-03 19:57 ` Eugene Syromiatnikov 2018-10-05 16:13 ` Yu-cheng Yu 2018-10-05 16:13 ` Yu-cheng Yu 2018-10-05 16:28 ` Andy Lutomirski 2018-10-05 16:28 ` Andy Lutomirski 2018-10-05 16:58 ` Yu-cheng Yu 2018-10-05 16:58 ` Yu-cheng Yu 2018-10-05 16:58 ` Yu-cheng Yu 2018-10-05 17:07 ` Andy Lutomirski 2018-10-05 17:07 ` Andy Lutomirski 2018-10-05 17:26 ` Eugene Syromiatnikov 2018-10-05 17:26 ` Eugene Syromiatnikov 2018-10-05 17:26 ` Eugene Syromiatnikov 2018-10-10 15:56 ` Yu-cheng Yu 2018-10-10 15:56 ` Yu-cheng Yu 2018-10-10 15:56 ` Yu-cheng Yu 2018-10-04 16:11 ` Andy Lutomirski 2018-10-04 16:11 ` Andy Lutomirski 2018-09-21 15:05 ` [RFC PATCH v4 4/9] mm/mmap: Add IBT bitmap size to address space limit check Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-10-03 20:21 ` Eugene Syromiatnikov [this message] 2018-10-03 20:21 ` Eugene Syromiatnikov 2018-09-21 15:05 ` [RFC PATCH v4 5/9] x86/cet/ibt: ELF header parsing for IBT Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-09-21 15:05 ` [RFC PATCH v4 6/9] x86/cet/ibt: Add arch_prctl functions " Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-10-04 13:28 ` Eugene Syromiatnikov 2018-10-04 13:28 ` Eugene Syromiatnikov 2018-10-04 15:37 ` Yu-cheng Yu 2018-10-04 15:37 ` Yu-cheng Yu 2018-10-04 16:07 ` Florian Weimer 2018-10-04 16:07 ` Florian Weimer 2018-10-04 16:12 ` Andy Lutomirski 2018-10-04 16:12 ` Andy Lutomirski 2018-10-04 16:25 ` Yu-cheng Yu 2018-10-04 16:25 ` Yu-cheng Yu 2018-10-04 16:08 ` Andy Lutomirski 2018-10-04 16:08 ` Andy Lutomirski 2018-09-21 15:05 ` [RFC PATCH v4 7/9] x86/cet/ibt: Add ENDBR to op-code-map Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-09-21 15:05 ` [RFC PATCH v4 8/9] x86: Insert endbr32/endbr64 to vDSO Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu 2018-09-21 15:05 ` [RFC PATCH v4 9/9] x86/cet: Add PTRACE interface for CET Yu-cheng Yu 2018-09-21 15:05 ` Yu-cheng Yu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181003202146.GG32759@asgard.redhat.com \ --to=esyr@redhat.com \ --cc=arnd@arndb.de \ --cc=bsingharora@gmail.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@linux.intel.com \ --cc=fweimer@redhat.com \ --cc=gorcunov@gmail.com \ --cc=hjl.tools@gmail.com \ --cc=hpa@zytor.com \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=luto@amacapital.net \ --cc=mike.kravetz@oracle.com \ --cc=mingo@redhat.com \ --cc=nadav.amit@gmail.com \ --cc=oleg@redhat.com \ --cc=pavel@ucw.cz \ --cc=peterz@infradead.org \ --cc=ravi.v.shankar@intel.com \ --cc=rdunlap@infradead.org \ --cc=tglx@linutronix.de \ --cc=vedvyas.shanbhogue@intel.com \ --cc=x86@kernel.org \ --cc=yu-cheng.yu@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.