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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 8B4CCC4338F for ; Wed, 18 Aug 2021 22:27:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 656AF6101A for ; Wed, 18 Aug 2021 22:27:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234455AbhHRW2U convert rfc822-to-8bit (ORCPT ); Wed, 18 Aug 2021 18:28:20 -0400 Received: from mga07.intel.com ([134.134.136.100]:52412 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232456AbhHRW2T (ORCPT ); Wed, 18 Aug 2021 18:28:19 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10080"; a="280178010" X-IronPort-AV: E=Sophos;i="5.84,332,1620716400"; d="scan'208";a="280178010" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2021 15:27:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,332,1620716400"; d="scan'208";a="531873941" Received: from irsmsx605.ger.corp.intel.com ([163.33.146.138]) by fmsmga002.fm.intel.com with ESMTP; 18 Aug 2021 15:27:42 -0700 Received: from tjmaciei-mobl5.localnet (10.209.60.224) by IRSMSX605.ger.corp.intel.com (163.33.146.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 18 Aug 2021 23:27:38 +0100 From: Thiago Macieira To: "Bae, Chang Seok" CC: Borislav Petkov , "Lutomirski, Andy" , "tglx@linutronix.de" , "mingo@kernel.org" , "x86@kernel.org" , "Brown, Len" , "Hansen, Dave" , "Liu, Jing2" , "Shankar, Ravi V" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to protect dynamic user state Date: Wed, 18 Aug 2021 15:27:35 -0700 Message-ID: <2658618.gP76fVu5Ab@tjmaciei-mobl5> Organization: Intel Corporation In-Reply-To: References: <20210730145957.7927-1-chang.seok.bae@intel.com> <3399412.qF98CnctbS@tjmaciei-mobl5> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" X-Originating-IP: [10.209.60.224] X-ClientProxiedBy: orsmsx605.amr.corp.intel.com (10.22.229.18) To IRSMSX605.ger.corp.intel.com (163.33.146.138) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, 18 August 2021 14:12:06 PDT Bae, Chang Seok wrote: > On Aug 18, 2021, at 14:04, Thiago Macieira > wrote: > > But it's not the only possible solution. A future kernel could decide to > > leave some bits off and only enable upon request. That's how > > macOS/Darwin does its AVX512 support. > > > Even if XCR0 is ever switched, doesn’t XGETBV(0) return it for the > *current* task? That's the point. If the kernel decides that feature bit 19 will be left off in XCR0, how shall userspace know the kernel supports the feature through the arch_prctl syscall you added? Not that I am advising we adopt this strategy. We don't need more fragmentation on how we enable the features. But having this syscall gives us flexibility in case we do need it in the future. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering