From: Andy Lutomirski <luto@amacapital.net> To: Ingo Molnar <mingo@kernel.org> Cc: "Thomas Gleixner" <tglx@linutronix.de>, "Ingo Molnar" <mingo@redhat.com>, "Jeff Dike" <jdike@addtoit.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@vger.kernel.org>, "Dmitry Safonov" <dsafonov@virtuozzo.com>, "Nadav Amit" <nadav.amit@gmail.com>, "Alexander Viro" <viro@zeniv.linux.org.uk>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, "Linux FS Devel" <linux-fsdevel@vger.kernel.org>, "kvm list" <kvm@vger.kernel.org>, "user-mode-linux-devel@lists.sourceforge.net" <user-mode-linux-devel@lists.sourceforge.net>, "X86 ML" <x86@kernel.org>, "open list:USER-MODE LINUX (UML)" <user-mode-linux-user@lists.sourceforge.net>, "Paolo Bonzini" <pbonzini@redhat.com>, "Kyle Huey" <me@kylehuey.com>, "Dave Hansen" <dave.hansen@linux.intel.com>, "Robert O'Callahan" <robert@ocallahan.org>, "Boris Ostrovsky" <boris.ostrovsky@oracle.com>, "Shuah Khan" <shuah@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "David Matlack" <dmatlack@google.com>, "Borislav Petkov" <bp@suse.de>, "Len Brown" <len.brown@intel.com>, "Richard Weinberger" <richard@nod.at>, "H. Peter Anvin" <hpa@zytor.com>, "Peter Zijlstra" <peterz@infradead.org> Subject: Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Date: Fri, 18 Nov 2016 09:32:46 -0800 [thread overview] Message-ID: <CALCETrX5SZh7=p1wk3yo8=vdg=veJmLwexMFGE=86bK1G6HkGQ@mail.gmail.com> (raw) In-Reply-To: <20161118081444.GC15912@gmail.com> On Nov 18, 2016 12:14 AM, "Ingo Molnar" <mingo@kernel.org> wrote: > > > * Kyle Huey <me@kylehuey.com> wrote: > > > Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. > > When enabled, the processor will fault on attempts to execute the CPUID > > instruction with CPL>0. Exposing this feature to userspace will allow a > > ptracer to trap and emulate the CPUID instruction. > > > > When supported, this feature is controlled by toggling bit 0 of > > MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of > > https://bugzilla.kernel.org/attachment.cgi?id=243991 > > > > Implement a new pair of arch_prctls, available on both x86-32 and x86-64. > > > > ARCH_GET_CPUID: Returns the current CPUID faulting state, either > > ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. arg2 must be 0. > > > > ARCH_SET_CPUID: Set the CPUID faulting state to arg2, which must be either > > ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. Returns EINVAL if arg2 is > > another value or CPUID faulting is not supported on this system. > > So the interface is: > > > +#define ARCH_GET_CPUID 0x1005 > > +#define ARCH_SET_CPUID 0x1006 > > +#define ARCH_CPUID_ENABLE 1 > > +#define ARCH_CPUID_SIGSEGV 2 > > Which maps to: > > prctl(ARCH_SET_CPUID, 0); /* -EINVAL */ > prctl(ARCH_SET_CPUID, 1); /* enable CPUID [i.e. make it work without faulting] */ > prctl(ARCH_SET_CPUID, 2); /* disable CPUID [i.e. make it fault] */ > > ret = prctl(ARCH_GET_CPUID, 0); /* return current state: 1==on, 2==off */ > > This is a very broken interface that makes very little sense. > > It would be much better to use a more natural interface where 1/0 means on/off and > where ARCH_GET_CPUID returns the current natural state: > > prctl(ARCH_SET_CPUID, 0); /* disable CPUID [i.e. make it fault] */ > prctl(ARCH_SET_CPUID, 1); /* enable CPUID [i.e. make it work without faulting] */ > > ret = prctl(ARCH_GET_CPUID); /* 1==enabled, 0==disabled */ > > See how natural it is? The use of the ARCH_CPUID_SIGSEGV/ENABLED symbols can be > avoided altogether. This will cut down on some of the ugliness in the kernel code > as well - and clean up the argument name as well: instead of naming it 'int arg2' > it can be named the more natural 'int cpuid_enabled'. > > > The state of the CPUID faulting flag is propagated across forks, but reset > > upon exec. > > I don't think this is the natural API for propagating settings across exec(). > We should reset the flag on exec() only if security considerations require it - > i.e. like perf events are cleared. > > If binaries that assume a working CPUID are exec()-ed then CPUID can be enabled > explicitly. I disagree. I'd rather not create more weird state that's carried across exec. We already have the iopl screwup IIRC. I think exec should stay as close to just working as possible. Also, if we keep it disabled across exec, we have to come up with a usable API that respects security considerations. We could use no_new_privs or we could auto-clear it on privilege changes. The former is IMO overcomplicated and the latter is really ugly especially when LSMs are involved. > > Clearing it automatically loses the ability of a pure no-CPUID environment to > exec() a CPUID-safe binary. If we really want this, let's wait until a user appears and add a "sticky" no-CPUID mode that requires no_new_privs to enable. --Andy
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@amacapital.net> To: Ingo Molnar <mingo@kernel.org> Cc: "Thomas Gleixner" <tglx@linutronix.de>, "Ingo Molnar" <mingo@redhat.com>, "Jeff Dike" <jdike@addtoit.com>, "Radim Krčmář" <rkrcmar@redhat.com>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@vger.kernel.org>, "Dmitry Safonov" <dsafonov@virtuozzo.com>, "Nadav Amit" <nadav.amit@gmail.com>, "Alexander Viro" <viro@zeniv.linux.org.uk>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, "Linux FS Devel" <linux-fsdevel@vger.kernel.org>, "kvm list" <kvm@vger.kernel.org>, "user-mode-linux-devel@lists.sourceforge.net" <user-mode-linux-devel@lists.sourceforge.net>, "X86 ML" <x86@kernel.org>, "open list:USER-MODE LINUX (UML)" <user-mode-linux-user@lists.sourceforge.net>, "Paolo Bonzini" <pbonzini@redhat.com>, "Kyle Huey" <me@kylehuey.com> Subject: Re: [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Date: Fri, 18 Nov 2016 09:32:46 -0800 [thread overview] Message-ID: <CALCETrX5SZh7=p1wk3yo8=vdg=veJmLwexMFGE=86bK1G6HkGQ@mail.gmail.com> (raw) In-Reply-To: <20161118081444.GC15912@gmail.com> On Nov 18, 2016 12:14 AM, "Ingo Molnar" <mingo@kernel.org> wrote: > > > * Kyle Huey <me@kylehuey.com> wrote: > > > Intel supports faulting on the CPUID instruction beginning with Ivy Bridge. > > When enabled, the processor will fault on attempts to execute the CPUID > > instruction with CPL>0. Exposing this feature to userspace will allow a > > ptracer to trap and emulate the CPUID instruction. > > > > When supported, this feature is controlled by toggling bit 0 of > > MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of > > https://bugzilla.kernel.org/attachment.cgi?id=243991 > > > > Implement a new pair of arch_prctls, available on both x86-32 and x86-64. > > > > ARCH_GET_CPUID: Returns the current CPUID faulting state, either > > ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. arg2 must be 0. > > > > ARCH_SET_CPUID: Set the CPUID faulting state to arg2, which must be either > > ARCH_CPUID_ENABLE or ARCH_CPUID_SIGSEGV. Returns EINVAL if arg2 is > > another value or CPUID faulting is not supported on this system. > > So the interface is: > > > +#define ARCH_GET_CPUID 0x1005 > > +#define ARCH_SET_CPUID 0x1006 > > +#define ARCH_CPUID_ENABLE 1 > > +#define ARCH_CPUID_SIGSEGV 2 > > Which maps to: > > prctl(ARCH_SET_CPUID, 0); /* -EINVAL */ > prctl(ARCH_SET_CPUID, 1); /* enable CPUID [i.e. make it work without faulting] */ > prctl(ARCH_SET_CPUID, 2); /* disable CPUID [i.e. make it fault] */ > > ret = prctl(ARCH_GET_CPUID, 0); /* return current state: 1==on, 2==off */ > > This is a very broken interface that makes very little sense. > > It would be much better to use a more natural interface where 1/0 means on/off and > where ARCH_GET_CPUID returns the current natural state: > > prctl(ARCH_SET_CPUID, 0); /* disable CPUID [i.e. make it fault] */ > prctl(ARCH_SET_CPUID, 1); /* enable CPUID [i.e. make it work without faulting] */ > > ret = prctl(ARCH_GET_CPUID); /* 1==enabled, 0==disabled */ > > See how natural it is? The use of the ARCH_CPUID_SIGSEGV/ENABLED symbols can be > avoided altogether. This will cut down on some of the ugliness in the kernel code > as well - and clean up the argument name as well: instead of naming it 'int arg2' > it can be named the more natural 'int cpuid_enabled'. > > > The state of the CPUID faulting flag is propagated across forks, but reset > > upon exec. > > I don't think this is the natural API for propagating settings across exec(). > We should reset the flag on exec() only if security considerations require it - > i.e. like perf events are cleared. > > If binaries that assume a working CPUID are exec()-ed then CPUID can be enabled > explicitly. I disagree. I'd rather not create more weird state that's carried across exec. We already have the iopl screwup IIRC. I think exec should stay as close to just working as possible. Also, if we keep it disabled across exec, we have to come up with a usable API that respects security considerations. We could use no_new_privs or we could auto-clear it on privilege changes. The former is IMO overcomplicated and the latter is really ugly especially when LSMs are involved. > > Clearing it automatically loses the ability of a pure no-CPUID environment to > exec() a CPUID-safe binary. If we really want this, let's wait until a user appears and add a "sticky" no-CPUID mode that requires no_new_privs to enable. --Andy
next prev parent reply other threads:[~2016-11-18 17:33 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-11-17 2:06 [PATCH v12 0/7] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction Kyle Huey 2016-11-17 2:06 ` Kyle Huey 2016-11-17 2:06 ` [PATCH v12 1/7] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl Kyle Huey 2016-11-17 2:06 ` Kyle Huey 2016-11-17 2:06 ` [PATCH v12 2/7] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64 Kyle Huey 2016-11-17 2:06 ` Kyle Huey 2016-11-18 7:27 ` Ingo Molnar 2016-11-18 7:27 ` Ingo Molnar 2016-11-18 7:28 ` Thomas Gleixner 2016-11-18 7:28 ` Thomas Gleixner 2016-11-18 8:16 ` Ingo Molnar 2016-11-18 8:16 ` Ingo Molnar 2016-11-18 16:39 ` Kyle Huey 2016-11-18 16:39 ` Kyle Huey 2016-11-29 9:26 ` Ingo Molnar 2016-11-29 9:26 ` Ingo Molnar 2016-11-17 2:06 ` [PATCH v12 3/7] x86/arch_prctl: Add do_arch_prctl_common Kyle Huey 2016-11-17 2:06 ` Kyle Huey 2016-11-17 2:06 ` [PATCH v12 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32 Kyle Huey 2016-11-17 2:06 ` Kyle Huey 2016-11-18 7:30 ` Ingo Molnar 2016-11-18 7:30 ` Ingo Molnar 2016-11-17 2:06 ` [PATCH v12 5/7] x86/cpufeature: Detect CPUID faulting support Kyle Huey 2016-11-17 2:06 ` Kyle Huey 2016-11-17 16:51 ` Borislav Petkov 2016-11-17 16:51 ` Borislav Petkov 2016-11-17 2:06 ` [PATCH v12 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Kyle Huey 2016-11-17 2:06 ` Kyle Huey 2016-11-18 8:14 ` Ingo Molnar 2016-11-18 8:14 ` Ingo Molnar 2016-11-18 8:49 ` Thomas Gleixner 2016-11-18 8:49 ` Thomas Gleixner 2016-11-21 8:27 ` Ingo Molnar 2016-11-21 8:27 ` Ingo Molnar 2016-11-22 17:26 ` Andy Lutomirski 2016-11-22 17:26 ` Andy Lutomirski 2016-11-18 15:55 ` Kyle Huey 2016-11-18 15:55 ` Kyle Huey 2016-11-18 17:32 ` Andy Lutomirski [this message] 2016-11-18 17:32 ` Andy Lutomirski 2016-11-17 2:06 ` [PATCH v12 7/7] KVM: x86: virtualize cpuid faulting Kyle Huey 2016-11-17 2:06 ` Kyle Huey 2016-11-17 12:31 ` Paolo Bonzini 2016-11-17 12:31 ` Paolo Bonzini
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='CALCETrX5SZh7=p1wk3yo8=vdg=veJmLwexMFGE=86bK1G6HkGQ@mail.gmail.com' \ --to=luto@amacapital.net \ --cc=boris.ostrovsky@oracle.com \ --cc=bp@suse.de \ --cc=dave.hansen@linux.intel.com \ --cc=dmatlack@google.com \ --cc=dsafonov@virtuozzo.com \ --cc=hpa@zytor.com \ --cc=jdike@addtoit.com \ --cc=kvm@vger.kernel.org \ --cc=len.brown@intel.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=me@kylehuey.com \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=nadav.amit@gmail.com \ --cc=pbonzini@redhat.com \ --cc=peterz@infradead.org \ --cc=rafael.j.wysocki@intel.com \ --cc=richard@nod.at \ --cc=rkrcmar@redhat.com \ --cc=robert@ocallahan.org \ --cc=shuah@kernel.org \ --cc=tglx@linutronix.de \ --cc=user-mode-linux-devel@lists.sourceforge.net \ --cc=user-mode-linux-user@lists.sourceforge.net \ --cc=viro@zeniv.linux.org.uk \ --cc=x86@kernel.org \ /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.