| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 04 Oct 2018 08:37:16 -0700
From: Yu-cheng Yu <yu-cheng.yu@...el.com>
To: Eugene Syromiatnikov <esyr@...hat.com>
Cc: x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-mm@...ck.org,
linux-arch@...r.kernel.org, linux-api@...r.kernel.org,
Arnd Bergmann <arnd@...db.de>,
Andy Lutomirski <luto@...capital.net>,
Balbir Singh <bsingharora@...il.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Florian Weimer <fweimer@...hat.com>,
"H.J. Lu" <hjl.tools@...il.com>, Jann Horn <jannh@...gle.com>,
Jonathan Corbet <corbet@....net>,
Kees Cook <keescook@...omium.org>,
Mike Kravetz <mike.kravetz@...cle.com>,
Nadav Amit <nadav.amit@...il.com>,
Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
Peter Zijlstra <peterz@...radead.org>,
Randy Dunlap <rdunlap@...radead.org>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@...el.com>
Subject: Re: [RFC PATCH v4 6/9] x86/cet/ibt: Add arch_prctl functions for IBT
On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:
> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect
> > Branch Tracking features.
> >
> > Introduce:
> >
> > arch_prctl(ARCH_CET_LEGACY_BITMAP, unsigned long *addr)
> > Enable the Indirect Branch Tracking legacy code bitmap.
> >
> > The parameter 'addr' is a pointer to a user buffer.
> > On returning to the caller, the kernel fills the following:
> >
> > *addr = IBT bitmap base address
> > *(addr + 1) = IBT bitmap size
>
> Again, some structure with a size field would be better from
> UAPI/extensibility standpoint.
>
> One additional point: "size" in the structure from kernel should have
> structure size expected by kernel, and at least providing there "0" from
> user space shouldn't lead to failure (in fact, it is possible to provide
> structure size back to userspace even if buffer is too small, along
> with error).
This has been in GLIBC v2.28. We cannot change it anymore.
>
> >
> > Signed-off-by: H.J. Lu <hjl.tools@...il.com>
> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@...el.com>
> > ---
> > arch/x86/include/uapi/asm/prctl.h | 1 +
> > arch/x86/kernel/cet_prctl.c | 38 ++++++++++++++++++++++++++++++-
> > arch/x86/kernel/process.c | 1 +
> > 3 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/uapi/asm/prctl.h
> > b/arch/x86/include/uapi/asm/prctl.h
> > index 3aec1088e01d..31d2465f9caf 100644
> > --- a/arch/x86/include/uapi/asm/prctl.h
> > +++ b/arch/x86/include/uapi/asm/prctl.h
> > @@ -18,5 +18,6 @@
> > #define ARCH_CET_DISABLE 0x3002
> > #define ARCH_CET_LOCK 0x3003
> > #define ARCH_CET_ALLOC_SHSTK 0x3004
> > +#define ARCH_CET_LEGACY_BITMAP 0x3005
>
> It would probably be nice to have mention of an architecture in these
> definitions ("ARCH_X86_CET_"...), but it's likely too late.
We can still change macro names. I will work on that.
>
> >
> > #endif /* _ASM_X86_PRCTL_H */
> > diff --git a/arch/x86/kernel/cet_prctl.c b/arch/x86/kernel/cet_prctl.c
> > index c4b7c19f5040..df47b5ebc3f4 100644
> > --- a/arch/x86/kernel/cet_prctl.c
> > +++ b/arch/x86/kernel/cet_prctl.c
> > @@ -20,6 +20,8 @@ static int handle_get_status(unsigned long arg2)
> >
> > if (current->thread.cet.shstk_enabled)
> > features |= GNU_PROPERTY_X86_FEATURE_1_SHSTK;
> > + if (current->thread.cet.ibt_enabled)
> > + features |= GNU_PROPERTY_X86_FEATURE_1_IBT;
> >
> > shstk_base = current->thread.cet.shstk_base;
> > shstk_size = current->thread.cet.shstk_size;
> > @@ -49,9 +51,35 @@ static int handle_alloc_shstk(unsigned long arg2)
> > return 0;
> > }
> >
> > +static int handle_bitmap(unsigned long arg2)
> > +{
> > + unsigned long addr, size;
> > +
> > + if (current->thread.cet.ibt_enabled) {
> > + int err;
> > +
> > + err = cet_setup_ibt_bitmap();
> > + if (err)
> > + return err;
> > +
> > + addr = current->thread.cet.ibt_bitmap_addr;
> > + size = current->thread.cet.ibt_bitmap_size;
> > + } else {
> > + addr = 0;
> > + size = 0;
> > + }
> > +
> > + if (put_user(addr, (unsigned long __user *)arg2) ||
> > + put_user(size, (unsigned long __user *)arg2 + 1))
> > + return -EFAULT;
> > +
> > + return 0;
> > +}
> > +
> > int prctl_cet(int option, unsigned long arg2)
> > {
> > - if (!cpu_feature_enabled(X86_FEATURE_SHSTK))
> > + if (!cpu_feature_enabled(X86_FEATURE_SHSTK) &&
> > + !cpu_feature_enabled(X86_FEATURE_IBT))
>
> This check is repeated many times, it is probably worth defining
> something like cpu_x86_cet_enabled() or something like that.
> Besides, early introduction of the macro would allow avoiding all these
> changes over the code in IBT patches, only macro definition has
> to be changed that way.
Yes, that makes things easier.
>
> > @@ -73,6 +103,12 @@ int prctl_cet(int option, unsigned long arg2)
> > case ARCH_CET_ALLOC_SHSTK:
> > return handle_alloc_shstk(arg2);
> >
> > + /*
> > + * Allocate legacy bitmap and return address & size to user.
> > + */
> > + case ARCH_CET_LEGACY_BITMAP:
> > + return handle_bitmap(arg2);
> > +
> > default:
> > return -EINVAL;
> > }
> > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > index ac0ea9c7e89f..aea15a9b6a3e 100644
> > --- a/arch/x86/kernel/process.c
> > +++ b/arch/x86/kernel/process.c
> > @@ -797,6 +797,7 @@ long do_arch_prctl_common(struct task_struct *task, int
> > option,
> > case ARCH_CET_DISABLE:
> > case ARCH_CET_LOCK:
> > case ARCH_CET_ALLOC_SHSTK:
> > + case ARCH_CET_LEGACY_BITMAP:
> > return prctl_cet(option, cpuid_enabled);
> > }
>
> I wonder, whether this duplication is really needed for CET-related
> arch_prctl commands, why not just call them from do_arch_prctl_common?
I will fix it.
Yu-cheng
Powered by blists - more mailing lists