From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5FFDC7EE30 for ; Wed, 2 Jul 2025 10:17:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41ABC6B00D2; Wed, 2 Jul 2025 06:17:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D1E56B00D3; Wed, 2 Jul 2025 06:17:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 293556B00DF; Wed, 2 Jul 2025 06:17:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 159116B00D2 for ; Wed, 2 Jul 2025 06:17:27 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AE7161A012F for ; Wed, 2 Jul 2025 10:17:26 +0000 (UTC) X-FDA: 83618922492.17.3C80C95 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by imf27.hostedemail.com (Postfix) with ESMTP id 545DD4000B for ; Wed, 2 Jul 2025 10:17:24 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LICB4OHT; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf27.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.10) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751451444; a=rsa-sha256; cv=none; b=wgHKUvbaxIYS3BG4rJKNJMA73CqKItA9Zf6uDacIJH3vBwHcqcFPLwRfjfl7zsRpUFalpH VomFE4iSGktio7Feij5G4mTMHuTRhVAke1NjfqouTCX+kdEjuBI7+oJ+Y0xhjzFQaeP0wg KparcKaVPnRaPbXmWoqe7kt3uWT+N2k= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LICB4OHT; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf27.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.10) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751451444; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ztR2b70wJ2jjIHyM4LUO6dEN95xTMQN1782a4ljjvqI=; b=YVo/NfXwztN1zgcGOPdXIJOuuaA3Oye9o43tCwb1quRJ5BTYWj2uIXakeMG9dDVM9bOcZx bi4rV1ADYOgGl9Fy78DOIxbC3pqZQ7m53sns56g1XSK6VqKS5tcZoZ5UXtUqZJFPNhSPNH MRxehVYiJQ/L5sxxo7e4yiHrVIzb2RE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1751451444; x=1782987444; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=0vykiB83G9vcIlf4hVyInQxt2iop2prV08IcMSSFKbA=; b=LICB4OHTN/QnJrbcUy3AuRsKK8Aq/t4Y+iqrlWeyULzzawu6uCdx0JuH 4vXZwIaeFCc/2KE3eT1KPQbnQxjYXVoRPN9RPuJixyxU6WwDfFZGL0FtU wjrYtjF29SdTY3R5PbrftVolQ+upTcAVomQ2iK4AuEB8NLpnPsXu7SebC x1q6A3EwjjJUiw6roILVGHEZ1xRYwQhm0VNL7vPd2t0CB2yc8qwGQc1Do Eau7Vo0pICJs2LNnKJ8yZlUCq9G9V19CVcbi8DlUFAOlM+O/e62vxFNKz jSPMYa1S2t++AzknXFqS5yctfbzlEmi7lHIRQUC/GjHUbEN6dvnBZLywU g==; X-CSE-ConnectionGUID: AtVMPx1dSSeXjtQ2bd2A6Q== X-CSE-MsgGUID: zbqgu387Q5y4oLxGOv5xFg== X-IronPort-AV: E=McAfee;i="6800,10657,11481"; a="71166803" X-IronPort-AV: E=Sophos;i="6.16,281,1744095600"; d="scan'208";a="71166803" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2025 03:17:22 -0700 X-CSE-ConnectionGUID: H0AE6E4lRXKuG3TgVZexbw== X-CSE-MsgGUID: +FtBcl7SSGuSI820sqPDbA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,281,1744095600"; d="scan'208";a="153491981" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa006.jf.intel.com with ESMTP; 02 Jul 2025 03:17:11 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 1298D1E0; Wed, 02 Jul 2025 13:17:10 +0300 (EEST) Date: Wed, 2 Jul 2025 13:17:10 +0300 From: "Kirill A. Shutemov" To: "H. Peter Anvin" Cc: Sohil Mehta , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin , Jonathan Corbet , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv8 14/17] x86/traps: Handle LASS thrown #SS Message-ID: <5q2zbkzyjknusd3feqolycqialetqfe52yfyzasnr6zp24pmej@4cg2r2hi4pf2> References: <20250701095849.2360685-1-kirill.shutemov@linux.intel.com> <20250701095849.2360685-15-kirill.shutemov@linux.intel.com> <95dc18fd-73b0-4019-92d2-c0e6aaf22c96@intel.com> <4DE45AFD-C1E0-4FB8-BE01-44A72C5C6E1E@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE45AFD-C1E0-4FB8-BE01-44A72C5C6E1E@zytor.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 545DD4000B X-Stat-Signature: q86auj6tqxr1d5emueujc4gby4dydh8r X-HE-Tag: 1751451444-585446 X-HE-Meta: U2FsdGVkX1+Y7c/wBTCwXunpy/Uo1/ODRf34THnvo2usC/ow9JtxF0pznwYBTVx8ywbiFpBVBPP2y4S1ws8Vv8tyw2ir84ssCaU74d/0xviTYcHVlfbuNUVPUsjJy95gmFGJMkASIEgR0VQGpNolcYFl2t32rlSeRG8QKD4lWw/7zhXrZvsoMfjejKhi4Zhankv3MBBdQswChTYjEvVUEXup+ZFRPO4C8Rub8rDrF/mpjZkGpxTGPK7IM84VOFzuU9yMW9u9PDVrPFsmX8sBWyM7t7HWDLJrScxGX7Zru40hcmFKWcNIw83y7N8QdmgCE7/EOHPeO5RGacuuXrOTs5tU7lbDhxjYfoLOqnB5ieoyNToYA2x8NsR+54cAnph9dk5Cu4kVER0A4qfjy9QmxX8IHi4sQU8HTYf1sDGIaR69TzWwcmAlA5SfHJgPZKYvEPTmzdG4xsCW8ZI4XXH3SRRwIQuDLnn38Lj6hslq99n3nWhxaobbl6cDkdanIL/58jTlKaLuEOq6SZKfZvZvZcj/si5eXxKokFvxL8lPKt1/J6Hp/D8WRDqPDz0AfhwI/8FDBMmmBhz+jsRtiUOLkeVIrzJ25eNsRahzEb/iu1BirRyrOEi3PtpGa26ZCGz4L5Hs3Jg9ojJ09t0KOGZOOZHVPjIoTnOB2EKq97372KADRndICUM3VzUpTPC069YXUkDcNXW8U3GO5VtTxIWJ2h4PmO9d7XAgxJ6q14eVySVgB6lVZuMWALfc4rLebk3xEFN7bx/SwFUPvW+ZB60vujs+UuVaSXY0bgrZ+rf++hVXykzasXQSguvb6MP2yNxYmTwSZ3SoM3ErEIdsU4KbtXUYOT6P29qfzuDx7B7ptNVkuCRWTlk0EnG3uScM5sl3Jo27xbDj9fQaAEiJpw1UrOUiLFMhhPHNcyuq2fFLAoGDJrunxieU2d34JIVJs/w0RGz06/0Ly6XxSRs84Fz bdhUnP3Z LktmyTsh1xk9fdDoXyWKMmpqmsrnFA5ZqtZQy75qO4DkKoG7Z/P7E7MCGRJNhuzm6+gddD9B39Z0wdhjKZU/F7KTPvEfXXTREQ2R3EAdWNlDHb3bvtLw/8aaDUmJ9X3S5wTednT9p4vZbPP6ukaApqGp1bRkXntIXX5tirzsCYQosCwWbZ2/TbG0UZBxyVdMJSGsTBLf418i56MxoNW6Lky5KokIKN3OzLRLGVBEE/YtTpp1w021m+lWPJ4/rn/+5pxqGxq1XtP11A8ed+qb6nCN2GBt1pJWqX6zVuqvJWKjTFdPbmO8AL6PyWNSDC/hnrC/P X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jul 01, 2025 at 07:06:10PM -0700, H. Peter Anvin wrote: > On July 1, 2025 6:35:40 PM PDT, Sohil Mehta wrote: > >On 7/1/2025 2:58 AM, Kirill A. Shutemov wrote: > >> LASS throws a #GP for any violations except for stack register accesses, > >> in which case it throws a #SS instead. Handle this similarly to how other > >> LASS violations are handled. > >> > > > >Maybe I've misunderstood something: > > > >Is the underlying assumption here that #SS were previously only > >generated by userspace, but now they can also be generated by the > >kernel? And we want the kernel generated #SS to behave the same as the #GP? > > > >> In case of FRED, before handling #SS as LASS violation, kernel has to > >> check if there's a fixup for the exception. It can address #SS due to > >> invalid user context on ERETU. See 5105e7687ad3 ("x86/fred: Fixup > >> fault on ERETU by jumping to fred_entrypoint_user") for more details. > >> > >> Co-developed-by: Alexander Shishkin > >> Signed-off-by: Alexander Shishkin > >> Signed-off-by: Kirill A. Shutemov > >> --- > >> arch/x86/kernel/traps.c | 39 +++++++++++++++++++++++++++++++++------ > >> 1 file changed, 33 insertions(+), 6 deletions(-) > >> > >> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > >> index ceb091f17a5b..f9ca5b911141 100644 > >> --- a/arch/x86/kernel/traps.c > >> +++ b/arch/x86/kernel/traps.c > >> @@ -418,12 +418,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_segment_not_present) > >> SIGBUS, 0, NULL); > >> } > >> > >> -DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment) > >> -{ > >> - do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS, > >> - 0, NULL); > >> -} > >> - > >> DEFINE_IDTENTRY_ERRORCODE(exc_alignment_check) > >> { > >> char *str = "alignment check"; > >> @@ -866,6 +860,39 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) > >> cond_local_irq_disable(regs); > >> } > >> > >> +#define SSFSTR "stack segment fault" > >> + > >> +DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment) > >> +{ > >> + if (user_mode(regs)) > >> + goto error_trap; > >> + > >> + if (cpu_feature_enabled(X86_FEATURE_FRED) && > >> + fixup_exception(regs, X86_TRAP_SS, error_code, 0)) > >> + return; > >> + > >> + if (cpu_feature_enabled(X86_FEATURE_LASS)) { > >> + enum kernel_exc_hint hint; > >> + unsigned long exc_addr; > >> + > >> + hint = get_kernel_exc_address(regs, &exc_addr); > >> + if (hint != EXC_NO_HINT) { > > > >The brackets are not needed for singular statements. Also the max line > >length is longer now. You can fit this all in a single line. > > > >> + printk(SSFSTR ", %s 0x%lx", kernel_exc_hint_help[hint], > >> + exc_addr); > >> + } > >> + > > > >> + if (hint != EXC_NON_CANONICAL) > >> + exc_addr = 0; > >> + > >> + die_addr(SSFSTR, regs, error_code, exc_addr); > > > >The variable names in die_addr() should be generalized as well. They > >seem to assume the caller to be a #GP handler. > > > >> + return; > >> + } > >> + > >> +error_trap: > >> + do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS, > >> + 0, NULL); > >> +} > >> + > >> static bool do_int3(struct pt_regs *regs) > >> { > >> int res; > > > > Note: for a FRED system, ERETU can generate #SS for a non-canonical user space RSP even in the absence of LASS, so if that is not currently handled that is an active bug. It is handled by fixup code inside do_error_trap(). We need to add explicit fixup before LASS handling to avoid treating bad userspace RSP as kernel LASS violation. -- Kiryl Shutsemau / Kirill A. Shutemov