Received: by 2002:a05:6a10:144:0:0:0:0 with SMTP id 4csp455915pxw; Fri, 8 Apr 2022 11:42:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoAZalgI78gbnMSIsBfb1tZLM8IdZbRFoj2ieGaAbY3iTcwek4n1oL0xf/Jxri1AIusnt6 X-Received: by 2002:a05:6a00:999:b0:4fa:964f:9021 with SMTP id u25-20020a056a00099900b004fa964f9021mr21007365pfg.34.1649443323698; Fri, 08 Apr 2022 11:42:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649443323; cv=none; d=google.com; s=arc-20160816; b=kviiAMcHHHjFBuyfrqLbZfOuc+hDpD/16VY6zy1Kxw7fgGVXhC6SUUciT13LQapRfL 0Ql8/SvDn+uBxM6t3x5ZI3dPyZCuQDFT83GJLaMz01uvEi2xi+03cKn9urojaQ1QCp1v yrqW0IwfXGyJsHf8hMj0hhxJH1I2npYNFDBnqwekZvuEbL5cC18m0M2W1xiMWVhG+JJc n7VIBBHHeKk33Kf0E9n+pNMEqTfESZkGibPiBg5O3jl9OV1RBZkwXHwLTrZFKZBGIwnr cfXSMjL6r3EZqHIPqfKKSJ84bfDjzPr8yg47Bje5/R14durcl1P7UJ2VVT/6w3lTMesj Kwog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=iCdq15bEqQNm/pFXDaqlmavp/KSNQHpopp15hvX8rxg=; b=uJp/0g9ZphZgypVNj/Ulf+MgTej5GhWBD1BHYHyddbtfi81+byhp3MIzmX/aCb6rKu +yC2xdjhxexByOPdAZ87TnefP9B4K793ogQjIPaHWU5L5JkYJhLYEid8SfKQYcJQ8SJd jUlfUYyGPteUn6SxgbTUad738frXXCCbRgSAeNkphAfXy8tZV7fhiitjEU4Sgf8cV4Sv /3N8xKq6dmtQcCBgDBv/ONADywMGzW3h9esb2dyx52YAiUWB3HyGpZ3WUmZQXIjKGb6h SoJp6pZy3FgY9aZvTyRHMIPzGjLrG+OfcG34IrOW3y9alCaStSNKX5r/s/ZeayohmNJj 49ow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=YhDkLCQq; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=Gf0zKFxm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cb4-20020a056a00430400b004fa950150a6si1852728pfb.113.2022.04.08.11.41.48; Fri, 08 Apr 2022 11:42:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=YhDkLCQq; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=Gf0zKFxm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232757AbiDHJPK (ORCPT + 99 others); Fri, 8 Apr 2022 05:15:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232752AbiDHJLk (ORCPT ); Fri, 8 Apr 2022 05:11:40 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39E6C1AF504; Fri, 8 Apr 2022 02:09:02 -0700 (PDT) Date: Fri, 08 Apr 2022 09:08:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649408940; h=from:from:sender:sender:reply-to: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; bh=iCdq15bEqQNm/pFXDaqlmavp/KSNQHpopp15hvX8rxg=; b=YhDkLCQq8M43xWNUF0WoIZebjaidYuBeVrkALdbNz+wfI7u3mm6rreGaaVHhWOuy5qXYiK 4u6Jes85nIRIxb5pTbOZzh04ewmLyQIQMbdBHuvIHJxxcv1d84L0ha8f2QIy3qFtYa+NvR lf1J25sZUUJnuZgkt8fli+y2jjJ+GguGExdIotuc55vPcVMpvvZEmW3mBRJBNRs8n59qbY UrKxakdgJwElf8AmFatg8yhOL+UqOfdf9MHSGbm1E7pRuIw3Ba7PhB6JWRXGcCvbenxlVv CrfRPguZuDtslSaI3mQzkX7c320LkrKMblrX5H97K5duHHjeeuLTVs7VlwaNcQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649408940; h=from:from:sender:sender:reply-to: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; bh=iCdq15bEqQNm/pFXDaqlmavp/KSNQHpopp15hvX8rxg=; b=Gf0zKFxmaOsIT54ouXjxtc2/rWizn0CO63nrIAcy6XuBr0K6ZxDUJe8lcG1xj01ZgDlqR1 yROdbVDkkFawsTBg== From: "tip-bot2 for Michael Roth" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/sev] x86/head/64: Re-enable stack protection Cc: Joerg Roedel , Michael Roth , Brijesh Singh , Borislav Petkov , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20220307213356.2797205-24-brijesh.singh@amd.com> References: <20220307213356.2797205-24-brijesh.singh@amd.com> MIME-Version: 1.0 Message-ID: <164940893965.389.13743968691185780967.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 The following commit has been merged into the x86/sev branch of tip: Commit-ID: 469693d8f62299709e8ba56d8fb3da9ea990213c Gitweb: https://git.kernel.org/tip/469693d8f62299709e8ba56d8fb3da9ea990213c Author: Michael Roth AuthorDate: Wed, 09 Feb 2022 12:10:17 -06:00 Committer: Borislav Petkov CommitterDate: Wed, 06 Apr 2022 17:06:55 +02:00 x86/head/64: Re-enable stack protection Due to 103a4908ad4d ("x86/head/64: Disable stack protection for head$(BITS).o") kernel/head{32,64}.c are compiled with -fno-stack-protector to allow a call to set_bringup_idt_handler(), which would otherwise have stack protection enabled with CONFIG_STACKPROTECTOR_STRONG. While sufficient for that case, there may still be issues with calls to any external functions that were compiled with stack protection enabled that in-turn make stack-protected calls, or if the exception handlers set up by set_bringup_idt_handler() make calls to stack-protected functions. Subsequent patches for SEV-SNP CPUID validation support will introduce both such cases. Attempting to disable stack protection for everything in scope to address that is prohibitive since much of the code, like the SEV-ES #VC handler, is shared code that remains in use after boot and could benefit from having stack protection enabled. Attempting to inline calls is brittle and can quickly balloon out to library/helper code where that's not really an option. Instead, re-enable stack protection for head32.c/head64.c, and make the appropriate changes to ensure the segment used for the stack canary is initialized in advance of any stack-protected C calls. For head64.c: - The BSP will enter from startup_64() and call into C code (startup_64_setup_env()) shortly after setting up the stack, which may result in calls to stack-protected code. Set up %gs early to allow for this safely. - APs will enter from secondary_startup_64*(), and %gs will be set up soon after. There is one call to C code prior to %gs being setup (__startup_secondary_64()), but it is only to fetch 'sme_me_mask' global, so just load 'sme_me_mask' directly instead, and remove the now-unused __startup_secondary_64() function. For head32.c: - BSPs/APs will set %fs to __BOOT_DS prior to any C calls. In recent kernels, the compiler is configured to access the stack canary at %fs:__stack_chk_guard [1], which overlaps with the initial per-cpu '__stack_chk_guard' variable in the initial/"master" .data..percpu area. This is sufficient to allow access to the canary for use during initial startup, so no changes are needed there. [1] 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable") [ bp: Massage commit message. ] Suggested-by: Joerg Roedel #for 64-bit %gs set up Signed-off-by: Michael Roth Signed-off-by: Brijesh Singh Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20220307213356.2797205-24-brijesh.singh@amd.com --- arch/x86/include/asm/setup.h | 1 - arch/x86/kernel/Makefile | 2 -- arch/x86/kernel/head64.c | 9 --------- arch/x86/kernel/head_64.S | 24 +++++++++++++++++++++--- 4 files changed, 21 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h index 896e48d..a1b107f 100644 --- a/arch/x86/include/asm/setup.h +++ b/arch/x86/include/asm/setup.h @@ -50,7 +50,6 @@ extern unsigned long saved_video_mode; extern void reserve_standard_io_resources(void); extern void i386_reserve_resources(void); extern unsigned long __startup_64(unsigned long physaddr, struct boot_params *bp); -extern unsigned long __startup_secondary_64(void); extern void startup_64_setup_env(unsigned long physbase); extern void early_setup_idt(void); extern void __init do_early_exception(struct pt_regs *regs, int trapnr); diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index c41ef42..1a2dc32 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -46,8 +46,6 @@ endif # non-deterministic coverage. KCOV_INSTRUMENT := n -CFLAGS_head$(BITS).o += -fno-stack-protector - CFLAGS_irq.o := -I $(srctree)/$(src)/../include/asm/trace obj-y := process_$(BITS).o signal.o diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 656d2f3..c185f48 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -318,15 +318,6 @@ unsigned long __head __startup_64(unsigned long physaddr, return sme_postprocess_startup(bp, pmd); } -unsigned long __startup_secondary_64(void) -{ - /* - * Return the SME encryption mask (if SME is active) to be used as a - * modifier for the initial pgdir entry programmed into CR3. - */ - return sme_get_me_mask(); -} - /* Wipe all early page tables except for the kernel symbol map */ static void __init reset_early_page_tables(void) { diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index 6bf340c..7bac9a4 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -65,6 +65,22 @@ SYM_CODE_START_NOALIGN(startup_64) leaq (__end_init_task - FRAME_SIZE)(%rip), %rsp leaq _text(%rip), %rdi + + /* + * initial_gs points to initial fixed_percpu_data struct with storage for + * the stack protector canary. Global pointer fixups are needed at this + * stage, so apply them as is done in fixup_pointer(), and initialize %gs + * such that the canary can be accessed at %gs:40 for subsequent C calls. + */ + movl $MSR_GS_BASE, %ecx + movq initial_gs(%rip), %rax + movq $_text, %rdx + subq %rdx, %rax + addq %rdi, %rax + movq %rax, %rdx + shrq $32, %rdx + wrmsr + pushq %rsi call startup_64_setup_env popq %rsi @@ -147,9 +163,11 @@ SYM_INNER_LABEL(secondary_startup_64_no_verify, SYM_L_GLOBAL) * Retrieve the modifier (SME encryption mask if SME is active) to be * added to the initial pgdir entry that will be programmed into CR3. */ - pushq %rsi - call __startup_secondary_64 - popq %rsi +#ifdef CONFIG_AMD_MEM_ENCRYPT + movq sme_me_mask, %rax +#else + xorq %rax, %rax +#endif /* Form the CR3 value being sure to include the CR3 modifier */ addq $(init_top_pgt - __START_KERNEL_map), %rax