From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4BC61C282CB for ; Tue, 5 Feb 2019 18:33:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 27957217F9 for ; Tue, 5 Feb 2019 18:33:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730218AbfBESdF (ORCPT ); Tue, 5 Feb 2019 13:33:05 -0500 Received: from mga09.intel.com ([134.134.136.24]:45218 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727379AbfBESdF (ORCPT ); Tue, 5 Feb 2019 13:33:05 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2019 10:33:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,336,1544515200"; d="scan'208";a="317874799" Received: from romley-ivt3.sc.intel.com ([172.25.110.60]) by fmsmga005.fm.intel.com with ESMTP; 05 Feb 2019 10:33:04 -0800 Date: Tue, 5 Feb 2019 10:26:51 -0800 From: Fenghua Yu To: Borislav Petkov Cc: Dave Hansen , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , H Peter Anvin , Ashok Raj , Michael Chan , Ravi V Shankar , Ricardo Neri , linux-kernel , x86 Subject: Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid Message-ID: <20190205182651.GB70667@romley-ivt3.sc.intel.com> References: <1549084491-57808-1-git-send-email-fenghua.yu@intel.com> <1549084491-57808-9-git-send-email-fenghua.yu@intel.com> <9fa7406b-113f-fe0a-9fc7-ef00b3a6b620@intel.com> <20190204195704.GJ29639@zn.tnic> <5c2f0af3-1740-f16b-6ff6-6bec6a325034@intel.com> <20190205084857.GK17528@hirez.programming.kicks-ass.net> <20190205154309.GU21801@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190205154309.GU21801@zn.tnic> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 05, 2019 at 04:43:09PM +0100, Borislav Petkov wrote: > On Tue, Feb 05, 2019 at 07:19:16AM -0800, Dave Hansen wrote: > > This is one of the few times that we're pretty confident that folks will > > use this. The reason we're going to this trouble is that the split lock > > detection is wanted by actual customers, and they want it before it's > > implemented on a processor with real enumeration. > > > > This isn't something we want everybody and their grandma to turn on; > > it's a rather specialized feature. It's really only for folks that care > > about the latency incurred across the entire system on split lock > > operations. > > ... > > > It's not for developers. This really is for (somewhat niche) end users > > that want split lock detection in production. This is all really an > > effort to get them running mainline or real distro kernels. > > This all sounds to me like it shouldn't even be mainline but in a > special, evaluation kernel. If anything, it should be default off and be > opted-in by a cmdline switch. None of that *cpuid=* toggling dance In the cover patch, we gave three real usage cases for this feature: This capability is critical for real time system designers who build consolidated real time systems. These systems run hard real time code on some cores and run "untrusted" user processes on some other cores. The hard real time cannot afford to have any bus lock from the untrusted processes to hurt real time performance. To date the designers have been unable to deploy these solutions as they have no way to prevent the "untrusted" user code from generating split lock and bus lock to block the hard real time code to access memory during bus locking. This capability may also find usage in cloud. A user process with split lock running in one guest can block other cores from accessing shared memory during its split locked memory access. That may cause overall system performance degradation. Split lock may open a security hole where malicious user code may slow down overall system by executing instructions with split lock. In the usage cases, end users (not developers) want to turn on the feature in their production lines (not evaluation) to detect split lock issues which can come not only from legacy apps but also from malicious code or newly started apps any time during run time. Thanks. -Fenghua