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 5E8FDC7EE30 for ; Wed, 2 Jul 2025 02:01:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC5736B0096; Tue, 1 Jul 2025 22:01:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B76066B009A; Tue, 1 Jul 2025 22:01:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3DD26B009C; Tue, 1 Jul 2025 22:01:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8D06B6B0096 for ; Tue, 1 Jul 2025 22:01:41 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 12A67806A6 for ; Wed, 2 Jul 2025 02:01:41 +0000 (UTC) X-FDA: 83617673202.26.1B4C34F Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf03.hostedemail.com (Postfix) with ESMTP id CB5512000B for ; Wed, 2 Jul 2025 02:01:38 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=E9tdaCIl; spf=pass (imf03.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com; dmarc=pass (policy=none) header.from=zytor.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751421699; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xsBLzF3UyZbaFPKi2ZS9R/n92G41U6FG3scZwTR38ro=; b=eWkHLLhSxVvLygowpMmbMRUxdJhjKIOozVgYMLFgSyQYn7/RCpukuxhegwEtEtN2/0AEQ2 akSs5ZhY3Op7WKJtgzzItPJNWDTgqwI2aW373mEEQ9vMz0FS25Y9mU1IhiG9G/p5eAdSQ8 qSroBPhX8Beaej1+yAZfyEEXnvRSJWs= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=E9tdaCIl; spf=pass (imf03.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com; dmarc=pass (policy=none) header.from=zytor.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751421699; a=rsa-sha256; cv=none; b=O0+Nmkrfi0lTrAxdj4tnWohpWT4iBtuqjx7Z+ZLvLU2gQMgYjfcx2KkK6JFzhDntaqR5L3 YmQ3z0MTCyfg0zeODYvdcABk1w2aaYyPqQyIPteFPpXWpOHPz0KTH7wbcXH8N0LaHLzRpz GT7zqskbLII2//IoiHAQTDR1yLYgchY= Received: from [127.0.0.1] (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 56220cdX457483 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 1 Jul 2025 19:00:39 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 56220cdX457483 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025062101; t=1751421644; bh=xsBLzF3UyZbaFPKi2ZS9R/n92G41U6FG3scZwTR38ro=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=E9tdaCIlWT+jCmX/+CfRzVCcIpysnoePPDS0qBRG+lh62cVFQRL0dxVWZRJ3LnScw Tsashqy1y3xJZSpEXwiZ9Qu00tOwNawGjNZE+YNOgxYveInrBPbuugBo1Uc6hSKIdh dwii7pNyjYiH65+CHzJw7yze/mhjXafHpTqB1NLmmTuwBJDMuR6TQqD8gMkGdYg2Fe Hd1DsC8LD9MtNVn6u2hbb1tv6engmhSynp0QaC9W2InnY4Bs1dgNMJeSh8bBEGujaz l7TIiwlZdLySQWzRmZ31mFWxuqtlh4bJvgcXrWFWKSzjO5tly2wZIJOrQ7zynooele fPnwxEZaa89/w== Date: Tue, 01 Jul 2025 19:00:38 -0700 From: "H. Peter Anvin" To: Sohil Mehta , "Kirill A. Shutemov" , 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 CC: 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 User-Agent: K-9 Mail for Android In-Reply-To: <95dc18fd-73b0-4019-92d2-c0e6aaf22c96@intel.com> References: <20250701095849.2360685-1-kirill.shutemov@linux.intel.com> <20250701095849.2360685-15-kirill.shutemov@linux.intel.com> <95dc18fd-73b0-4019-92d2-c0e6aaf22c96@intel.com> Message-ID: <3D770C94-8BB8-4D71-BF48-6FA78C1DA967@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CB5512000B X-Stat-Signature: ua6pmxoeww98a15ixwswen9m86aeumjj X-HE-Tag: 1751421698-760616 X-HE-Meta: U2FsdGVkX18cL2W+yAEoAiaEaU1YvKPDz5y8uw97Eqp26X7UuX4V/nlD97gH8aTLXR1+N+5Db6HIpJYyK9XNmrIJa3Ws4uvxFxv3PlMZnCqVDygh57XHUyXfFdy8eoSCw4WA0mfgLWrYrNykiK5WKB2DevzfbgRrzARjMS/X0PLNutYeWw8IFUQ03EzjORUZlP6zJwZCM47auS97wQwM4Tfkyg8oP4Q5uvialHGqutYT9B7+reMH3KM9qCRg/1opx1rJqixwuxVCmzSJynlca3YyOdKlZizaqLaF/Ofnr0KAUGqqUvwuLCbl5iflWgGzOoWW6rbsGxqUabY36XJwbLdVEw4JIzJAwX4uQjzGEClA8cTLQ5oNg28Yo7QBxwm++detVu6Vr5r4dd38Hg//IPNBALR6CKQMYKn9VbDnPi4KVTf8OQT1Bt/QO7xhiBQeuaCD8Yrvpqg6C39CL3dOJIDSk/q11RopbTwntfIoTuw7VmxbrBGWABkqLT7EdYqrsetSBwnF9aB+eu0CFwkAbaqPQyP3S3MWnrFJq2cJdf5L0So5p6yGtRZ6OMO0lo3jGPQZv8egJtdFL8MPcUAeEtUXp/0JN037xzpi98EcGrxkoqhI3j3Qy8kKZoFRrhr+XC7F1rIVZRvqSjJtbirPMGKDlfUKI6+EcInYeKxhqwV3fc2oVZ4QKBZEz6ox35+iRJNVO6+Ge9HJi45qq+PnT8HsFb2tw1qScNQbE3KxozZe/D7YDcaA1/P+DTgQ9HvyEl6xqDszgnyqEb0b1w8ueUxVphCfP886BMJr3xKQAf+cbGt0TWzB2irgxHs3JOUE1/lmY7hqwrGYrpNVRGRwMgqMIwnhAtj8edOlhkKx+8TrtWDnBKSa5HJ014H0fQ43TqlsnwbKnO2MQwoRjCy3XXA3AKF1kgFTU2lNsu3eoEihuDoxbhVgk5lwfxAgzj+3w+gfBRDq+PtWwLLbSIw r0cMqaOl 4YW2HBxko3t5KwM4lhnXiBYT5U1x9YzklcUUHVnXWsqp2CYKsuQH9LKBaPDpslFzkINpiMJZgwcG+pyYI1rMOwEH1iUosGCD3bqFwh+X8bxXUpiaY64a7LgA5xI4PeEg5NL8E9Oyfp1sWk4cKDNP+LuB2SPN7rkVBVjKPTEscZpjX/EeyCdZR5AH6UaWQ5ISpJAm5f5RXDOxv6eeRnqjVKkuhNmtUSWPQS7jUeiuKab7h988BL7TwsmmCzQHXDXemCqb8sZQaPBvu+l+EHn9LlAEu23yuTgh1Z0XZctlN9xsI/7Ga9H9FBC0huDqu276gTF8ry0YfMNoNYRafnzJsHxl6NA8Ei3r30lZWB142Q2AGvVNvJWF4E/roq3zk99EeLvBaKIl3zdVybv9598OSajy5q8HgXQWeNw7ItGWkPyDRDBA= 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 July 1, 2025 6:35:40 PM PDT, Sohil Mehta wro= te: >On 7/1/2025 2:58 AM, Kirill A=2E Shutemov wrote: >> LASS throws a #GP for any violations except for stack register accesses= , >> in which case it throws a #SS instead=2E Handle this similarly to how o= ther >> LASS violations are handled=2E >>=20 > >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 #G= P? > >> In case of FRED, before handling #SS as LASS violation, kernel has to >> check if there's a fixup for the exception=2E It can address #SS due to >> invalid user context on ERETU=2E See 5105e7687ad3 ("x86/fred: Fixup >> fault on ERETU by jumping to fred_entrypoint_user") for more details=2E >>=20 >> Co-developed-by: Alexander Shishkin >> Signed-off-by: Alexander Shishkin >> Signed-off-by: Kirill A=2E Shutemov >> --- >> arch/x86/kernel/traps=2Ec | 39 +++++++++++++++++++++++++++++++++------ >> 1 file changed, 33 insertions(+), 6 deletions(-) >>=20 >> diff --git a/arch/x86/kernel/traps=2Ec b/arch/x86/kernel/traps=2Ec >> index ceb091f17a5b=2E=2Ef9ca5b911141 100644 >> --- a/arch/x86/kernel/traps=2Ec >> +++ b/arch/x86/kernel/traps=2Ec >> @@ -418,12 +418,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_segment_not_present) >> SIGBUS, 0, NULL); >> } >> =20 >> -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 =3D "alignment check"; >> @@ -866,6 +860,39 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection) >> cond_local_irq_disable(regs); >> } >> =20 >> +#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 =3D get_kernel_exc_address(regs, &exc_addr); >> + if (hint !=3D EXC_NO_HINT) { > >The brackets are not needed for singular statements=2E Also the max line >length is longer now=2E You can fit this all in a single line=2E > >> + printk(SSFSTR ", %s 0x%lx", kernel_exc_hint_help[hint], >> + exc_addr); >> + } >> + > >> + if (hint !=3D EXC_NON_CANONICAL) >> + exc_addr =3D 0; >> + >> + die_addr(SSFSTR, regs, error_code, exc_addr); > >The variable names in die_addr() should be generalized as well=2E They >seem to assume the caller to be a #GP handler=2E > >> + 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; > An #SS can be generated by the kernel if RSP is corrupted=2E This is fatal= , but as always we want to get a message out=2E