Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp991190pxp; Wed, 16 Mar 2022 23:42:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynmcdHDnAGxG0rOh7N4Us8DZQb6ApatHO4m9Gz4Syt1F9CML+hqYF9aHsC/U0wIlRCYIQf X-Received: by 2002:a17:90b:4c42:b0:1bf:c572:cc45 with SMTP id np2-20020a17090b4c4200b001bfc572cc45mr14300349pjb.238.1647499361031; Wed, 16 Mar 2022 23:42:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647499361; cv=none; d=google.com; s=arc-20160816; b=O9VM0B+CaGbZLvKIhkEdRAd8wZDPjaSvU0vcSXPhH8wj+JbIDJyE4uKgaTKsA7OlRs XbHMJxSpC8MotbG6wv9xv9YHY3DFjKgt+w77vfnttp2cai2ZrJklTgpRJBkBTBCEukeg RFGlkW02rmM17jhDyYvWso2N4a9D+54ncquC/6RVL0t5COOlkjiGXGx+ZdF2p56a7Wi9 hM1166oAaxKEs6IsCtjhlgH39KOY8I63IMfawWXpP3a7eYSU7y8OZglqwAoo0T5qFU5U +d1EzxG33y0Sjm8PD/xW9TQ77JyEbR3XmY9xnZx9UdvolepwxErR/KkjrDWLEbyQYkhZ yRzQ== 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=js1+B6U7GnHXHZd9NH18Qysgu6pUa6EyQ15ilg3c36Y=; b=YrQ3YomYXQM2Y14Msbzpq5F4d32BR1XZemJ+SLM0OjLONSV47RwHs0p8vUc9rVgnva phm7sees/wNZB6ddgGRuPyKQOJmYlxscVn0h242hqhFhhhGgCg6IGp+8q8cDQFCA4i+m PrytBVbNUEqdvR0qwKOCe+hC29qQgnDfNT/B0nRXmwEgzQbul6Z2MfD9NfeuHMvT1V8D tsffvNyDeFAMfQU9eaD1MwXPGZCmf1v/+KBAwTFxtk2oA78yP0psSbssAXfVvFFcs/al S6yvEYLE9xE8bsWXy+qPHJgfp+lnYl8bgSUO/Ocw3HvFIiZq/Vllqr/N5daFrmLbnPfj dncQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GHYvDGzS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id s6-20020a17090ad48600b001c6774114a6si1836267pju.3.2022.03.16.23.42.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 23:42:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GHYvDGzS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 8CA732C8B5B; Wed, 16 Mar 2022 22:26:23 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243606AbiCPPoU (ORCPT + 99 others); Wed, 16 Mar 2022 11:44:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357294AbiCPPoO (ORCPT ); Wed, 16 Mar 2022 11:44:14 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57E3713E1A; Wed, 16 Mar 2022 08:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647445376; x=1678981376; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=Ixp7OhMpuLHg7wYtSO0RbosnpcFuNIgV6KAlovOHN5A=; b=GHYvDGzSF9aScylHgvCprSxFoYbsmMcrk642cQFTR+uaG+RPXyNYTsGl ZlExH/teClHc4NY5eAGRdDR3K6SyevC2PM2EY18Nnw9KoD8DPoT9aonME uUyDCXJacBElgK6Wgbv0Kk7obaFgLaE9gCz0bpxCO1q9bK1VERWUgD54R Beb7iGthWP8/IVZiDp4io/AHuQangmz47S97Y6mEWbgQagWaXCA6ZN3p0 73R+knLWJzOPfM4nyvxNq6KUV38EWn60Mi+L0pM7Vah+OSbrV9izuSy+Z 1/sy2qf3EuHfaAJODtE61s0AAQUv/EKHnRHn4g1/UKoIKnMVgYWWrCegZ g==; X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="281418833" X-IronPort-AV: E=Sophos;i="5.90,186,1643702400"; d="scan'208";a="281418833" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2022 08:42:40 -0700 X-IronPort-AV: E=Sophos;i="5.90,186,1643702400"; d="scan'208";a="557506601" 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:42:40 -0700 Message-ID: <947c4872-df94-0091-ebbf-b733db4bd9d6@intel.com> Date: Wed, 16 Mar 2022 08:42:33 -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: <53e7d3a3-a576-7ef1-fa2d-d170fa1172a1@fortanix.com> 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 02:46, Jethro Beekman wrote: >> +void update_cpusvn_intel(void) +{ + sgx_lock_epc(); + if >> (sgx_zap_pages()) > 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. "Today" in what? If a microcode update changes SGX behavior and bumps CPUSVN, it's fundamentally incompatible with letting enclaves continue to run. They might as well be killed. But, seriously, if you can't handle enclaves being killed every few months, don't use SGX. The architecture doesn't allow data to be persistent like normal x86. It's fundamental to the architecture. You can also think of this as a shiny new SGX *testing* feature: one that keeps enclave owners from becoming complacent and forgetting about what the SGX architecture provides.