Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3245017imw; Mon, 18 Jul 2022 04:54:52 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vB80UkuxX94t9Eg+mv7S4gk9nBEpbqd7T+ngD26P4KOZ0EHPfvuN1ad/8EpWzyhtZWHlWY X-Received: by 2002:a05:6402:388b:b0:42b:5f20:c616 with SMTP id fd11-20020a056402388b00b0042b5f20c616mr36486571edb.50.1658145291901; Mon, 18 Jul 2022 04:54:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658145291; cv=none; d=google.com; s=arc-20160816; b=Xj/CSVpwd881FcLZjA7n+zX4U0f/eo3irs9+dpM+hW7N6gOhIt9UxMaarvhAuQ4PX5 Y+xrMbrlvZI6XqTn3Az43Kq6hos35WFHv7SECWkfQJ6oWtXZcPkBtYOCFSyuHQWNHyeP bEryQn+vrm+BGO546C2lIznIrKS5f50jeoEAVyuIwedQytQEagtufQ6+ZLQxkU22FOKO AbWBzXyOf84hBwCLnh2aVnONtpdiybtNQEjDAbMkUWeLibxWoUG9U+VfVE5iIO0hQAKp Xp6/NSYs226svXcFDgfgHAmiOKThejKb/6nq0zVNUg0e8c3VAMVHoSyCkhNFxwbrRAf1 nMCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=EEc9IHZIWJwHYmyzdLOeoXjAFOJf8a2lOt0xm5QgV3w=; b=SUko2phD9vZnclzCB8StFDBVHLX2iSGWKmWMKHztUJ0EZ9RZeqeVcA30OVq4xhJNwQ efxuVdlljBmjkEhyZy5fCz9wx47hppNyue/bLvvMRTxJoiO+R92/M5kfWTj65fMJbKA5 +V65MNlKK6ZIvVU7GIC/Q4Fd+T7cvcQ1ShdXezIiCDk79SYaa+J11yzhW+F3LQglKqIA 3jZ35NZ442nzHZMXrLt8XBNNRYcuf9k730UD1TEYdLziImItI19zLCBFVpl3rl7ADxND OIfyAdaHxL+Ogka64mEmMsrpEMo3P3OzuTIQ8/kY7qnOKdl5CMBJjqOe/6Zk013KKskX tCRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=desiato.20200630 header.b=T+cIZZ3b; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g12-20020a056402090c00b004378a88f055si18174275edz.577.2022.07.18.04.54.24; Mon, 18 Jul 2022 04:54:51 -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=@infradead.org header.s=desiato.20200630 header.b=T+cIZZ3b; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234419AbiGRLmD (ORCPT + 99 others); Mon, 18 Jul 2022 07:42:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230249AbiGRLmC (ORCPT ); Mon, 18 Jul 2022 07:42:02 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5ADFB4E; Mon, 18 Jul 2022 04:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=EEc9IHZIWJwHYmyzdLOeoXjAFOJf8a2lOt0xm5QgV3w=; b=T+cIZZ3bhcx8LfA9eyofGJrDhv zy6tBDbb4qBFCHdlXaxIdQxJJNjascLa6qWnSS4kO6uvbc48k+UniEGd/L/dvhbrSXryRPqbd+/Pl sQa1/OY6pFczLuEF054UxJh4D214/RgxImxXHsY6xzpvD8Ft01So1580ctcmigeWn9Usmto6n9W/l npRD39zyWsSUTqmQ0hoMRu1/4X07fIpeiaagnyUMPe9cMUsirrzg8UwFENG/F0xdZSZc+Xell3mtE VtZ8SNFb450+ILrXP7Mg8m1BJorpkZigjTPSHPVbCMos1tAAOrwIEW+4XT409PjaE//v3kcnRIqRM bSvgwg5Q==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=worktop.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDP87-004oSC-0E; Mon, 18 Jul 2022 11:41:39 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id D2E17980239; Mon, 18 Jul 2022 13:41:37 +0200 (CEST) Date: Mon, 18 Jul 2022 13:41:37 +0200 From: Peter Zijlstra To: Thadeu Lima de Souza Cascardo Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, x86@kernel.org, ardb@kernel.org, tglx@linutronix.de, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, Guenter Roeck , Borislav Petkov , Josh Poimboeuf , stable@vger.kernel.org, Andrew Cooper Subject: Re: [PATCH] efi/x86: use naked RET on mixed mode call wrapper Message-ID: References: <20220715194550.793957-1-cascardo@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220715194550.793957-1-cascardo@canonical.com> 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_NONE 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 On Fri, Jul 15, 2022 at 04:45:50PM -0300, Thadeu Lima de Souza Cascardo wrote: > When running with return thunks enabled under 32-bit EFI, the system > crashes with: > > [ 0.137688] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) > [ 0.138136] BUG: unable to handle page fault for address: 000000005bc02900 > [ 0.138136] #PF: supervisor instruction fetch in kernel mode > [ 0.138136] #PF: error_code(0x0011) - permissions violation > [ 0.138136] PGD 18f7063 P4D 18f7063 PUD 18ff063 PMD 190e063 PTE 800000005bc02063 > [ 0.138136] Oops: 0011 [#1] PREEMPT SMP PTI > [ 0.138136] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc6+ #166 > [ 0.138136] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 > [ 0.138136] RIP: 0010:0x5bc02900 > [ 0.138136] Code: Unable to access opcode bytes at RIP 0x5bc028d6. > [ 0.138136] RSP: 0018:ffffffffb3203e10 EFLAGS: 00010046 > [ 0.138136] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000048 > [ 0.138136] RDX: 000000000190dfac RSI: 0000000000001710 RDI: 000000007eae823b > [ 0.138136] RBP: ffffffffb3203e70 R08: 0000000001970000 R09: ffffffffb3203e28 > [ 0.138136] R10: 747563657865206c R11: 6c6977203a696665 R12: 0000000000001710 > [ 0.138136] R13: 0000000000000030 R14: 0000000001970000 R15: 0000000000000001 > [ 0.138136] FS: 0000000000000000(0000) GS:ffff8e013ca00000(0000) knlGS:0000000000000000 > [ 0.138136] CS: 0010 DS: 0018 ES: 0018 CR0: 0000000080050033 > [ 0.138136] CR2: 000000005bc02900 CR3: 0000000001930000 CR4: 00000000000006f0 > [ 0.138136] Call Trace: > [ 0.138136] > [ 0.138136] ? efi_set_virtual_address_map+0x9c/0x175 > [ 0.138136] efi_enter_virtual_mode+0x4a6/0x53e > [ 0.138136] start_kernel+0x67c/0x71e > [ 0.138136] x86_64_start_reservations+0x24/0x2a > [ 0.138136] x86_64_start_kernel+0xe9/0xf4 > [ 0.138136] secondary_startup_64_no_verify+0xe5/0xeb > [ 0.138136] > > That's because it cannot jump to the return thunk from the 32-bit code. > Using a naked RET and marking it as safe allows the system to proceed > booting. > > Fixes: aa3d480315ba ("x86: Use return-thunk in asm code") > Reported-by: Guenter Roeck > Signed-off-by: Thadeu Lima de Souza Cascardo > Cc: Peter Zijlstra (Intel) > Cc: Borislav Petkov > Cc: Josh Poimboeuf > Cc: > --- > > Does this leave one potential attack vector open? Perhaps, since this is > running under a different mapping (AFAIU), the risk is reduced? Or rather, the > attacker could attack using the firmware RETs anyway? > > Alternatively, we could use IBPB when available when using the wrapper. > > Thoughts? What actual uarch are you running this on? Is this AMD hardware? For Intel we'll enable IBRS for firmware if it is not otherwise enabled (upstream will always enable IBRS for the SKL family chips, but Thomas just posted the retbleed=stuff approach yesterday that will not) On AMD I think you're stuck with IBPB, but that has to be issued *before* calling the firmware muck. In either case, I think the patch as proposed is fine. But perhaps we want something like the below on top. --- Subject: x86/amd: Use IBPB for firmware calls On AMD IBRS does not prevent Retbleed; as such use IBPB before a firmware call to flush the branch history state. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/nospec-branch.h | 2 ++ arch/x86/kernel/cpu/bugs.c | 11 ++++++++++- 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 00f5227c8459..a77b915d36a8 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -302,6 +302,7 @@ #define X86_FEATURE_RETPOLINE_LFENCE (11*32+13) /* "" Use LFENCE for Spectre variant 2 */ #define X86_FEATURE_RETHUNK (11*32+14) /* "" Use REturn THUNK */ #define X86_FEATURE_UNRET (11*32+15) /* "" AMD BTB untrain return */ +#define X86_FEATURE_USE_IBPB_FW (11*32+16) /* "" Use IBPB during runtime firmware calls */ /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX_VNNI (12*32+ 4) /* AVX VNNI instructions */ diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h index 10a3bfc1eb23..f934dcdb7c0d 100644 --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -297,6 +297,8 @@ do { \ alternative_msr_write(MSR_IA32_SPEC_CTRL, \ spec_ctrl_current() | SPEC_CTRL_IBRS, \ X86_FEATURE_USE_IBRS_FW); \ + altnerative_msr_write(MSR_IA32_PRED_CMD, PRED_CMD_IBPB, \ + X86_FEATURE_USE_IBPB_FW); \ } while (0) #define firmware_restrict_branch_speculation_end() \ diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index aa34f908c39f..78c9082242a9 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1516,7 +1516,16 @@ static void __init spectre_v2_select_mitigation(void) * the CPU supports Enhanced IBRS, kernel might un-intentionally not * enable IBRS around firmware calls. */ - if (boot_cpu_has(X86_FEATURE_IBRS) && !spectre_v2_in_ibrs_mode(mode)) { + if (boot_cpu_has_bug(X86_BUG_RETBLEED) && + (boot_cpu_data.x86_vendor == X86_VENDOR_AMD || + boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)) { + + if (retbleed_cmd != RETBLEED_CMD_IBPB) { + setup_force_cpu_cap(X86_FEATURE_USE_IBPB_FW); + pr_info("Enabling Speculation Barrier for firmware calls\n"); + } + + } else if (boot_cpu_has(X86_FEATURE_IBRS) && !spectre_v2_in_ibrs_mode(mode)) { setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW); pr_info("Enabling Restricted Speculation for firmware calls\n"); }