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 A48F9C27C55 for ; Mon, 10 Jun 2024 17:02:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EA3F6B0095; Mon, 10 Jun 2024 13:02:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29A6B6B0096; Mon, 10 Jun 2024 13:02:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 162656B0098; Mon, 10 Jun 2024 13:02:15 -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 ED7C56B0095 for ; Mon, 10 Jun 2024 13:02:14 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A95E9A0C9B for ; Mon, 10 Jun 2024 17:02:14 +0000 (UTC) X-FDA: 82215596988.06.1CD3BAE Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf06.hostedemail.com (Postfix) with ESMTP id 35C12180015 for ; Mon, 10 Jun 2024 17:02:10 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ti3YrOvh; spf=pass (imf06.hostedemail.com: domain of kees@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718038932; a=rsa-sha256; cv=none; b=8K9+tWpNq3ObVjk6PBUfk51pxvCMi4qVq3WeE6j2WaxuT/3mAYKnYyH1ddbo65lHGa1c2B 61DmvTlC7hitobpGXsIuMm1cZg+PobhcXx4nD/Jvvk/8+Fm2uervMVpkuVH0horen0mk9j DG4ip4m8j3uihb0xSs0sO33UZUSeP3s= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ti3YrOvh; spf=pass (imf06.hostedemail.com: domain of kees@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718038932; 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=eVlEcHfF80iKfLaqatoE33k/NEhsBfjLtQ95b6hAHFA=; b=aF2a3Y7+cxy7HubuWqYHNvFxFUMeq/0QC6LBbO/HnLrOE2qhxlvkunVAcOKGE/xPMT8XTc 2rEaLUnhEWd5UixJtIe+2/1dm1kvts/vZWYP4TCr3RWa6JTLmiX1VK8fC4m5OU74a5O5Ad /s5o9i3bjDHDkkSx24m+mG9pz/dp9f0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id F2FB2CE147A; Mon, 10 Jun 2024 17:02:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33F37C2BBFC; Mon, 10 Jun 2024 17:02:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718038926; bh=WFeffItMXMcz+XG1+wQHxMIyeQdKyjz6JLP3Gz+RuNw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ti3YrOvh6kr5L5/NEmkjAc5sZJGS2uB9eaN9LfnQmvR7CYr1QvL70SPO1fFt+U3b+ doxRofUpDLlm82KDuIFhpGfxLe1vkjZjOSUgNJ0+fLX2LXO7StMGCMkXufzn8drQN0 6OiNHM6Uf/ryvFLlmDbEEHSfOU8ryT/2wjZqzX6aV4iZP3D7Gd78TistJY9yFMMTF4 UEcLNDRf5z0B0KLJWltETSvBp/o3kbaYzMNKlw8C8TXulzA6FAytCGJHVjUX+b1oWu UeSi5LdyRoEd5kDGRZlhTAcaT5HWBWlYEdD+5IdM7uZStDBCz/CJGdxOi9VuvbLqOD 9AOlEQ2ImzyDw== Date: Mon, 10 Jun 2024 10:02:05 -0700 From: Kees Cook To: "Guilherme G. Piccoli" Cc: Steven Rostedt , 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 , 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 , Ard Biesheuvel Subject: Re: [PATCH v2 0/2] mm/memblock: Add "reserve_mem" to reserved named memory at boot up Message-ID: <202406101001.D469C9A@keescook> References: <20240606150143.876469296@goodmis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 35C12180015 X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: rzw8i35eb9hrg8pi9giwezu6gji1eqmt X-HE-Tag: 1718038930-46257 X-HE-Meta: U2FsdGVkX18BNojKZt64tnFj4JleSlqTEFCWWdXjt/5XXd07XSqGMZo2VQTrNRHZ9uD4vHaOr716+NuW7MQaIZIeVL5Ad5c2a1vjB/a7cE+RnuHCpbrdOHFGuG9+ZTGxQkHxmiB3A5Lys7XIC3QwDV8JZNQIegArNGuZdc9QYgDWVwkaDqS3B1PKZIWsGyjPGls+WPzLkaejidm+Ab12VNN2UpKeD8k66n192ChL7933dQuZfu3ovQf2U+AtQJWXG41WsiYXCmw36/PiuD5GBgflx6fc5Lg8LukN5EIGKLWgGsPSqPvihOeBXL1aSiEOxVK92qttDZkjWtf3dQLPN4zhiGmLE6FhNd0GxvAZIw6Q4qmFRCdV6LhNzZ52KCCagWBWgif3cqYZHnMHaYKg1RbZIo5km6USRcV2bXUdRb6mpUFgCMYf/f2DzuozA9tk80R0kiqdjEGKQ2/vAfHO4lbt7Pwf7/MOdQltFj0GJBObVaQVl8SOmOvuxZQqTckZPjJPGmzAMPCqKa4RLy5Qjh1PeJVYEyP7X+auIq1Jk21PAWy8gEzSooJnNwrqzOcRIVOxHgo65QFiTBTjUbDVl1mSjy/4Ig7Dr0p/BpZZhC7gA5B9G45dbXGFqzhbIgGkDdhJXJHMkNbnNQ2D2k7c7uPioX4Du+Kcv+F5367xPJePYBOSZbn4UjhQVbltvnacaQC5PBbJLtwT/A9/qe+e3Y1BJegqZPPwSjBbjkB8L+UcwT3/M77Vvz2AuFqfA4QYeneYz9X4RcMQEZSk7IDRPm3u7xMIbD3kT9JaplddP6r7Oc0lgB7tkFXxJn8foWhd5trQeabFVI0AAxvDBS24DHb6/zSEmOapamTRioItk6ylsNLSrgxcTYZSy5x2HZgSyWdXT1LIxxB+FvyzBwgXoFY80m+eOe22TBXKxP8dmWSQk106hwAVa7w9nHN2BMfLtcnif0sasedY7u0LSoJ itqjeHSa EZMXeRCeVm1hpckOKti1/51l2Jp1Occgr+QracU8QWNfsK0ZgrxQzRrgoAQGSF5RN3kZ+NfCT2ZNc4sDEa1vKYFkrzY1/TfIqgdhS/pOmKIFH65tRCFT4eSlz/4tMPfO375z9nErOPzCugNIMni6DHmoP6saNIHCml0rKWPbfZCObyFx4HstCdM/JwrrZ4apklOqvRQ80at7X8g2raYeq/D40RrGrV39IPVhf2x4tOj4nowmBwa2R+R3W8BuG5lCl1US9bQyYf3qd7K98mIcXPsdTh8LvEGaz8ebHpLv8tTVKEGY= 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 Fri, Jun 07, 2024 at 04:54:41PM -0300, Guilherme G. Piccoli wrote: > On 06/06/2024 12:01, Steven Rostedt wrote: > > Reserve unspecified location of physical memory from kernel command line > > [...] > > Solution: > > > > The solution I have come up with is to introduce a new "reserve_mem=" kernel > > command line. This parameter takes the following format: > > > > reserve_mem=nn:align:label > > > > Where nn is the size of memory to reserve, the align is the alignment of > > that memory, and label is the way for other sub-systems to find that memory. > > This way the kernel command line could have: > > > > reserve_mem=12M:4096:oops ramoops.mem_name=oops > > > > At boot up, the kernel will search for 12 megabytes in usable memory regions > > with an alignment of 4096. It will start at the highest regions and work its > > way down (for those old devices that want access to lower address DMA). When > > it finds a region, it will save it off in a small table and mark it with the > > "oops" label. Then the pstore ramoops sub-system could ask for that memory > > and location, and it will map itself there. > > > > This prototype allows for 8 different mappings (which may be overkill, 4 is > > probably plenty) with 16 byte size to store the label. > > > > I have tested this and it works for us to solve the above problem. We can > > update the kernel and command line and increase the size of pstore without > > needing to update the firmware, or knowing every memory layout of each > > board. I only tested this locally, it has not been tested in the field. > > > > Hi Steve, first of all, thanks for this work! This is much appreciated. > The kdumpst tooling (Arch Linux) makes use of pstore when available, and > the recommendation so far was to reserve memory somehow, like "mem=" or > use kdump instead, if no free RAM area was available. > > With your solution, things get way more "elegant". Also, I think we all > know pstore is not 100% reliable, specially the RAM backend due to > already mentioned reasons (like FW memory retraining, ECC memory, etc), > but it's great we have a mechanism to **try it**. If it works, awesome - > for statistical analysis, this is very useful; pstore has been used with > success in the Steam Deck, for example. > > With all that said, I've tested your patches on top of 6.10-rc2 in 2 > qemu VMs (one running legacy BIOS - seabios - and the other UEFI - using > ovmf) and on Steam Deck, and it's working flawlessly. I've tested only > using ramoops as module. > > Some code review in the patches themselves (like a missing > EXPORT_SYMBOL_GPL), but all in all, that's a great addition! Feel free > to add my: > > Tested-by: Guilherme G. Piccoli Yeah, I think this looks good as long as it's understood to be a "best effort", and will radically simplify doing qemu testing, etc. I expect I can take v3 into -next with the fixes Guilherme noted. -Kees -- Kees Cook