Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp382964pxt; Wed, 4 Aug 2021 13:48:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfrlSb1jU4Mti+3HE5L2Ta9uj5al43n4ZIP3Mt3wHxskrVFgJr8ZxAlSjT6UK/fGmMDLR6 X-Received: by 2002:a05:6402:28f:: with SMTP id l15mr1850918edv.131.1628110127729; Wed, 04 Aug 2021 13:48:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628110127; cv=none; d=google.com; s=arc-20160816; b=C61/eD2DmAAysDQUQ9tyAKLFQ4c64EwLClVuD4k7Go3kdNgIKe4Q5ceykoedJDyM07 6lB7o9c+JqGioWKHYPL9xgE26IwMm8quMCQErF6Z3MBODJsPBmyyDqkKKPs1N6SuOexH 6Y7PKahXDkfW3PkI/019i2DXIS9WHAlxXKzQiaPHXoysLVJTAXRXZ+TOzSk+LG4WXiiU k7xlOcA2zhD3xJuD/LbuPIE9CYYo4foEhVYXfjY83Gx6e/AtBgO3K1NiEBJj8qeRIdKk bfBatAPpJFso8t+jyHTP46CZsdhBCVFbycKs0aKY/jXgW7TI/OQMpu1AWj6NDqsxn0mg WJEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=IKS4Hn5DSpVj9yxHz6IzAk9fTpbsDZ966dN9Wh0yrRg=; b=k405ASfXrW/xsUEZmDXjOJhldrpkdIcET91/T/NH64dKUn15wPhDCShSaOPvqhLImD I1g/jUsNuMBZGi9gpNqEWWmPJoJzzgZtRi6stAOM8AE5sup40f+UPMk7acb7tZZ9uCxV yV4Q3wME0+AVuWZX4gJ+3WrXx5lK1CGSBiuj5nwfVoBd/82LCEjj0hrgTU0LgbkdOeRL 9Yggef4K+2OerVJjZukQ8e+hSV/rfBA61teX7q2VMqrLh96h9pYbTAOWk64o+ar6R8Ey aH1T/igzAfTn3qkS2X4gXbd5j0RQ2RRQdPUsYyyGT2seRzF5qGCiPygcFH0rLhw0iSCh Y2hg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v2si3061740ejy.465.2021.08.04.13.48.23; Wed, 04 Aug 2021 13:48:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240241AbhHDSPX (ORCPT + 99 others); Wed, 4 Aug 2021 14:15:23 -0400 Received: from mga02.intel.com ([134.134.136.20]:49808 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240163AbhHDSPI (ORCPT ); Wed, 4 Aug 2021 14:15:08 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10066"; a="201151116" X-IronPort-AV: E=Sophos;i="5.84,295,1620716400"; d="scan'208";a="201151116" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2021 11:14:52 -0700 X-IronPort-AV: E=Sophos;i="5.84,295,1620716400"; d="scan'208";a="503075884" Received: from mjkendri-mobl.amr.corp.intel.com (HELO skuppusw-desk1.amr.corp.intel.com) ([10.254.17.117]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2021 11:14:51 -0700 From: Kuppuswamy Sathyanarayanan To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski Cc: Peter H Anvin , Dave Hansen , Tony Luck , Dan Williams , Andi Kleen , Kirill Shutemov , Sean Christopherson , Kuppuswamy Sathyanarayanan , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v5 11/12] x86/tdx: Don't write CSTAR MSR on Intel Date: Wed, 4 Aug 2021 11:13:28 -0700 Message-Id: <20210804181329.2899708-12-sathyanarayanan.kuppuswamy@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210804181329.2899708-1-sathyanarayanan.kuppuswamy@linux.intel.com> References: <20210804181329.2899708-1-sathyanarayanan.kuppuswamy@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andi Kleen On Intel CPUs writing the CSTAR MSR is not really needed. Syscalls from 32bit work using SYSENTER and 32bit SYSCALL is an illegal opcode. But the kernel did write it anyways even though it was ignored by the CPU. Inside a TDX guest this actually leads to a #GP. While the #GP is caught and recovered from, it prints an ugly message at boot. Do not write the CSTAR MSR on Intel CPUs. Signed-off-by: Andi Kleen --- arch/x86/kernel/cpu/common.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 64b805bd6a54..d936f0e4ec51 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1752,7 +1752,13 @@ void syscall_init(void) wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64); #ifdef CONFIG_IA32_EMULATION - wrmsrl(MSR_CSTAR, (unsigned long)entry_SYSCALL_compat); + /* + * CSTAR is not needed on Intel because it doesn't support + * 32bit SYSCALL, but only SYSENTER. On a TDX guest + * it leads to a #GP. + */ + if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) + wrmsrl(MSR_CSTAR, (unsigned long)entry_SYSCALL_compat); /* * This only works on Intel CPUs. * On AMD CPUs these MSRs are 32-bit, CPU truncates MSR_IA32_SYSENTER_EIP. @@ -1764,7 +1770,8 @@ void syscall_init(void) (unsigned long)(cpu_entry_stack(smp_processor_id()) + 1)); wrmsrl_safe(MSR_IA32_SYSENTER_EIP, (u64)entry_SYSENTER_compat); #else - wrmsrl(MSR_CSTAR, (unsigned long)ignore_sysret); + if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) + wrmsrl(MSR_CSTAR, (unsigned long)ignore_sysret); wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)GDT_ENTRY_INVALID_SEG); wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL); wrmsrl_safe(MSR_IA32_SYSENTER_EIP, 0ULL); -- 2.25.1