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 45345C83F04 for ; Wed, 2 Jul 2025 14:38:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6E0F6B00B1; Wed, 2 Jul 2025 10:38:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C45406B00B4; Wed, 2 Jul 2025 10:38:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B828B6B00B7; Wed, 2 Jul 2025 10:38:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AA53E6B00B1 for ; Wed, 2 Jul 2025 10:38:25 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4CF5C1A031E for ; Wed, 2 Jul 2025 14:38:25 +0000 (UTC) X-FDA: 83619580170.19.7B56E4F Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf20.hostedemail.com (Postfix) with ESMTP id 489CD1C001C for ; Wed, 2 Jul 2025 14:38:23 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=DXZ89xVF; spf=pass (imf20.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=1751467103; 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=vedweYDuCMOClUg69BFkxDuS10njABpMhtr+ugtmIEs=; b=M4eSB3//W3h+2XEqS3cW7SnoZkefJ5bb24SQUSezVXOOQJ8CvsT5KNP+oAUSLlCd79Ca1S uI40Z5C9eoepo5EXNy6AT5qoGoJ6Jj0a5+VxYwxVe+1EwfnDLwxLH33pyqTmKJ8qKsQg9J 1P75+C/oQV5ZlujHO6DTFV6/WOEyy08= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025062101 header.b=DXZ89xVF; spf=pass (imf20.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=1751467103; a=rsa-sha256; cv=none; b=IhTChN79DdumaLzYO5ql7ljBvYidLwoGx6qxxLHzJTxN5Tj0jZ5dTj1eJgS0CMG0ehr+Zp SdMXX13tCHDasL5pGVBDSQ2T0zlgjZRP3j+6DLyFcpZjX/C4KcPBB8fXo36HIzttA7DxJ0 3KldoDO/6+ZS2M+cgeRKp4TuHuquVHY= 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 562EbC76696595 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 2 Jul 2025 07:37:13 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 562EbC76696595 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025062101; t=1751467037; bh=vedweYDuCMOClUg69BFkxDuS10njABpMhtr+ugtmIEs=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=DXZ89xVFv179csAkJagaK7K6kHQFaO1KDExUYRflFnbk1CKN98H2A3X0BW/Xn7CWK p/lSdhUSOX3MLxFsLtQObgctvrt5fYTdx2cNChx0sxRkawi5k300cXWd33YvjZZXaX ptnAP5XKgtfJAwKM2gbk0WhT1PWBFWHOjUhOzoS+4Tnc0JrzdAkcCLu+z/sbmt+ZuE muZxbXuKzz/7sHrPRDIs6FwQyK7HKdhEmUXraWviKzczKfmEgA4gOl7SkARtW5uD2q AdnNdI4UkMYSWpFMLcq7+Ekbou+vpcFC6tLJhkFkxx1i5Bfk2w8mGaXVqiBnr6r2hj USlw9Y9IQLIZA== Date: Wed, 02 Jul 2025 07:37:12 -0700 From: "H. Peter Anvin" To: "Kirill A. Shutemov" 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 User-Agent: K-9 Mail for Android In-Reply-To: <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> <5q2zbkzyjknusd3feqolycqialetqfe52yfyzasnr6zp24pmej@4cg2r2hi4pf2> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 489CD1C001C X-Stat-Signature: 573kn3txqjb8fuqqp8pmj9ihh71976pc X-Rspam-User: X-HE-Tag: 1751467103-443531 X-HE-Meta: U2FsdGVkX18RcqIcLB43qZNF77xEFGRrRQ5QOt0VOBPrNSsuy+dOzIdBW8AajODv5bl5dUHymCDu+6C7rtokH+durQZI6MEp3JREVOqglhtjCDBB6qSMP+3MDuVFzRkme3LbUn+LRwimOABI3v/B6kQ1KGKb47P5BrfdKf0oS4eOhZJOuDi5IhZ0VMSRJIJ4tjQuczJxjNwVfHbCFqVG4luZT7WEZkIQmHLHPRYj2GmqZC3uBjh3V+hkwt1q8qnaczGYqQvjNmcz8rcmKAHOLa+KNUZVxaU5VtYQy9k9/17faW416CfUcP1e4x7EfPCBTdj4ZyNfuejCllw3l0tZv42SqzPwhdbRu/6LmUSQ6rF3gMFozz433qEWJKFJZJAzUMxg+7Epl3UOYHKg+McOAwBGl+Ok1Vk5Wmbd6itL/ogNVQETRtxXJgCum657bT11mFGY1b3BcVh7VkCg3DIm2NTiSyy4rQeMysGMPVDXbHmEzkgPVCgzsdhV1ohXptVKLaAcL8GWPiFXPyWt5Hya5S5eJALC5QyJuw+0D0AqlUn35bw1rexh8LrhHj9xKgBPgstvcWeiINhUzmOCUYyq5IX/DZ3kEZs8/d1Tv/nkmagOJr+oSMCgb8sR2yAYvpN6gQPVEEAH7Soh2xWnLvyt4/61tZk/qqwbHJY1HaDOLYXM0RUUACl3IjLY0O8mf2Ml9X/lTgWnHPp/gwVhyyWaTSfPOAi5RTxDJn6BIHvXPds5pxk4hSXYRG4I57LVADi5rCzecDZo7rsWuH7vFXHJ/azHDSrzPacWrEzXvJHILyXR+EHgZOOkBQ1ruchCObd0BvOzS9Gsvqd5EYka2nyqHSm6maYhpKX/MvJgvGZKWdbEC5b59m6iWA/XdiLn4yU83mHOzdEODcpZFT3CUEQ+RKlYoCIt084/bE3eJfvwfULP78b9eVCQilZOewep7zDR/GZN97FVDapVrzJB5Nr VFkAqIX/ foA/tf6McaYbhR8JmFAzOe08AZuXSqhmgvw3hT4RzHBzulkXE0xTgq/vbjzinpM6COPrxGr6V8eHWt2kYX3l/d5UHosH4sD5ldTVxJzM4xOxroISeak5tgEcY7Ks4ZVpjO1uvfT/e34v1W/sVa3Rfp0PTe2dqF1+k+9Y9uId9us6c/G9YG6s+AriBVjXn/Bn+P0HO4vce9NbQGto2Bo170UAOqrJxije2esGZ+f/MykWJTlCSr7J5+yb8PgaCXXqZrA/3H3oGQI8ayd+v37m1aYK5VKRuhqLq498xY2zpIAP2vaZVupcphRq/w6D6JKsakjVhf0JTvVpd6kPRN54rKiEutxOcprUE24rB+TdU7pXKh35x2qbNxd5T5DXEYUu8bqrG3hybk/6N/48bqfuFn2ED8klEM2SMueRIbwy9jyEyP8c= 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 2, 2025 3:17:10 AM PDT, "Kirill A=2E Shutemov" wrote: >On Tue, Jul 01, 2025 at 07:06:10PM -0700, H=2E Peter Anvin wrote: >> On July 1, 2025 6:35:40 PM PDT, Sohil Mehta = wrote: >> >On 7/1/2025 2:58 AM, Kirill A=2E Shutemov wrote: >> >> LASS throws a #GP for any violations except for stack register acces= ses, >> >> in which case it throws a #SS instead=2E Handle this similarly to ho= w other >> >> 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= #GP? >> > >> >> In case of FRED, before handling #SS as LASS violation, kernel has t= o >> >> 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_prese= nt) >> >> SIGBUS, 0, NULL); >> >> } >> >> =20 >> >> -DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment) >> >> -{ >> >> - do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGB= US, >> >> - 0, NULL); >> >> -} >> >> - >> >> DEFINE_IDTENTRY_ERRORCODE(exc_alignment_check) >> >> { >> >> char *str =3D "alignment check"; >> >> @@ -866,6 +860,39 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protectio= n) >> >> 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 li= ne >> >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, SIGB= US, >> >> + 0, NULL); >> >> +} >> >> + >> >> static bool do_int3(struct pt_regs *regs) >> >> { >> >> int res; >> > >>=20 >> Note: for a FRED system, ERETU can generate #SS for a non-canonical use= r space RSP even in the absence of LASS, so if that is not currently handle= d that is an active bug=2E > >It is handled by fixup code inside do_error_trap()=2E We need to add >explicit fixup before LASS handling to avoid treating bad userspace RSP a= s >kernel LASS violation=2E > Great=2E I was pretty sure, but I wanted to address Sohil's question direc= tly=2E Thanks for verifying=2E A LASS violation of any kind in the kernel (unless handled by fixup, inclu= ding user access fixup) ought to be fatal, correct?