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 CE8D1C7EE30 for ; Thu, 26 Jun 2025 12:47:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EE6B6B009D; Thu, 26 Jun 2025 08:47:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69E746B009E; Thu, 26 Jun 2025 08:47:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58D9E6B009F; Thu, 26 Jun 2025 08:47:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4552D6B009D for ; Thu, 26 Jun 2025 08:47:53 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D4F9F1601D2 for ; Thu, 26 Jun 2025 12:47:52 +0000 (UTC) X-FDA: 83597528784.09.653BFD2 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by imf25.hostedemail.com (Postfix) with ESMTP id 38FFBA0003 for ; Thu, 26 Jun 2025 12:47:50 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=nbRdv3bm; spf=none (imf25.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.12) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750942070; 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=vt5abggpTC0eWIS/ONjafvm5zdsh6cp1TnZyIaISQKk=; b=VSMoKBJ2YBJ7++hzljr3UILmsSdJvDxDgj9EYAKlxPnV8T0HSIWMfDw+gTdpsZOwznLp6m 8GUkNOgB1I+K+nIZ65fWcXGHevVBpC+Sto1Rs7t0hjo8msx377xM82wlmtrB/48VZ/JrVA cMC6dKQWLaDLvk/XLOS1c68PRh8+SSM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=nbRdv3bm; spf=none (imf25.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.12) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750942070; a=rsa-sha256; cv=none; b=xNu9KxQydq4dHGA1yEDUNyU5dQLhrn7zowP9ARoZWZwIOLS72LzOj350mQv/COZ8IWBFn6 JjT3ggGE6lB01LzYIr2XiUvhvmh6dRGqfNXTWPBE6tRttDy/503I8Uef4tRkrpyNEE34/S PLgYnOVxf/er7YsVpeV+h5YuAw1sDNc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1750942070; x=1782478070; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=yEVEVPCgQVDBf9e9XQZU0mmeebKCotKG0hlhjNKE7CQ=; b=nbRdv3bmk2t79kHnZthRtdispeoET0Dfg+MwF0fz4vvJiPRp78YFOAv7 nTJHAojNydF+pi4/fCC+ngDzql8qF7a+HWeb9HtGm9gPw6e5f5tOLpUnx HT1wcXtGeHPjbVJHLHnL7PsOl4epheCm6ua/ihfffd5wzpua5qk7aNZ3e V1xQUC6WOOu/WrKPYoupPSx78Bc9tJSUIrTbv77oy9MyCTxNr2qWR+DN+ 7v51EST4lMlFBCPeo5RHHNoQzzkmb7yJcA1OcSJGdF+XZkW/nNGJRChJk tQoedlaJkqT0TBeQM9xU2C01zQWWgMchiM+A8nH5FPIUnoMkULpxrpcPH A==; X-CSE-ConnectionGUID: D9SopsigQICujT/Ot7sDFA== X-CSE-MsgGUID: fyuAO1VlQwyh0HQDclnRWQ== X-IronPort-AV: E=McAfee;i="6800,10657,11475"; a="64671202" X-IronPort-AV: E=Sophos;i="6.16,267,1744095600"; d="scan'208";a="64671202" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2025 05:47:49 -0700 X-CSE-ConnectionGUID: eHSQK0fJQgOPUviOTHUIMw== X-CSE-MsgGUID: 5nVvn7pvSaSl7xzcMHvB0g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,267,1744095600"; d="scan'208";a="152266048" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa009.jf.intel.com with ESMTP; 26 Jun 2025 05:47:38 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 2F23A2E2; Thu, 26 Jun 2025 15:47:36 +0300 (EEST) Date: Thu, 26 Jun 2025 15:47:36 +0300 From: "Kirill A. Shutemov" To: Vegard Nossum Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , 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 , Sohil Mehta , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , 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: [PATCHv7 00/16] x86: Enable Linear Address Space Separation support Message-ID: References: <20250625125112.3943745-1-kirill.shutemov@linux.intel.com> <9b1c5e43-ff48-4af8-9ec8-1c1dc2b902ae@oracle.com> <1b96b0ca-5c14-4271-86c1-c305bf052b16@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1b96b0ca-5c14-4271-86c1-c305bf052b16@oracle.com> X-Rspamd-Server: rspam11 X-Rspam-User: X-Rspamd-Queue-Id: 38FFBA0003 X-Stat-Signature: gow7c8tabjx63umjibyzqt7qcubo5x3u X-HE-Tag: 1750942070-842136 X-HE-Meta: U2FsdGVkX1/bO6pxD4YuVIghdjE2krLNwxsbkUNiA6xxDOuUvPwTadjmlSykf+nLiBkdbn+QBBWk81MkjqNbftWAMSEdJ+SmG+brrhspeBYWkGEuQEYH+A3apYRvDmJ7cOvL7NcSwXkzAg+lkta1FoESMJZO/xkIu7i1KmNFnTJg87eKj93JmaqtIBLOvF5nZWPK7NhNQs1rLg1CBcBd+nwwwqDo2QWBIuYReMukMOENBESu8Sn63SDIj3vckBJyoS6YQRjtDo4lIg6OPhHtYDGmB2qjGvmQoQm4XnKMaqe+LsRZEdDL8mhc5Q6K65tbK7u2sgMQ5TMAOByvrJKsLZVeQ23iWKKg+Q5/WE9VT4eTPzWCyvB+FKIWaD6UPbQ6v3nfTe7L9I8iVwCwcvYVMj2H4c5YO1hESPB3WcXCXYrKSOneJDWzpWZ4fgVePL4xSQGaPVSOBpRjfpcJm/rXCO7jkK3wk/pdr/2Ut8Wc+eLGlZPIwYx0GeqJka6Z+IyEU722Jw4kCDmyB94wx9meGr5E+kl6APUKgL6Eb2SFJFCSCHJ1Chuj0Bs8JtfLtvMWU2wjNcuS98wbxZjXkYCTmuwbVOjPtSkarcCIhG92FPzznvCa7QXNpdg9OSuDzHdjlp//iAWxN3E2r1VUB9tkY61L5jIEpqbPB2Hkbv73Z/TakL5ZVyIO1Httkn4iDzsCNtAF6nefgO6DMPoQ0qbiF8pnJxZrhnAapq1NekQu++s1RD6J5MKi6fiqZsG/tPfu50Neq1IY1G925dVlVL+ut7ctuV/2R464KqS1S0CwYxYUoJ35p/NkaEp6BJWtFMlxToFwAFfErNdyUP7uMGqaOFXOW90Y8uURZIl4Yt7CC6gYQEmCPcMntYuHUe1D8vdZTn+nDRw72fpNWuuw2dsSApRoo3QV9z64SrP8mon8cjJm1SUtacy5v6h72sPSuOpyCS6kKWj40IBL6Gu0+hK CA8ppKxu 2hdxelrIrh6SDPayaczh4g3yDioHcXgQu9wQydXhq3A3nK9o127+0laavsxYL4qGgHCIU4UDzvfiUCjDkh3cudDhUmdgwXmRnocZVOFPOiMfIJ7aLCOg+gOzUSwBxtQJansyB9MfivXVPVZBeRvqhUGpSxd8UlX40wOkH/7INYgF10e1G0TprCiFVN54RCBSM+sl0PC7ISg0F5Qdjd+GzbcJZ816G9wXUOTvTVmS4pV4UBTXBzvweMeEH/8f+KLtCLHOq/xYK94ZLILv1R6QVNMB0HePBLkm/I+t2 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 Thu, Jun 26, 2025 at 11:35:21AM +0200, Vegard Nossum wrote: > > On 26/06/2025 11:22, Vegard Nossum wrote: > > > > On 25/06/2025 14:50, Kirill A. Shutemov wrote: > > > Linear Address Space Separation (LASS) is a security feature that > > > intends to > > > prevent malicious virtual address space accesses across user/kernel mode. > > > > I applied these patches on top of tip/master and when I try to boot it > > fails with errno 12 (ENOMEM - Cannot allocate memory): > > > > [    1.517526] Kernel panic - not syncing: Requested init /bin/bash > > failed (error -12). For some reason, I failed to reproduce it. What is your toolchain? > > Just using standard defconfig and booting in qemu/KVM with 2G RAM. > > > > Bisect lands on "x86/asm: Introduce inline memcpy and memset". > > I think the newly added mulq to rep_stos_alternative clobbers %rdx, Yes, it makes sense. > at > least this patch fixed it for me: > > diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h > index 5cd0f18a431fe..bc096526432a1 100644 > --- a/arch/x86/include/asm/string.h > +++ b/arch/x86/include/asm/string.h > @@ -28,7 +28,7 @@ static __always_inline void *__inline_memcpy(void *to, > const void *from, size_t > "2:\n\t" > _ASM_EXTABLE_UA(1b, 2b) > :"+c" (len), "+D" (to), "+S" (from), > ASM_CALL_CONSTRAINT > - : : "memory", _ASM_AX); > + : : "memory", _ASM_AX, _ASM_DX); > > return ret + len; > } This part is not needed. rep_movs_alternative() doesn't touch RDX. I will fold the patch below. Or maybe some asm guru can suggest a better way to fix it without clobbering RDX? diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h index 5cd0f18a431f..b0a26a3f11e0 100644 --- a/arch/x86/include/asm/string.h +++ b/arch/x86/include/asm/string.h @@ -44,7 +44,7 @@ static __always_inline void *__inline_memset(void *addr, int v, size_t len) _ASM_EXTABLE_UA(1b, 2b) : "+c" (len), "+D" (addr), ASM_CALL_CONSTRAINT : "a" ((uint8_t)v) - : "memory", _ASM_SI); + : "memory", _ASM_SI, _ASM_DX); return ret + len; } diff --git a/arch/x86/lib/clear_page_64.S b/arch/x86/lib/clear_page_64.S index ca94828def62..d904c781fa3f 100644 --- a/arch/x86/lib/clear_page_64.S +++ b/arch/x86/lib/clear_page_64.S @@ -64,12 +64,15 @@ EXPORT_SYMBOL_GPL(clear_page_erms) * * Output: * rcx: uncleared bytes or 0 if successful. + * rdx: clobbered */ SYM_FUNC_START(rep_stos_alternative) ANNOTATE_NOENDBR movzbq %al, %rsi movabs $0x0101010101010101, %rax + + /* %rdx:%rax = %rax * %rsi */ mulq %rsi cmpq $64,%rcx -- Kiryl Shutsemau / Kirill A. Shutemov