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 43A75C04FFE for ; Wed, 8 May 2024 23:24:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B37E6B0083; Wed, 8 May 2024 19:24:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 963B96B0088; Wed, 8 May 2024 19:24:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82B206B0089; Wed, 8 May 2024 19:24:04 -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 5F99D6B0083 for ; Wed, 8 May 2024 19:24:04 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 031A2C123B for ; Wed, 8 May 2024 23:24:03 +0000 (UTC) X-FDA: 82096808808.07.351290A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 499DE40013 for ; Wed, 8 May 2024 23:24:02 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of "SRS0=lPt4=ML=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=lPt4=ML=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715210642; a=rsa-sha256; cv=none; b=fbWrY+jjV0WTUa13x5gDrTrsEZEXmtdOtmhHEFtKbeQFtZ5pNANv8iFLB+ec1fCb4WJfLZ hBAlVfBI+wMLecDSSgB4+VfXTGuYyoEdQp2tCgVd6CDFFibhosRq1jwD8iEOBEa5Ne1KpO yiIhEqpF0/JljPMSSey6OeE4GlWYezo= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of "SRS0=lPt4=ML=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=lPt4=ML=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715210642; 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; bh=zFCoZuGz11CxDIRGICZr+U4KGaLYzQ/+gxe2mCyy8y0=; b=JndU8vczq9yPOwFufMUt/W8RwzgSfVGc2kd/tRMFcAK8E37mLNw3nrZyfaYRu7+Ygq41Fu o8m/sKK5yoQcWbTYpVIsGLWx0HMGYu5xOKi5fA+X1OQQSOYC8HAR7eIWM0NXiBPJewYrUk QEdltqnWcJ7/FoYeq1076QLajvruie4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EBA0E61A0A; Wed, 8 May 2024 23:24:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96026C113CC; Wed, 8 May 2024 23:23:59 +0000 (UTC) Date: Wed, 8 May 2024 19:23:57 -0400 From: Steven Rostedt To: Ard Biesheuvel Cc: Mike Rapoport , Kees Cook , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Tony Luck , "Guilherme G. Piccoli" , linux-hardening@vger.kernel.org, Guenter Roeck , Ross Zwisler , wklin@google.com, Vineeth Remanan Pillai , Joel Fernandes , Suleiman Souhlal , Linus Torvalds , Catalin Marinas , Will Deacon Subject: Re: [POC][RFC][PATCH 1/2] mm/x86: Add wildcard * option as memmap=nn*align:name Message-ID: <20240508192357.72bfcb81@rorschach.local.home> In-Reply-To: References: <20240409210254.660888920@goodmis.org> <20240409211351.075320273@goodmis.org> <202404091521.B63E85D@keescook> <20240409191156.5f92a15c@gandalf.local.home> <202404091638.2F98764A41@keescook> <20240412181940.3e1d99f7@gandalf.local.home> <202404151017.FC002AA5@keescook> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: tioktjeqhqqmng7h8jqucx39mfgphyeo X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 499DE40013 X-HE-Tag: 1715210642-459180 X-HE-Meta: U2FsdGVkX1+hIs/5AABmk8bRsljnbzXmS5zP7t/8dp2hkGbmqD//ilNVfqaTjLkI2HO9ITqhFIsMGqXfE0xJp81yQ9ELLlBI2PQDVeF+o2Cv23KkXULeNRjJU49cp762KEJLI/MyhHACzSYHIP48iMaNVqzDc5/EvzRBY+KlEZMhkq9Tz8DjRcop1kNBG529Io4wUvc1yhkEdgLB2sCtqNq5pX3l9Yd44iRhEnCwZ8T8r45VsjZYTf6nydvrjxri5Hqlzje1UUF6dk84wFAMeLbGPgGkVacLfSQLwCHoVmAeFUBQoJXHWjePv8+/LqzmhaD0txFucoRdUhgY5bC++lNH4iMNVYYWPAEb/IpfTVcdFuoO2IbvsX9PkiJ9qgwahjOw9JcAcHsHeFINsTQGq8IZKqrnJpXp/Akfna9aJ9msgMdjWb2Q7liXpDfWTdDmUJaua0fPDTiihCCktxdwyWgb6+GnqmOo6xiewPqTrr4QFXkGZHPIloTQ0VY7FtPk0ah5yHU/xKCNeL4n8eud8sk2NS+a39I5FoLPLkPdbLY6pg/dzxpc/R3XAas1rY43OOEu8r2bW8bgt2DDKFqaLzBoc6Sr0sHuV86ITgDA4Sg0XMJCIhi5ntABv8R0yIJdcJYj+KAybODX3R0VPxV4ObDaie3zpT1rd48kJMTor50lR8mzcqCUivlZYaSIv2dzqzJkBDBFRBvOYHBS9cuSlGgD6Nx6IdYiw5hH/attfxLaurTCBh8HizZY/O9ZxKnIvGFIpYO7edNgySb7zkZ7M4dHdc8jZVf6OpaOd1NWJtyJT+PITiLVQQupF3P8djBMSRbf+WEL/wt6rvWkWvIQs6TJCVEI+GW8E1iITRIOYTqOJ0h/qwz9szB2Pfm2RTTTW/QlxRFNtcOCzmw+9+GfQ2XLMrFyIw/wfBuoHQWFrRF713F1e50lwlEO3n3N/UkWJp2YyJgTVy6YNZFxWhB O0SQMoGc Skms26i+QZIVIgz+c82jDR6djGO5lwkomIP1io5yB0sYs87NMkuVijNk/IHKh4WpuDnaYb0AnjVky5S15hZzjAol8vjChODcaHOrH6mJxS7gYUKvexc3cJThUSfIhgnlmuYWoyJUxEPzba+CiSTCdkR6vntLlSAo/fAIyy4c/ZBZqQZRTB6/+S19Z56WHlZ9rutXV9SrsC0zguexrXco+T7EqJFyGIxnu63X2ucx/eTDRT+F1AZBXsq5Y5ha4Vtlp6VoYJ955LICeU5dMzaxZx2hjg2cb66+bY5frfJGq6k43pyMvC6TFjyaL3w== 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 Mon, 6 May 2024 12:38:32 +0200 Ard Biesheuvel wrote: > The logic in arch/x86/boot/compressed/kaslr.c is now only used by non-EFI boot. > > In general, I am highly skeptical that hopes and prayers are enough to > prevent the firmware from stepping on such a region, unless this is > only a best effort thing, and failures are acceptable. For instance, I would be very happy with just a "best effort" approach. I think kexec/kdump has the same issue and it hasn't been a problem in practice. > booting an EFI system with/without an external display attached, or > with a USB device inserted (without even using it during boot) will > impact the memory map, to the extent that the E820 table derived from > it may look different. (EFI tries to keep the runtime regions in the > same place but the boot-time regions are allocated/freed on demand) Part of my requirement was that the system is exactly the same (no changes to hardware or even the kernel). > > So I would strongly urge to address this properly, and work with > firmware folks to define some kind of protocol for this. We could possibly add that later, but honesty, that is something that I doubt would ever happen. You would have to get buy-in from all firmware stakeholders. I'm not sure if this is a big enough use case for them to even take a look at it. The main use case for this work is for pstore to have crash information of what happened up to the crash. In 99.99% of the time, the firmware or kaslr will not use the memory that was needed, and you can get very useful information from the crash info. If the pstore is moved, it should be able to see that the memory is garbage and just reset it. Note that we can not use kexec/kdump in the field for various reasons, and I need a way to reserve memory for several different devices (both x86 and arm). -- Steve