From patchwork Sun Apr 7 23:04:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Chang S. Bae" X-Patchwork-Id: 13620300 X-Patchwork-Delegate: herbert@gondor.apana.org.au Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 825443FB83; Sun, 7 Apr 2024 23:20:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712532049; cv=none; b=HwkggrxWYD3YGS7OZsSioPmfLZkl0qn4CcpiZmzSD3JL0RKl4h5SJ2+VeWZme/BpSZXX2hlpqKjzrCVRySFq2ICDCrPAmn5I1OYKOib2i3WsIMnW5voNzN8zv+H2DzIqLd93h67QUSxQdx7CrvBm5eTjuw1QJw6YmZFkW2NVnwI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712532049; c=relaxed/simple; bh=Guz77wGX67222+ZdfWG+k8ArwL5scaBgVJjI+9Ueoug=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=m70iMptQq8FBwP5nTlKQNPfhZVJ0K50XTRMmJCTp5mfhJI6qw/QmMwL/cgDbQXKPYneMB42G1e93RimPuEAzKezEM+Q+W4UovrXEOsp7LV0/9DRLCrNz1AIVd4Z+V6adguiHSfrV5MMnAE8fLgpxqx/qbDcQiKi5WF76+p0a+xc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=AVyZdntV; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="AVyZdntV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712532047; x=1744068047; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Guz77wGX67222+ZdfWG+k8ArwL5scaBgVJjI+9Ueoug=; b=AVyZdntVJAOkH2DfIs5EbmHVVj2WrcJI6qvjIPd/bBFe4+XICUjtSuQe XbfJ2MOz1bgFSFyJFS71diSCvvdScNOW9o9/sgl6qaHmLGTV86xYhlKwA SSz/a4JggLnnRIIV/WViajdwKXa/v/5P4oNUDCxARFaUMdgbymKRtWHW2 gg2HSCgUUsSbavMSHrYeqjhPQdFRWEDOOES0P9LrcPOjC5fcYxVYoTAas l8shFaBYQgL9V0x4r7Qwx0dWqunEBANUNRDA8FPqypnpF1DtslBhGMJql F2+4M+kylDjIPIHoKOXIydX9KlpL4yLxnnUGwjBBds6JvRAzyon/9/Yy1 g==; X-CSE-ConnectionGUID: FyJb4sHVTGGPpKFD653Qwg== X-CSE-MsgGUID: YyTUCWHaQe+V5JlkduEAhg== X-IronPort-AV: E=McAfee;i="6600,9927,11037"; a="11570832" X-IronPort-AV: E=Sophos;i="6.07,185,1708416000"; d="scan'208";a="11570832" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2024 16:20:47 -0700 X-CSE-ConnectionGUID: TaIMkT2MRMaENMvjVc8q6A== X-CSE-MsgGUID: MxY1RVtOQjGqnm+dSNpECw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,185,1708416000"; d="scan'208";a="20269732" Received: from chang-linux-3.sc.intel.com ([172.25.66.175]) by orviesa008.jf.intel.com with ESMTP; 07 Apr 2024 16:20:45 -0700 From: "Chang S. Bae" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org Cc: ebiggers@kernel.org, luto@kernel.org, dave.hansen@linux.intel.com, tglx@linutronix.de, bp@alien8.de, mingo@kernel.org, x86@kernel.org, herbert@gondor.apana.org.au, ardb@kernel.org, elliott@hpe.com, dan.j.williams@intel.com, bernie.keany@intel.com, charishma1.gairuboyina@intel.com, chang.seok.bae@intel.com, Dave Hansen Subject: [PATCH v9a 07/14] x86/cpu/keylocker: Load a wrapping key at boot time Date: Sun, 7 Apr 2024 16:04:53 -0700 Message-Id: <20240407230453.912322-1-chang.seok.bae@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240329015346.635933-8-chang.seok.bae@intel.com> References: <20240329015346.635933-8-chang.seok.bae@intel.com> Precedence: bulk X-Mailing-List: linux-crypto@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 The wrapping key is an entity to encode a clear text key into a key handle. This key is a pivot in protecting user keys. So the value has to be randomized before being loaded in the software-invisible CPU state. The wrapping key needs to be established before the first user. Given that the only proposed Linux use case for Key Locker is dm-crypt, the feature could be lazily enabled before the first dm-crypt user arrives. But there is no precedent for late enabling of CPU features and it adds maintenance burden without demonstrative benefit outside of minimizing the visibility of Key Locker to userspace. Therefore, generate random bytes and load them at boot time, involving clobbering XMM registers. Perform this process under arch_initcall(), ensuring that it occurs after FPU initialization. Finally, flush out random bytes after loading. Given that the Linux Key Locker support is only intended for bare metal dm-crypt use, and that switching wrapping key per virtual machine is impractical, explicitly skip this setup in the X86_FEATURE_HYPERVISOR case. Signed-off-by: Chang S. Bae Cc: Eric Biggers Cc: Dave Hansen Cc: "Elliott, Robert (Servers)" Cc: Dan Williams --- Changes from v9: * Include 'tlbflush.h' back, which was once removed by mistake. --- arch/x86/kernel/Makefile | 1 + arch/x86/kernel/keylocker.c | 78 +++++++++++++++++++++++++++++++++++++ 2 files changed, 79 insertions(+) create mode 100644 arch/x86/kernel/keylocker.c diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 74077694da7d..d105e5785b90 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -137,6 +137,7 @@ obj-$(CONFIG_PERF_EVENTS) += perf_regs.o obj-$(CONFIG_TRACING) += tracepoint.o obj-$(CONFIG_SCHED_MC_PRIO) += itmt.o obj-$(CONFIG_X86_UMIP) += umip.o +obj-$(CONFIG_X86_KEYLOCKER) += keylocker.o obj-$(CONFIG_UNWINDER_ORC) += unwind_orc.o obj-$(CONFIG_UNWINDER_FRAME_POINTER) += unwind_frame.o diff --git a/arch/x86/kernel/keylocker.c b/arch/x86/kernel/keylocker.c new file mode 100644 index 000000000000..8569b92971da --- /dev/null +++ b/arch/x86/kernel/keylocker.c @@ -0,0 +1,78 @@ +// SPDX-License-Identifier: GPL-2.0-only + +/* + * Setup Key Locker feature and support the wrapping key management. + */ + +#include +#include + +#include +#include +#include +#include + +static struct iwkey wrapping_key __initdata; + +static void __init generate_keylocker_data(void) +{ + get_random_bytes(&wrapping_key.integrity_key, sizeof(wrapping_key.integrity_key)); + get_random_bytes(&wrapping_key.encryption_key, sizeof(wrapping_key.encryption_key)); +} + +static void __init destroy_keylocker_data(void) +{ + memzero_explicit(&wrapping_key, sizeof(wrapping_key)); +} + +/* + * For loading the wrapping key into each CPU, the feature bit is set + * in the control register and FPU context management is performed. + */ +static void __init load_keylocker(struct work_struct *unused) +{ + cr4_set_bits(X86_CR4_KEYLOCKER); + + kernel_fpu_begin(); + load_xmm_iwkey(&wrapping_key); + kernel_fpu_end(); +} + +static int __init init_keylocker(void) +{ + u32 eax, ebx, ecx, edx; + + if (!cpu_feature_enabled(X86_FEATURE_KEYLOCKER)) + goto disable; + + if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) { + pr_debug("x86/keylocker: Not compatible with a hypervisor.\n"); + goto clear_cap; + } + + cr4_set_bits(X86_CR4_KEYLOCKER); + + /* AESKLE depends on CR4.KEYLOCKER */ + cpuid_count(KEYLOCKER_CPUID, 0, &eax, &ebx, &ecx, &edx); + if (!(ebx & KEYLOCKER_CPUID_EBX_AESKLE) || + !(eax & KEYLOCKER_CPUID_EAX_SUPERVISOR)) { + pr_debug("x86/keylocker: Not fully supported.\n"); + goto clear_cap; + } + + generate_keylocker_data(); + schedule_on_each_cpu(load_keylocker); + destroy_keylocker_data(); + + pr_info_once("x86/keylocker: Enabled.\n"); + return 0; + +clear_cap: + setup_clear_cpu_cap(X86_FEATURE_KEYLOCKER); + pr_info_once("x86/keylocker: Disabled.\n"); +disable: + cr4_clear_bits(X86_CR4_KEYLOCKER); + return -ENODEV; +} + +arch_initcall(init_keylocker); From patchwork Sun Apr 7 23:04:32 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Chang S. Bae" X-Patchwork-Id: 13620298 X-Patchwork-Delegate: herbert@gondor.apana.org.au Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E852C1E893; Sun, 7 Apr 2024 23:20:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712532030; cv=none; b=X+3+V7z0vp0TAunwUIttnkMfxw41iS++kx4JOxi9JLAg1uoylGRlvcSkHhWk8Fi0YLG2/0lAVeVh/39jwBzAczLIK3b4IqnKwLy3VGAedv0vzsQNR131oBOxahcPORL6QOdGxpoCUsLc27WqAQyhge3WMZrp1qsCdM3rYvTApM0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712532030; c=relaxed/simple; bh=Y/j0qNmFRDBaKOS+TGqHbCS5rou+RE1grg9TlB3OhyY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=hGd9S1N4tTL8fLab3w2mC5v5G9Rz0U4eXgfImTTaWg2GW1d+v4JEg5JlBubeM10FNtLySafXapu9xFrptQEclZWjpMnYqKxZGLEb/fxUzcI4cc20547kwoxjxVZfiRE49qXfNohj36QFujvDiFtvGcHI7cAWkPV7koI3MUtVGnk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jEHELQS3; arc=none smtp.client-ip=198.175.65.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jEHELQS3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712532027; x=1744068027; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Y/j0qNmFRDBaKOS+TGqHbCS5rou+RE1grg9TlB3OhyY=; b=jEHELQS3IPTwloyjvcSlcY1zjF2ldljFZvTOrz25AVLWoADg5YdTADOm hY+22hLFP60coBEg4YSORfjvVahMSYkL4Ko61eIrY1hPc25WuRqYV4ltl 9MgGa4Jv27Fmz0ezUxSNmsZE97h8GNvE0Jx+HQGLmjgu/f2uEjBO+9nt3 8XIlIcvlaNq9lAc4/vtWGZK33moB5kBSR4jC9gqM9QzqqOutxTHi+H0d8 Fw/ECofzBVDC6NCx3IesSGjRTBrTqjpoBFfxaXWUfNzGWgs1Pj5INPfn5 4DfWn8lDvua93IIdA6RTywL15stgbFWKAS5NZ0JDKPC/jVCRgyPcb7q9O w==; X-CSE-ConnectionGUID: QR732DZOQ82jVky8OYvo1g== X-CSE-MsgGUID: rT5Z06ylTGuZTak04ViHsA== X-IronPort-AV: E=McAfee;i="6600,9927,11037"; a="7704012" X-IronPort-AV: E=Sophos;i="6.07,185,1708416000"; d="scan'208";a="7704012" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2024 16:20:27 -0700 X-CSE-ConnectionGUID: 9waKUil4QDaN6QUvkUIM5g== X-CSE-MsgGUID: i9QBSZRrQ4Sg4FoWsI7k0Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,185,1708416000"; d="scan'208";a="50678941" Received: from chang-linux-3.sc.intel.com ([172.25.66.175]) by orviesa002.jf.intel.com with ESMTP; 07 Apr 2024 16:20:27 -0700 From: "Chang S. Bae" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org Cc: ebiggers@kernel.org, luto@kernel.org, dave.hansen@linux.intel.com, tglx@linutronix.de, bp@alien8.de, mingo@kernel.org, x86@kernel.org, herbert@gondor.apana.org.au, ardb@kernel.org, elliott@hpe.com, dan.j.williams@intel.com, bernie.keany@intel.com, charishma1.gairuboyina@intel.com, chang.seok.bae@intel.com, Dave Hansen , Pawan Gupta Subject: [PATCH v9a 10/14] x86/cpu/keylocker: Check Gather Data Sampling mitigation Date: Sun, 7 Apr 2024 16:04:32 -0700 Message-Id: <20240407230432.912290-1-chang.seok.bae@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240329065742.fc5of75e776y2g4b@desk> References: <20240329065742.fc5of75e776y2g4b@desk> Precedence: bulk X-Mailing-List: linux-crypto@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Gather Data Sampling is a transient execution side channel issue in some CPU models. The stale data in registers is not guaranteed as secure when this vulnerability is not addressed. In the Key Locker usage during AES transformations, the temporary storage of the original key in registers poses a risk. The key material can be staled in some implementations, leading to susceptibility to leakage of the AES key. To mitigate this vulnerability, a qualified microcode image must be applied. Add code to ensure that the mitigation is installed and securely locked. Disable the feature, otherwise. Expand gds_ucode_mitigated() to examine the lock state. Signed-off-by: Chang S. Bae Cc: Dave Hansen Cc: Pawan Gupta --- Changes from v9: * Removed MSR reads and utilized the helper function. (Pawan Gupta) Alternatively, 'gds_mitigation' can be exported and referenced directly. Using 'gds_mitigation == GDS_MITIGATION_FULL_LOCKED' may also be readable. However, it was opted to expand gds_ucode_mitigated() for consistency, as it is already established. Note that this approach aligns with Intel's guidance, as the bugs.c code checks the following MSR bits: "Intel recommends that system software does not enable Key Locker (by setting CR4.KL) unless the GDS mitigation is enabled (IA32_MCU_OPT_CTRL[GDS_MITG_DIS] (bit 4) is 0) and locked (IA32_MCU_OPT_CTRL [GDS_MITG_LOCK](bit 5) is 1)." For more information, refer to Intel's technical documentation on Gather Data Sampling: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html --- arch/x86/include/asm/processor.h | 7 ++++++- arch/x86/kernel/cpu/bugs.c | 5 ++++- arch/x86/kernel/keylocker.c | 12 ++++++++++++ arch/x86/kvm/x86.c | 2 +- 4 files changed, 23 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 811548f131f4..74eaa3a2b85b 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -721,7 +721,12 @@ enum mds_mitigations { MDS_MITIGATION_VMWERV, }; -extern bool gds_ucode_mitigated(void); +enum mitigation_info { + MITG_FULL, + MITG_LOCKED, +}; + +extern bool gds_ucode_mitigated(enum mitigation_info mitg); /* * Make previous memory operations globally visible before diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index e7ba936d798b..80f6e70619cb 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -752,8 +752,11 @@ static const char * const gds_strings[] = { [GDS_MITIGATION_HYPERVISOR] = "Unknown: Dependent on hypervisor status", }; -bool gds_ucode_mitigated(void) +bool gds_ucode_mitigated(enum mitigation_info mitg) { + if (mitg == MITG_LOCKED) + return gds_mitigation == GDS_MITIGATION_FULL_LOCKED; + return (gds_mitigation == GDS_MITIGATION_FULL || gds_mitigation == GDS_MITIGATION_FULL_LOCKED); } diff --git a/arch/x86/kernel/keylocker.c b/arch/x86/kernel/keylocker.c index 1e81d0704eea..23cf4a235f11 100644 --- a/arch/x86/kernel/keylocker.c +++ b/arch/x86/kernel/keylocker.c @@ -113,6 +113,15 @@ void restore_keylocker(void) valid_wrapping_key = false; } +/* Check if Key Locker is secure enough to be used. */ +static bool __init secure_keylocker(void) +{ + if (boot_cpu_has_bug(X86_BUG_GDS) && !gds_ucode_mitigated(MITG_LOCKED)) + return false; + + return true; +} + static int __init init_keylocker(void) { u32 eax, ebx, ecx, edx; @@ -126,6 +135,9 @@ static int __init init_keylocker(void) goto clear_cap; } + if (!secure_keylocker()) + goto clear_cap; + cr4_set_bits(X86_CR4_KEYLOCKER); /* AESKLE depends on CR4.KEYLOCKER */ diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 47d9f03b7778..4ab50e95fdb5 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1675,7 +1675,7 @@ static u64 kvm_get_arch_capabilities(void) */ } - if (!boot_cpu_has_bug(X86_BUG_GDS) || gds_ucode_mitigated()) + if (!boot_cpu_has_bug(X86_BUG_GDS) || gds_ucode_mitigated(MITG_FULL)) data |= ARCH_CAP_GDS_NO; return data; From patchwork Sun Apr 7 23:04:43 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Chang S. Bae" X-Patchwork-Id: 13620299 X-Patchwork-Delegate: herbert@gondor.apana.org.au Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 233EC45951; Sun, 7 Apr 2024 23:20:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712532040; cv=none; b=N/nrTWkL6K758rf7qC4DGni2JHY37kxgh/PuuzXuHjf8i7S+mwOm5/AzLEvfWqLeohBC7y2BVJbh8s9gcRa7oZniPFUGzPKtBqlvk1ZpqmxagyLdfg5+q+nivSJ0vNznQl0a+/BG4LISEPInxjCozcjM+FIsrAWE2mGl9mHsTkM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712532040; c=relaxed/simple; bh=9QDRwKQcp+Etmkpf3eb7UKBNnIpkotHX2gTPqHqq1G4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=kPaT7DFI3qzVj2MzqseS4Vv3rGFRdjClxjNBOGwMERDxlggIG0++Kl8mUAIkWUiDH1OfARWtTuMyHSG9Lsy1hlnLwqrbZyZhyqrPU03AJEcR8qxh5trAgNuTNPLQ/0Kx3fgQ0jtcHboEOGfOrBV1kdTHrQH1S1kvMx15rDQYQhw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=m6N5VUnc; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="m6N5VUnc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712532038; x=1744068038; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9QDRwKQcp+Etmkpf3eb7UKBNnIpkotHX2gTPqHqq1G4=; b=m6N5VUncNf7XJKl1gxknbYz1/+zhY4/xBZTHl3x6yXPTu2XfqsqV93lA +xl9y8ZGrmwi9ZafStyUJ8Uy8Cb+bMZMk+pbeKZxiX5bP6if7ylKj6720 A8Aas6ztVP1nOdJqkiYBeWGyd+bbCb3hDil2sThznBAjgkV1e4Qd7emwH QSnu2Rq8RO7jBGUuwQoIE/a7KyTazY5Q+opmLHFx/+oj//DqDZXMz1kyd g7+7eyan205SNry67Co5rcy/ruCN/PFHqJIR5w87jVY3UoqYv31rLyBnZ ppQV78QK1I/CwNHTN1bkF4bZkN0b00FJUe8anqScwKLzryrRZwounnsG+ g==; X-CSE-ConnectionGUID: cnGsA71lQTaLNxKoBC6voQ== X-CSE-MsgGUID: H+/RGCBgRZeWvtYKb/IiFA== X-IronPort-AV: E=McAfee;i="6600,9927,11037"; a="11570820" X-IronPort-AV: E=Sophos;i="6.07,185,1708416000"; d="scan'208";a="11570820" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Apr 2024 16:20:37 -0700 X-CSE-ConnectionGUID: AXJleEeiRaqTLCoYOQ1O5A== X-CSE-MsgGUID: jigVE6a0TSylKehw1XiG/g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,185,1708416000"; d="scan'208";a="20269689" Received: from chang-linux-3.sc.intel.com ([172.25.66.175]) by orviesa008.jf.intel.com with ESMTP; 07 Apr 2024 16:20:35 -0700 From: "Chang S. Bae" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org Cc: ebiggers@kernel.org, luto@kernel.org, dave.hansen@linux.intel.com, tglx@linutronix.de, bp@alien8.de, mingo@kernel.org, x86@kernel.org, herbert@gondor.apana.org.au, ardb@kernel.org, elliott@hpe.com, dan.j.williams@intel.com, bernie.keany@intel.com, charishma1.gairuboyina@intel.com, chang.seok.bae@intel.com, Dave Hansen , Pawan Gupta Subject: [PATCH v9a 11/14] x86/cpu/keylocker: Check Register File Data Sampling mitigation Date: Sun, 7 Apr 2024 16:04:43 -0700 Message-Id: <20240407230443.912306-1-chang.seok.bae@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240329062057.kt5dkoffbkkxdt7x@desk> References: <20240329062057.kt5dkoffbkkxdt7x@desk> Precedence: bulk X-Mailing-List: linux-crypto@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 The Register File Data Sampling vulnerability may allow malicious userspace programs to infer stale kernel register data, potentially exposing sensitive key values, including AES keys. To address this vulnerability, a microcode update needs to be applied to the CPU, which modifies the VERW instruction to flush the affected CPU buffers. Reference the 'rfds_mitigation' variable to check the mitigation status. Do not enable Key Locker on CPUs affected by the vulnerability but lacking mitigation. Signed-off-by: Chang S. Bae Cc: Dave Hansen Cc: Pawan Gupta --- Changes from v9: * Remove the helper function and simplify the code by directly reading the status variable. (Pawan Gupta) Note that this code change aligns with mitigation guidance, which recommends: "Software loading Key Locker keys using LOADIWKEY should execute a VERW to clear registers before transitioning to untrusted code to prevent later software from inferring the loaded key." For more information, refer to Intel's guidance on Register File Data Sampling: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/register-file-data-sampling.html --- arch/x86/include/asm/processor.h | 8 ++++++++ arch/x86/kernel/cpu/bugs.c | 8 +------- arch/x86/kernel/keylocker.c | 3 +++ 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 74eaa3a2b85b..b823163f4786 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -728,6 +728,14 @@ enum mitigation_info { extern bool gds_ucode_mitigated(enum mitigation_info mitg); +enum rfds_mitigations { + RFDS_MITIGATION_OFF, + RFDS_MITIGATION_VERW, + RFDS_MITIGATION_UCODE_NEEDED, +}; + +extern enum rfds_mitigations rfds_mitigation; + /* * Make previous memory operations globally visible before * a WRMSR. diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 80f6e70619cb..a2ba1a0ef872 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -483,14 +483,8 @@ early_param("mmio_stale_data", mmio_stale_data_parse_cmdline); #undef pr_fmt #define pr_fmt(fmt) "Register File Data Sampling: " fmt -enum rfds_mitigations { - RFDS_MITIGATION_OFF, - RFDS_MITIGATION_VERW, - RFDS_MITIGATION_UCODE_NEEDED, -}; - /* Default mitigation for Register File Data Sampling */ -static enum rfds_mitigations rfds_mitigation __ro_after_init = +enum rfds_mitigations rfds_mitigation __ro_after_init = IS_ENABLED(CONFIG_MITIGATION_RFDS) ? RFDS_MITIGATION_VERW : RFDS_MITIGATION_OFF; static const char * const rfds_strings[] = { diff --git a/arch/x86/kernel/keylocker.c b/arch/x86/kernel/keylocker.c index 23cf4a235f11..09876693414c 100644 --- a/arch/x86/kernel/keylocker.c +++ b/arch/x86/kernel/keylocker.c @@ -119,6 +119,9 @@ static bool __init secure_keylocker(void) if (boot_cpu_has_bug(X86_BUG_GDS) && !gds_ucode_mitigated(MITG_LOCKED)) return false; + if (boot_cpu_has_bug(X86_BUG_RFDS) && rfds_mitigation != RFDS_MITIGATION_VERW) + return false; + return true; }