From patchwork Fri Nov 10 22:27:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Philipson X-Patchwork-Id: 164010 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b129:0:b0:403:3b70:6f57 with SMTP id q9csp1420643vqs; Fri, 10 Nov 2023 14:29:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IEFcjEORpDRU1+dI6iYJkUgY56yt5+9L66gOc81zLqK3no4g/yJzErUHG+2ay0A8oDStMd4 X-Received: by 2002:a05:6a20:e117:b0:174:c134:81fa with SMTP id kr23-20020a056a20e11700b00174c13481famr529900pzb.17.1699655345715; Fri, 10 Nov 2023 14:29:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699655345; cv=none; d=google.com; s=arc-20160816; b=Real9wdk5IXj6xHDooFXs+hPHdL2HDN1IxELW7kJMMAHsHmEwt2jhzIMcp1XBjQZ7A oU/f3Hdg87P+GBOYp+/cf1auwe4ofT73ZsCB7E1EjKAd5v6TMygkGle1tRIzqnxa3KUl hghBnsk+3NGFm4mkHAO5RLyBqXdMd/uLGWupi4WwdOKBZ29aUFouaRZpInMXDSX4+h51 +krua10TP8S5bQvwMFMcqrFgrqCRM/fUJffxFyqjeBvtvH8Z69uLnK0UBP+c0WT8+J8U 5ezSAwQ5rTRvkOY/68GkYFzOGz7pTxCr6BF/27MkIv9BucxGxJq1kLC8rRPcEchIGWrC GTDg== 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 :dkim-signature; bh=pTEEykeNC3Q3SWEcX9fjXti3Z4HD4e/23AnxgHkyIf8=; fh=3RswKj8aEXyBJ6DCbqm+xF4dpuJnrF7Rjf3Zdj/lhD8=; b=enp6RCdKSqUQ+zvvX/7lkh0mRKWBVaK2zRIOo29f004CbFxUR6RZqg6v4ld866pgQ2 19OMmC7E4iQuGhzeALtTMERiY+Vxb5OZ5E5g59Jx3PHUccda0niorsgPMa5lLDNoOxZY egNouHy2ZfmpRCwy1KayWv1RTZvLId5RVNbIc5pueOAnRraK0lSwTrp/xl7/9oocEbci Zq3Hh/OstXDtkWPhVuiWIo8Q98sCfoHxQRmNXmWIm/1/H0s22pP+3n1Q58Y7KrHGEOsd uk6egKXCgYO6dU0z6FQFrpeeV2YIkYnhtxjkWJ/NY6Xs2V6Q8NldVXWAlVW1svUbYwXO i6UA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=m6+XqwLo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id a22-20020a170902b59600b001cc2ba37be8si285578pls.258.2023.11.10.14.29.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Nov 2023 14:29:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=m6+XqwLo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id F0F3083D2133; Fri, 10 Nov 2023 14:29:04 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344364AbjKJW2y (ORCPT + 29 others); Fri, 10 Nov 2023 17:28:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229786AbjKJW2o (ORCPT ); Fri, 10 Nov 2023 17:28:44 -0500 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 57541448C; Fri, 10 Nov 2023 14:28:36 -0800 (PST) Received: from pps.filterd (m0333521.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3AAHiI7g020606; Fri, 10 Nov 2023 22:28:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding; s=corp-2023-03-30; bh=pTEEykeNC3Q3SWEcX9fjXti3Z4HD4e/23AnxgHkyIf8=; b=m6+XqwLoXr3IN+ulTzisoWOfsRt76aviUWUUS79mCgXx9Jn13E0qnUI5bTgzx1RXJnLd 77BylWpZ5Dn2dj7NkbTR45eDTsyb1fkmbsgv7drmKX2Zso5LRalR9LOqeqv0CJ4P+jmH qKATz4OyJTbagAnCw4BNaDs9HhHb78u42scbPXbNLo8xIgMRk3LlALMb+CCjRASN9tBR TxsrpDESkiYLD4LED7QT1qBK5a2OIeuJZPce+xnA1Z2l7SAnjvEAiKRKx7KwZo3YFQIV cZydfxUbOINm4PoN0nWGKR2e5rs3zEbIOY+OoxyUW16eM/e8MRkLyCiF4OHD+Vafi3nV 4g== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3u7w23pys9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Nov 2023 22:28:05 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 3AAK2YaR023798; Fri, 10 Nov 2023 22:28:03 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3u7w28nb2c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Nov 2023 22:28:03 +0000 Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3AAMRsaG039112; Fri, 10 Nov 2023 22:28:03 GMT Received: from ovs113.us.oracle.com (ovs113.us.oracle.com [10.149.224.213]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3u7w28nayh-10 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Nov 2023 22:28:03 +0000 From: Ross Philipson To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org, linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org, kexec@lists.infradead.org, linux-efi@vger.kernel.org Cc: ross.philipson@oracle.com, dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, ardb@kernel.org, mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com, luto@amacapital.net, nivedita@alum.mit.edu, kanth.ghatraju@oracle.com, trenchboot-devel@googlegroups.com Subject: [PATCH v7 09/13] x86: Secure Launch SMP bringup support Date: Fri, 10 Nov 2023 17:27:47 -0500 Message-Id: <20231110222751.219836-10-ross.philipson@oracle.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20231110222751.219836-1-ross.philipson@oracle.com> References: <20231110222751.219836-1-ross.philipson@oracle.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-10_20,2023-11-09_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0 spamscore=0 mlxscore=0 adultscore=0 malwarescore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311100187 X-Proofpoint-GUID: Anb6ZhN2o_e8OD1XbDk3zxexIPZW-3Qs X-Proofpoint-ORIG-GUID: Anb6ZhN2o_e8OD1XbDk3zxexIPZW-3Qs X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Fri, 10 Nov 2023 14:29:05 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782217803759912625 X-GMAIL-MSGID: 1782217803759912625 On Intel, the APs are left in a well documented state after TXT performs the late launch. Specifically they cannot have #INIT asserted on them so a standard startup via INIT/SIPI/SIPI cannot be performed. Instead the early SL stub code uses MONITOR and MWAIT to park the APs. The realmode/init.c code updates the jump address for the waiting APs with the location of the Secure Launch entry point in the RM piggy after it is loaded and fixed up. As the APs are woken up by writing the monitor, the APs jump to the Secure Launch entry point in the RM piggy which mimics what the real mode code would do then jumps to the standard RM piggy protected mode entry point. Signed-off-by: Ross Philipson --- arch/x86/include/asm/realmode.h | 3 ++ arch/x86/kernel/smpboot.c | 56 +++++++++++++++++++++++++++- arch/x86/realmode/init.c | 3 ++ arch/x86/realmode/rm/header.S | 3 ++ arch/x86/realmode/rm/trampoline_64.S | 32 ++++++++++++++++ 5 files changed, 96 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h index 87e5482acd0d..339b48e2543d 100644 --- a/arch/x86/include/asm/realmode.h +++ b/arch/x86/include/asm/realmode.h @@ -38,6 +38,9 @@ struct real_mode_header { #ifdef CONFIG_X86_64 u32 machine_real_restart_seg; #endif +#ifdef CONFIG_SECURE_LAUNCH + u32 sl_trampoline_start32; +#endif }; /* This must match data at realmode/rm/trampoline_{32,64}.S */ diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 2cc2aa120b4b..6f2a5ee458ce 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -60,6 +60,7 @@ #include #include #include +#include #include #include @@ -986,6 +987,56 @@ int common_cpu_up(unsigned int cpu, struct task_struct *idle) return 0; } +#ifdef CONFIG_SECURE_LAUNCH + +static bool slaunch_is_txt_launch(void) +{ + if ((slaunch_get_flags() & (SL_FLAG_ACTIVE|SL_FLAG_ARCH_TXT)) == + (SL_FLAG_ACTIVE | SL_FLAG_ARCH_TXT)) + return true; + + return false; +} + +/* + * TXT AP startup is quite different than normal. The APs cannot have #INIT + * asserted on them or receive SIPIs. The early Secure Launch code has parked + * the APs using monitor/mwait. This will wake the APs by writing the monitor + * and have them jump to the protected mode code in the rmpiggy where the rest + * of the SMP boot of the AP will proceed normally. + */ +static void slaunch_wakeup_cpu_from_txt(int cpu, int apicid) +{ + struct sl_ap_wake_info *ap_wake_info; + struct sl_ap_stack_and_monitor *stack_monitor = NULL; + + ap_wake_info = slaunch_get_ap_wake_info(); + + stack_monitor = (struct sl_ap_stack_and_monitor *)__va(ap_wake_info->ap_wake_block + + ap_wake_info->ap_stacks_offset); + + for (unsigned int i = TXT_MAX_CPUS - 1; i >= 0; i--) { + if (stack_monitor[i].apicid == apicid) { + /* Write the monitor */ + stack_monitor[i].monitor = 1; + break; + } + } +} + +#else + +static inline bool slaunch_is_txt_launch(void) +{ + return false; +} + +static inline void slaunch_wakeup_cpu_from_txt(int cpu, int apicid) +{ +} + +#endif /* !CONFIG_SECURE_LAUNCH */ + /* * NOTE - on most systems this is a PHYSICAL apic ID, but on multiquad * (ie clustered apic addressing mode), this is a LOGICAL apic ID. @@ -1040,12 +1091,15 @@ static int do_boot_cpu(u32 apicid, int cpu, struct task_struct *idle) /* * Wake up a CPU in difference cases: + * - Intel TXT DRTM launch uses its own method to wake the APs * - Use a method from the APIC driver if one defined, with wakeup * straight to 64-bit mode preferred over wakeup to RM. * Otherwise, * - Use an INIT boot APIC message */ - if (apic->wakeup_secondary_cpu_64) + if (slaunch_is_txt_launch()) + slaunch_wakeup_cpu_from_txt(cpu, apicid); + else if (apic->wakeup_secondary_cpu_64) ret = apic->wakeup_secondary_cpu_64(apicid, start_ip); else if (apic->wakeup_secondary_cpu) ret = apic->wakeup_secondary_cpu(apicid, start_ip); diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c index 788e5559549f..b548b3376765 100644 --- a/arch/x86/realmode/init.c +++ b/arch/x86/realmode/init.c @@ -4,6 +4,7 @@ #include #include #include +#include #include #include @@ -210,6 +211,8 @@ void __init init_real_mode(void) setup_real_mode(); set_real_mode_permissions(); + + slaunch_fixup_jump_vector(); } static int __init do_init_real_mode(void) diff --git a/arch/x86/realmode/rm/header.S b/arch/x86/realmode/rm/header.S index 2eb62be6d256..3b5cbcbbfc90 100644 --- a/arch/x86/realmode/rm/header.S +++ b/arch/x86/realmode/rm/header.S @@ -37,6 +37,9 @@ SYM_DATA_START(real_mode_header) #ifdef CONFIG_X86_64 .long __KERNEL32_CS #endif +#ifdef CONFIG_SECURE_LAUNCH + .long pa_sl_trampoline_start32 +#endif SYM_DATA_END(real_mode_header) /* End signature, used to verify integrity */ diff --git a/arch/x86/realmode/rm/trampoline_64.S b/arch/x86/realmode/rm/trampoline_64.S index c9f76fae902e..526d449d5383 100644 --- a/arch/x86/realmode/rm/trampoline_64.S +++ b/arch/x86/realmode/rm/trampoline_64.S @@ -120,6 +120,38 @@ SYM_CODE_END(sev_es_trampoline_start) .section ".text32","ax" .code32 +#ifdef CONFIG_SECURE_LAUNCH + .balign 4 +SYM_CODE_START(sl_trampoline_start32) + /* + * The early secure launch stub AP wakeup code has taken care of all + * the vagaries of launching out of TXT. This bit just mimics what the + * 16b entry code does and jumps off to the real startup_32. + */ + cli + wbinvd + + /* + * The %ebx provided is not terribly useful since it is the physical + * address of tb_trampoline_start and not the base of the image. + * Use pa_real_mode_base, which is fixed up, to get a run time + * base register to use for offsets to location that do not have + * pa_ symbols. + */ + movl $pa_real_mode_base, %ebx + + LOCK_AND_LOAD_REALMODE_ESP lock_pa=1 + + lgdt tr_gdt(%ebx) + lidt tr_idt(%ebx) + + movw $__KERNEL_DS, %dx # Data segment descriptor + + /* Jump to where the 16b code would have jumped */ + ljmpl $__KERNEL32_CS, $pa_startup_32 +SYM_CODE_END(sl_trampoline_start32) +#endif + .balign 4 SYM_CODE_START(startup_32) movl %edx, %ss