Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp934651pxp; Wed, 16 Mar 2022 21:51:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwaWDB/tZu2afSQQscYs7AOmweEyVSGzgLQ+rlppPXPUvvYBwATzN0ysUVYZZp0bDwCMs9O X-Received: by 2002:a17:902:cf02:b0:14f:e0c2:1514 with SMTP id i2-20020a170902cf0200b0014fe0c21514mr2809390plg.90.1647492664176; Wed, 16 Mar 2022 21:51:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647492664; cv=none; d=google.com; s=arc-20160816; b=fNGcuHng/ZaaIwzE+1kBuGS4WKjyuRqVwR6HLZhzp4eR3UrUSn02CrVCQLqhSJJH0J Oy812IkZ2HsjSTbyLwv7YhPcOeU4SfgRajwAGRAyFewc5cqqjF4GNtOZMbjYjCofb6Jf hyP6o8kdpnhNDq5R/X2rX+oztvQXyS/8KEV5yk1Svnx72DMxx4ngQHBaqnklP/iibFY+ 8H6r3+hBg9lms3lPih87qP9+NqWxNF7Ul9FXtuoMEoI602s/OKB0LsB+6ntEQASEo9HV aF24hFX5zSewAAwpmwzXMIy7rsILohstVL9LMpyEm56mbStkGNLGfszam+w859aVYalo ptlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=ToJpzCDw+ewsryh6ivb42cn+E4Ux4Mnyc9a778LHaTc=; b=WaWKMOhhboawY0sSCw/yoYvCvfRmECpyJbFo5w0fB0dD57j00R8ruDl6zdCdplN+nr Juk38ayf+mqIiKF8+Wm0CDni1M7PNCnZwYcUont754lrYpXy7FRLhXLn8g1zzVJ3Id/N p+reKPUMMasRzNXHyhRPetFgs0D2ce8ZHSIXMPMO4jyikCsK9Q8Nvm8mfhcJ5p0MkIUt JAxurXN6zmkDrwQUju8mgBxdMYR1ZMJIbfNKBdFG7nv6bo6MuKzc7SZzmJ72IQwsYxrC nOekgGtSL56Mpuec208NjxOZQLPTQ6xcx0kuYZIIQtoijCLkzlgvL+zRJXl9M7j0jKj9 ouUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="b/gLlPjo"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id n8-20020a17090ade8800b001bd14e030d8si1168497pjv.176.2022.03.16.21.51.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 21:51:04 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="b/gLlPjo"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A59D315B983; Wed, 16 Mar 2022 21:10:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357368AbiCPPsr (ORCPT + 99 others); Wed, 16 Mar 2022 11:48:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357378AbiCPPsn (ORCPT ); Wed, 16 Mar 2022 11:48:43 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3D3D6D390; Wed, 16 Mar 2022 08:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647445649; x=1678981649; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=BrzHWmqSAHVQTAHSUYYjuNm7pNzr8pYle8SOGv/r6GU=; b=b/gLlPjo+GNMXH0FpOx/NfcTwWyfOZVqa6qYElT/VsEJVc7NuRK4gc5+ VONr6SKWcTAGlPDBCqC5edqCdtTsOnzqj4wKNWxGGaGRVNuBIjtxNBam3 NMPJUNyYjJabJSJu7GUvYjubzFlqXEXF5eoHOMmwMzp5CFLyMpfPn44eh p67BBddpxwJGAf31Tl1Oe/6875KkHuceHWHGyy5i/MMoAWXuXvRmLiG1F xby6kxQgM4RF0YFgQmupStrgbRn8LQmMl0Wt7wcg62UeoF2q33QAblyXb EY7jaPaTar3V2SNjDUTrEP57FSLssC1FAJ0X3k5fqBG8btb5CdJFyqY0y A==; X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="343072053" X-IronPort-AV: E=Sophos;i="5.90,186,1643702400"; d="scan'208";a="343072053" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2022 08:47:29 -0700 X-IronPort-AV: E=Sophos;i="5.90,186,1643702400"; d="scan'208";a="557509706" Received: from jdwaldem-mobl.amr.corp.intel.com (HELO [10.255.228.230]) ([10.255.228.230]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2022 08:47:29 -0700 Message-ID: Date: Wed, 16 Mar 2022 08:47:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Jethro Beekman , Cathy Zhang , linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org Cc: ashok.raj@intel.com References: <20220315010300.10199-1-cathy.zhang@intel.com> <20220315010300.10199-10-cathy.zhang@intel.com> <53e7d3a3-a576-7ef1-fa2d-d170fa1172a1@fortanix.com> From: Dave Hansen Subject: Re: [RFC PATCH v2 09/10] x86/cpu: Call ENCLS[EUPDATESVN] procedure in microcode update In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/16/22 03:24, Jethro Beekman wrote: >> Doing this automatically and unconditionally during a microcode >> update seems undesirable. This requires the userland tooling that >> is coordinating the microcode update to be aware of any SGX >> enclaves that are running and possibly coordinate sequencing with >> the processes containing those enclaves. This coupling does not >> exist today. > Also, a microcode update may not affect SGX security at all and doing > the EUPDATESVN procedure may not be required for this particular > update. This case is called out specifically in the EUPDATESVN > documentation. I don't think Intel provides the metadata for the kernel to tell if an update requires an EUPDATESVN procedure or not. If this is inconvenient for you, I'd suggest reporting this to the folks at Intel who can fix it. It doesn't seem like something which they are motivated to fix.