From patchwork Wed Jan 31 07:21:10 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: tip-bot2 for Thomas Gleixner X-Patchwork-Id: 194548 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp1722579dyb; Tue, 30 Jan 2024 23:24:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IEBioRhKF7R0GE4l09uHWiwOf66JIxDQLIhWS+D8i2/HvyiC+GhSv7U63uPorjxKCxRdrUG X-Received: by 2002:a17:90a:dc04:b0:295:f337:26f8 with SMTP id i4-20020a17090adc0400b00295f33726f8mr35653pjv.12.1706685842058; Tue, 30 Jan 2024 23:24:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706685842; cv=pass; d=google.com; s=arc-20160816; b=ma+IyMiiGkXAR6ZzyZFM/EeQ9mNsqMUpkCCXyowzJfvI4HpVGt+r3tJP4Dc4Z4MYRv mNbNADSwEwFgQ5frzqSRO6xyejsU+XXtUeg8cu4Xy0vkxJDSVA5bAQSbKvNj5nxT0x/F iUhP1FlmyktxnS4UakY48XM+GSiVirTfosmIrDb4+jd4Wr6pnIFR7iM0SvFK9o/OBTpU hXvGTGR+lTR4mvHQwkuybpvy6RTjVakGCttdgythUBHz5QE3rdlVqyjkp4jZLGXnE8N5 vIr4i/8SoK95I0AaNjUHfLZnAWZz1MeFlNScF07mZmK8GfXPVlJ1Kkqv4YaASQ2yXQJE F/0Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:precedence:robot-unsubscribe:robot-id :message-id:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:references:in-reply-to:cc:subject:to:reply-to:sender :from:dkim-signature:dkim-signature:date; bh=7EDvqY+FrfhoNiGl/jodCXdh7PZYstJCOtSPDE8BJY4=; fh=nGlmmR/m20wPby9IA4/UXRBMF2YRTamkZHObV38V3HY=; b=Ru3ZDuv0bYExcwbl9TjKQIOnpCKsYPdQc8+m2ZuWM5oI5mJ7LIxjpm5pj59dVVvEZi t/ijeYfVPvwdPRGyao0Jow+QEdmX0Tt4S4f6G76Y3TI+sx/qGHplDO7ipjSLXi4Navcd sdgQPJCgqz9BR28WBZT9jRBZwYUCrid97lpWh5Drt3SUg+dNASNR17yqgMghmZu7QS3r coT1B++VRUij0vH0NnuOfce0abz61qTQ+wOJupuAX/ZuhnUFChhEAFky2e1E0YJritMa x8lw5qSKl+XqqHISOb7Sw87ROMVxSEABRFvt6j6C1FlALwoK1VN9zXjn4d3EMfUtYoN5 ldrQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=P1Tsklgy; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; arc=pass (i=1 spf=pass spfdomain=linutronix.de dkim=pass dkdomain=linutronix.de dmarc=pass fromdomain=linutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-45898-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45898-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de X-Forwarded-Encrypted: i=1; AJvYcCXwzNyLyNLnZmcP6b+Qm06hOJ8rmhGTA7acbYyb5o6jXiegq8u68fc/XvDELcVDJZppU7lJX06E7G0kYua75cfgJ7M85Q== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id dt15-20020a17090afa4f00b0029590fb320bsi651723pjb.67.2024.01.30.23.24.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 23:24:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-45898-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=P1Tsklgy; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; arc=pass (i=1 spf=pass spfdomain=linutronix.de dkim=pass dkdomain=linutronix.de dmarc=pass fromdomain=linutronix.de); spf=pass (google.com: domain of linux-kernel+bounces-45898-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45898-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 3E7EB28AA34 for ; Wed, 31 Jan 2024 07:23:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 36D746BB4A; Wed, 31 Jan 2024 07:21:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="P1Tsklgy"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="kE/OoDpj" Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 84A4256772; Wed, 31 Jan 2024 07:21:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706685676; cv=none; b=AT+XKPHV1XV6EGdkyYFxAw3N9pH1JcRtnZK+dSXzBD1g4Gqn+197ejjJbeFapOVhYupjQveTwA/VqRW74OJsxtV1IFljj4PKiOobNNRRE+7HOcD+mmdYIitAoTWlgCAQm+4nTOJBQ5ihynBUqZ9+AXdQNpQ8+ZKKCp835DuotN0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706685676; c=relaxed/simple; bh=06vC6dSb30cXRlyBgUWBCtQ03xSF5Xuzl68Nv5CXQ6g=; h=Date:From:To:Subject:Cc:In-Reply-To:References:MIME-Version: Message-ID:Content-Type; b=kMCQKtXpB4n+eFgbZG1BgE+cjcuC8/7y/d4J9AxlplG6AbHkio+rc6TvPVh3n2dB8kKOPIahWXqLSCRbEHvqKRn2GMW5gITq00F6qb23pQjwZNxnmrTXw16cHh1kACaIffUCTpqTyg0YsoFIGu8Ho6Wa5xlzKm2uG1wm6iHQDSg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=P1Tsklgy; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=kE/OoDpj; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Date: Wed, 31 Jan 2024 07:21:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1706685671; 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=7EDvqY+FrfhoNiGl/jodCXdh7PZYstJCOtSPDE8BJY4=; b=P1TsklgyQKGqThd716MJsdhpEm++viAFL1y15QrueGf8rjUkDa2GFLq1gqaOP0oI1yl9CO 3a2HnfZ5rKARn5Gy+1awxp2fsSCFaXlVytU7SE4l1i7A6MovbXjHuVXLjem/6LdvNJVHom 22jOj8Tm9J9+DUVSctMI+HZsAqV7eHVEIiTU3F9VXPXbF05hZD7FI3P2ByVDPzDaCWIuf4 dRehA2DEllmaHP6qsn0KsMONeux8R0aG4bitJx1kzZfj3aCAh1cLSh2nDC2AyrG535sa2V oD4tE6mCKVz8T9fVR/CXHx7Hzm8APpwMw+3X4A5uVZ+vCFKeEh2KbTvK34ujyA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1706685671; 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=7EDvqY+FrfhoNiGl/jodCXdh7PZYstJCOtSPDE8BJY4=; b=kE/OoDpjS/MuE5+LntMenTExv2hPDYNfDa2rKi4fYKOh/g0gW3hyJZtrVywkFYq3Ynw0Ta OGXfGO0sKndKUPAA== From: "tip-bot2 for Xin Li" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/fred] x86/fred: Fixup fault on ERETU by jumping to fred_entrypoint_user Cc: "H. Peter Anvin (Intel)" , Xin Li , Thomas Gleixner , Shan Kang , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20231205105030.8698-30-xin3.li@intel.com> References: <20231205105030.8698-30-xin3.li@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-ID: <170668567087.398.14483021835383611163.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784440834634349456 X-GMAIL-MSGID: 1789589813464383056 The following commit has been merged into the x86/fred branch of tip: Commit-ID: ed63bc7d4953bd5fe93a5c3acef7f485fb216208 Gitweb: https://git.kernel.org/tip/ed63bc7d4953bd5fe93a5c3acef7f485fb216208 Author: Xin Li AuthorDate: Tue, 05 Dec 2023 02:50:18 -08:00 Committer: Borislav Petkov (AMD) CommitterDate: Tue, 30 Jan 2024 18:20:36 +01:00 x86/fred: Fixup fault on ERETU by jumping to fred_entrypoint_user If the stack frame contains an invalid user context (e.g. due to invalid SS, a non-canonical RIP, etc.) the ERETU instruction will trap (#SS or #GP). >From a Linux point of view, this really should be considered a user space failure, so use the standard fault fixup mechanism to intercept the fault, fix up the exception frame, and redirect execution to fred_entrypoint_user. The end result is that it appears just as if the hardware had taken the exception immediately after completing the transition to user space. Suggested-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li Signed-off-by: Thomas Gleixner Tested-by: Shan Kang Link: https://lore.kernel.org/r/20231205105030.8698-30-xin3.li@intel.com --- arch/x86/entry/entry_64_fred.S | 5 +- arch/x86/include/asm/extable_fixup_types.h | 4 +- arch/x86/mm/extable.c | 78 +++++++++++++++++++++- 3 files changed, 85 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S index 2271a1c..7fe2722 100644 --- a/arch/x86/entry/entry_64_fred.S +++ b/arch/x86/entry/entry_64_fred.S @@ -3,6 +3,7 @@ * The actual FRED entry points. */ +#include #include #include "calling.h" @@ -34,7 +35,9 @@ SYM_CODE_START_NOALIGN(asm_fred_entrypoint_user) call fred_entry_from_user SYM_INNER_LABEL(asm_fred_exit_user, SYM_L_GLOBAL) FRED_EXIT - ERETU +1: ERETU + + _ASM_EXTABLE_TYPE(1b, asm_fred_entrypoint_user, EX_TYPE_ERETU) SYM_CODE_END(asm_fred_entrypoint_user) /* diff --git a/arch/x86/include/asm/extable_fixup_types.h b/arch/x86/include/asm/extable_fixup_types.h index fe63120..7acf038 100644 --- a/arch/x86/include/asm/extable_fixup_types.h +++ b/arch/x86/include/asm/extable_fixup_types.h @@ -64,6 +64,8 @@ #define EX_TYPE_UCOPY_LEN4 (EX_TYPE_UCOPY_LEN | EX_DATA_IMM(4)) #define EX_TYPE_UCOPY_LEN8 (EX_TYPE_UCOPY_LEN | EX_DATA_IMM(8)) -#define EX_TYPE_ZEROPAD 20 /* longword load with zeropad on fault */ +#define EX_TYPE_ZEROPAD 20 /* longword load with zeropad on fault */ + +#define EX_TYPE_ERETU 21 #endif diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c index 271dcb2..b522933 100644 --- a/arch/x86/mm/extable.c +++ b/arch/x86/mm/extable.c @@ -6,6 +6,7 @@ #include #include +#include #include #include #include @@ -223,6 +224,79 @@ static bool ex_handler_ucopy_len(const struct exception_table_entry *fixup, return ex_handler_uaccess(fixup, regs, trapnr, fault_address); } +#ifdef CONFIG_X86_FRED +static bool ex_handler_eretu(const struct exception_table_entry *fixup, + struct pt_regs *regs, unsigned long error_code) +{ + struct pt_regs *uregs = (struct pt_regs *)(regs->sp - offsetof(struct pt_regs, orig_ax)); + unsigned short ss = uregs->ss; + unsigned short cs = uregs->cs; + + /* + * Move the NMI bit from the invalid stack frame, which caused ERETU + * to fault, to the fault handler's stack frame, thus to unblock NMI + * with the fault handler's ERETS instruction ASAP if NMI is blocked. + */ + regs->fred_ss.nmi = uregs->fred_ss.nmi; + + /* + * Sync event information to uregs, i.e., the ERETU return frame, but + * is it safe to write to the ERETU return frame which is just above + * current event stack frame? + * + * The RSP used by FRED to push a stack frame is not the value in %rsp, + * it is calculated from %rsp with the following 2 steps: + * 1) RSP = %rsp - (IA32_FRED_CONFIG & 0x1c0) // Reserve N*64 bytes + * 2) RSP = RSP & ~0x3f // Align to a 64-byte cache line + * when an event delivery doesn't trigger a stack level change. + * + * Here is an example with N*64 (N=1) bytes reserved: + * + * 64-byte cache line ==> ______________ + * |___Reserved___| + * |__Event_data__| + * |_____SS_______| + * |_____RSP______| + * |_____FLAGS____| + * |_____CS_______| + * |_____IP_______| + * 64-byte cache line ==> |__Error_code__| <== ERETU return frame + * |______________| + * |______________| + * |______________| + * |______________| + * |______________| + * |______________| + * |______________| + * 64-byte cache line ==> |______________| <== RSP after step 1) and 2) + * |___Reserved___| + * |__Event_data__| + * |_____SS_______| + * |_____RSP______| + * |_____FLAGS____| + * |_____CS_______| + * |_____IP_______| + * 64-byte cache line ==> |__Error_code__| <== ERETS return frame + * + * Thus a new FRED stack frame will always be pushed below a previous + * FRED stack frame ((N*64) bytes may be reserved between), and it is + * safe to write to a previous FRED stack frame as they never overlap. + */ + fred_info(uregs)->edata = fred_event_data(regs); + uregs->ssx = regs->ssx; + uregs->fred_ss.ss = ss; + /* The NMI bit was moved away above */ + uregs->fred_ss.nmi = 0; + uregs->csx = regs->csx; + uregs->fred_cs.sl = 0; + uregs->fred_cs.wfe = 0; + uregs->cs = cs; + uregs->orig_ax = error_code; + + return ex_handler_default(fixup, regs); +} +#endif + int ex_get_fixup_type(unsigned long ip) { const struct exception_table_entry *e = search_exception_tables(ip); @@ -300,6 +374,10 @@ int fixup_exception(struct pt_regs *regs, int trapnr, unsigned long error_code, return ex_handler_ucopy_len(e, regs, trapnr, fault_addr, reg, imm); case EX_TYPE_ZEROPAD: return ex_handler_zeropad(e, regs, fault_addr); +#ifdef CONFIG_X86_FRED + case EX_TYPE_ERETU: + return ex_handler_eretu(e, regs, error_code); +#endif } BUG(); }