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 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 23CA6C76196 for ; Tue, 11 Apr 2023 06:44:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681195459; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=6B/yFOZXrDIM9JwPgPlLvAzM7UC2t2+cmwujyxuFW7U=; b=IK0JbVZWsHhSUnOCPNF8/fiBOzIdfiR8cCpZnBBPPDrXpaZj9WVCpU/n4Ex4qM8EVma+gP xDEFjZaL7cfspW2Yob85PzmAH+8NHa1qFVZ2DIhtLWVpSkdhtX23TP054VxaFzzBlbQgYS OWbrao4xQ1QenqXmL+7hogdARxk6HvU= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-167-DbYNpNxAMP-mi5JESpp7_Q-1; Tue, 11 Apr 2023 02:44:15 -0400 X-MC-Unique: DbYNpNxAMP-mi5JESpp7_Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1AD301C06904; Tue, 11 Apr 2023 06:44:12 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 046CAE09080; Tue, 11 Apr 2023 06:44:12 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id D529A1946A6C; Tue, 11 Apr 2023 06:44:10 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 7ECBF1946586 for ; Mon, 10 Apr 2023 23:12:48 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 72172C15BB8; Mon, 10 Apr 2023 23:12:48 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast03.extmail.prod.ext.rdu2.redhat.com [10.11.55.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6A35AC15BA0 for ; Mon, 10 Apr 2023 23:12:48 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F5AB811E7C for ; Mon, 10 Apr 2023 23:12:48 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-675-gi-JSF0_PAOMUBgPGhTMHw-3; Mon, 10 Apr 2023 19:12:44 -0400 X-MC-Unique: gi-JSF0_PAOMUBgPGhTMHw-3 X-IronPort-AV: E=McAfee;i="6600,9927,10676"; a="340962543" X-IronPort-AV: E=Sophos;i="5.98,335,1673942400"; d="scan'208";a="340962543" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Apr 2023 16:11:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10676"; a="757608002" X-IronPort-AV: E=Sophos;i="5.98,335,1673942400"; d="scan'208";a="757608002" Received: from chang-linux-3.sc.intel.com ([172.25.66.173]) by fmsmga004.fm.intel.com with ESMTP; 10 Apr 2023 16:11:40 -0700 From: "Chang S. Bae" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, dm-devel@redhat.com Date: Mon, 10 Apr 2023 15:59:29 -0700 Message-Id: <20230410225936.8940-6-chang.seok.bae@intel.com> In-Reply-To: <20230410225936.8940-1-chang.seok.bae@intel.com> References: <20220112211258.21115-1-chang.seok.bae@intel.com> <20230410225936.8940-1-chang.seok.bae@intel.com> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mailman-Approved-At: Tue, 11 Apr 2023 06:44:09 +0000 Subject: [dm-devel] [PATCH v6 05/12] x86/msr-index: Add MSRs for Key Locker internal wrapping key X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: x86@kernel.org, herbert@gondor.apana.org.au, ardb@kernel.org, chang.seok.bae@intel.com, dave.hansen@linux.intel.com, dan.j.williams@intel.com, mingo@kernel.org, ebiggers@kernel.org, lalithambika.krishnakumar@intel.com, Peter Zijlstra , Ingo Molnar , Borislav Petkov , luto@kernel.org, "H. Peter Anvin" , bernie.keany@intel.com, tglx@linutronix.de, bp@suse.de, gmazyland@gmail.com, charishma1.gairuboyina@intel.com MIME-Version: 1.0 Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: intel.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The CPU state that contains the internal wrapping key is in the same power domain as the cache. So any sleep state that would invalidate the cache (like S3) also invalidates the state of the wrapping key. But, since the state is inaccessible to software, it needs a special mechanism to save and restore the key during deep sleep. A set of new MSRs are provided as an abstract interface to save and restore the wrapping key, and to check the key status. The wrapping key is saved in a platform-scoped state of non-volatile media. The backup itself and its path from the CPU are encrypted and integrity protected. But this storage's non-volatility is not architecturally guaranteed across off states, such as S5 and G3. The MSRs will be used to back up the key for S3/4 sleep states. Then the kernel code writes one of them to restore the key in each CPU state. Signed-off-by: Chang S. Bae Reviewed-by: Dan Williams Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Peter Zijlstra Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from RFC v2: * Update the changelog. (Dan Williams) * Rename the MSRs. (Dan Williams) --- arch/x86/include/asm/msr-index.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index ad35355ee43e..4fa3b9e26162 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -1115,4 +1115,10 @@ * a #GP */ +/* MSRs for managing an internal wrapping key for Key Locker. */ +#define MSR_IA32_IWKEY_COPY_STATUS 0x00000990 +#define MSR_IA32_IWKEY_BACKUP_STATUS 0x00000991 +#define MSR_IA32_BACKUP_IWKEY_TO_PLATFORM 0x00000d91 +#define MSR_IA32_COPY_IWKEY_TO_LOCAL 0x00000d92 + #endif /* _ASM_X86_MSR_INDEX_H */ -- 2.17.1 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel