From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764201AbcINT30 (ORCPT ); Wed, 14 Sep 2016 15:29:26 -0400 Received: from ppsw-31.csi.cam.ac.uk ([131.111.8.131]:39765 "EHLO ppsw-31.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763906AbcINT3Y (ORCPT ); Wed, 14 Sep 2016 15:29:24 -0400 X-Greylist: delayed 356 seconds by postgrey-1.27 at vger.kernel.org; Wed, 14 Sep 2016 15:29:23 EDT X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Subject: Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction. To: Boris Ostrovsky , Andy Lutomirski , Kyle Huey References: <1473640169-24145-1-git-send-email-khuey@kylehuey.com> Cc: Thomas Gleixner , John Stultz , Ingo Molnar , Michal Hocko , Andrew Morton , "Michael S. Tsirkin" , Alexander Shishkin , Aravind Gopalakrishnan , Vlastimil Babka , "Luis R. Rodriguez" , Mateusz Guzik , Alex Thorlton , "Rafael J. Wysocki" , Dmitry Vyukov , Vladimir Zapolskiy , Jiri Slaby , Andrey Ryabinin , Ben Segall , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Denys Vlasenko , Paul Gortmaker , Srinivas Pandruvada , "Robert O'Callahan" , "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Juergen Gross , Linux API , Fenghua Yu , Kees Cook , "Peter Zijlstra (Intel)" , Borislav Petkov , Len Brown , Huang Rui , "H. Peter Anvin" From: Andrew Cooper Message-ID: <2c7b1052-be5a-f776-60e5-23136cd7443c@citrix.com> Date: Wed, 14 Sep 2016 20:28:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/09/2016 20:23, Boris Ostrovsky wrote: > On 09/14/2016 02:52 PM, Andy Lutomirski wrote: >> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: >>> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski wrote: >>>> You should explicitly check that, if the >>>> feature is set under Xen PV, then the MSR actually works as >>>> advertised. This may require talking to the Xen folks to make sure >>>> you're testing the right configuration. >>> This is interesting. When running under Xen PV the kernel is allowed >>> to read the real value of MSR_PLATFORM_INFO and see that CPUID >>> faulting is supported. But as you suggested, writing to >>> MSR_MISC_FEATURES_ENABLES doesn't actually enable CPUID faulting, at >>> least not in any way that works. >>> >>> It's not obvious to me how to test this, because when this feature >>> works, CPUID only faults in userspace, not in the kernel. Is there >>> existing code somewhere that runs tests like this in userspace? >>> >> Andrew, Boris: should we expect Xen PV to do anything sensible when we >> write to MSR_PLATFORM_INFO to turn on CPUID faulting? Should the Xen >> PV rdmsr hooks or perhaps the hypervisor mask out the feature if it >> isn't going to be supported? > The hypervisor uses CPUID faulting so we shouldn't advertise this > feature to guests. In the case that the hardware has faulting, or for any HVM guest, the extra cost to making the feature available to the guest is a single conditional test in the cpuid path. This is about as close to zero as a feature gets. We really should be offering the feature to guests, and have it actually working. The issue here is that it is leaking when we weren't intending to offer it. ~Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] prctl,x86 Add PR_[GET|SET]_CPUID for controlling the CPUID instruction. Date: Wed, 14 Sep 2016 20:28:55 +0100 Message-ID: <2c7b1052-be5a-f776-60e5-23136cd7443c@citrix.com> References: <1473640169-24145-1-git-send-email-khuey@kylehuey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Boris Ostrovsky , Andy Lutomirski , Kyle Huey Cc: Thomas Gleixner , John Stultz , Ingo Molnar , Michal Hocko , Andrew Morton , "Michael S. Tsirkin" , Alexander Shishkin , Aravind Gopalakrishnan , Vlastimil Babka , "Luis R. Rodriguez" , Mateusz Guzik , Alex Thorlton , "Rafael J. Wysocki" , Dmitry Vyukov , Vladimir Zapolskiy , Jiri Slaby , Andrey Ryabinin , Ben Segall , maintainer:X86 ARCHITECTURE (32-BIT List-Id: linux-api@vger.kernel.org On 14/09/2016 20:23, Boris Ostrovsky wrote: > On 09/14/2016 02:52 PM, Andy Lutomirski wrote: >> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey wrote: >>> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski wrote: >>>> You should explicitly check that, if the >>>> feature is set under Xen PV, then the MSR actually works as >>>> advertised. This may require talking to the Xen folks to make sure >>>> you're testing the right configuration. >>> This is interesting. When running under Xen PV the kernel is allowed >>> to read the real value of MSR_PLATFORM_INFO and see that CPUID >>> faulting is supported. But as you suggested, writing to >>> MSR_MISC_FEATURES_ENABLES doesn't actually enable CPUID faulting, at >>> least not in any way that works. >>> >>> It's not obvious to me how to test this, because when this feature >>> works, CPUID only faults in userspace, not in the kernel. Is there >>> existing code somewhere that runs tests like this in userspace? >>> >> Andrew, Boris: should we expect Xen PV to do anything sensible when we >> write to MSR_PLATFORM_INFO to turn on CPUID faulting? Should the Xen >> PV rdmsr hooks or perhaps the hypervisor mask out the feature if it >> isn't going to be supported? > The hypervisor uses CPUID faulting so we shouldn't advertise this > feature to guests. In the case that the hardware has faulting, or for any HVM guest, the extra cost to making the feature available to the guest is a single conditional test in the cpuid path. This is about as close to zero as a feature gets. We really should be offering the feature to guests, and have it actually working. The issue here is that it is leaking when we weren't intending to offer it. ~Andrew