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 68588C67861 for ; Tue, 9 Apr 2024 22:23:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0459C6B0085; Tue, 9 Apr 2024 18:23:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F37A16B0089; Tue, 9 Apr 2024 18:23:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFFC36B008A; Tue, 9 Apr 2024 18:23:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BF2006B0089 for ; Tue, 9 Apr 2024 18:23:11 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7BD8140119 for ; Tue, 9 Apr 2024 22:23:11 +0000 (UTC) X-FDA: 81991420182.14.EC6B85D Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf28.hostedemail.com (Postfix) with ESMTP id 9C27AC000E for ; Tue, 9 Apr 2024 22:23:09 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=UEOP18Qu; spf=pass (imf28.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.171 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712701389; a=rsa-sha256; cv=none; b=MbFjqZaM1W/41pS1tkBVZI/aUbWs+mKESAwgwBGlelhwcwHosHfMRGNngDpyQHXyreosDG ZKaxCV2YYzNtwr5ib1L1rsXzZo93t+tGyeLYvsuSgEDLT/4VrkHIwhbOY1Fuz7k80I5nAA Snf9lz6RTVW+zB/ykr8wbtwXIjACFwE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=UEOP18Qu; spf=pass (imf28.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.171 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712701389; 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=SuLQgIPqrOGCGrvwUhSgQ0Doo+WUpy3yKdb+8HV/Ppw=; b=PQJ92p1JBXaMbhbuEocaXHsZeBgoYO2YftxvLfxAkBRK6Q4AjlPNX2Xq6+mlFkjM455LZb 7Nt5XvqGi5RXgY0f9U5tRB5BL/4LKyH2T2jiGQu2rXksaRzFTk9nsST+nNandOr4R8mxcr U/ZLetHnDpEcmNfC9rKwmM7YhgO2YIw= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1e4f341330fso297065ad.0 for ; Tue, 09 Apr 2024 15:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1712701388; x=1713306188; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=SuLQgIPqrOGCGrvwUhSgQ0Doo+WUpy3yKdb+8HV/Ppw=; b=UEOP18QuFooi+b38FgXkmx+P2fnih8WYfpaaOcGCAJ7YX+Ad9rKliVzDbHaFsl2R+L Qu+e2DQdnYv4xkPZQMuXSgJ9IgEYzQ0I7Jr0MLf35Wgr47jg949mXJwoPEWn4SJYu9A4 ZSnzV9eobYODd+tAvbFi++8FsGQOSVcLSfv20= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712701388; x=1713306188; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SuLQgIPqrOGCGrvwUhSgQ0Doo+WUpy3yKdb+8HV/Ppw=; b=onNTT9k2/Fwdov1Ju4NTXOsodxLr+QWLOhoqTDxvM3K242ZHiDWvhKhjFzvqh+EKok XmUAMLmdKVNZ+vBC+fYgbocymzl9Cf7OXG0I5YxrzyhJ5ruajrnDtvctIyDTijCQMCb7 z1sK0OjryNJSc9i25yr6FxrHbzr7J1OvQzSwdpy0K3D4iF5LWlnNiTriAh0wnbDqiIJs 8oati1Gxt65yzUlI00esVw1qajiQgh+JklOTYErRSFZYYn3unfGc8iS4YWIZVJ9gbI13 GNq1T7WqXb317To+drThJzHYxoMJo6UJfwFZOet7BDkkerHpDGv4T1U21EhH/OgtAHai lo2A== X-Forwarded-Encrypted: i=1; AJvYcCUP59NCSYMU9QvxXWFYuKoEaSsJClNNp+8Etd6jQx7C89i8ruSQGB3SxdBSC9if3Xx4rhL0huiz+LnidEGKn/DtlJM= X-Gm-Message-State: AOJu0YyI3/KQsY3LYQNeYxgymWmibZfqA49dorhA/GV8a1LHn6sYegfA BoLcehZis++MR0K0B9+Zyw3TY4QayPdfRMARKq9dbky+Xr+vjwiI3LWI05pIxg== X-Google-Smtp-Source: AGHT+IGdZCQ6OZYRXUtTSII6tqnCYFblnnzuJzQ5H00+Zb9dJ8S3bAgG3vMV8MTsugbMJ44iIbnlug== X-Received: by 2002:a17:903:1c7:b0:1e4:2b70:2f17 with SMTP id e7-20020a17090301c700b001e42b702f17mr1166729plh.52.1712701388466; Tue, 09 Apr 2024 15:23:08 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id u2-20020a1709026e0200b001e26d572f9esm1661164plk.242.2024.04.09.15.23.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Apr 2024 15:23:07 -0700 (PDT) Date: Tue, 9 Apr 2024 15:23:07 -0700 From: Kees Cook To: Steven Rostedt Cc: 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: <202404091521.B63E85D@keescook> References: <20240409210254.660888920@goodmis.org> <20240409211351.075320273@goodmis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240409211351.075320273@goodmis.org> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9C27AC000E X-Stat-Signature: k5xew7pwn4aohyxbutyieqagc6uiopjs X-Rspam-User: X-HE-Tag: 1712701389-463894 X-HE-Meta: U2FsdGVkX1+p7Nxz39RoKRq0Hxpp6pK4KVaIVYAn1g7SfzeIB6ZN1b3i94a/1um9nYhayAZAd7oWynU6xBP87iWVc2E1rZNUzqnuPpEwrKNaHmmcqusGs3/GifwsBjz7/T6QdJTqkYyYKyvHSbN0gCaL7NATcPTMhJ6yGcwgX2xXCgYSOjD1K7frBVZ7tU2t1bW1C9fHNYWs/knnOnnEm+c2ZAae+b1AiCPiJZyLR6uUoaX8D3CJxQSY4gKjXzs8yK3sIClO/HTPNR115J1UC3wBEiBIlSE0w3sxGkSUBeL5H4Gj0oLsL3bh/zZZSe8sEIxeLpN/CkP97b0AW8OueGZK7qE9RW527qLeyuOXatzCI2pJFlV8rAHjIpSLCb08XKGTDrzY4DdT+spQxFjQ333BfXT9W9uac5fFVnM0XZ1IjIlXjcCqQFksIdhkgVXjAvC1pPfXM0Lw1eniayXQkBra8GY2rg942Plm1qyCDWeKaolTo+3PQkiA8AwJjd6sKonCnlSZs/rHKRjyFAdPVs1Fzz6i7PWtTUB86FWpsAz03b1a+WZGIYPxIHcc0RFtkotyxrPUZrKW2KOY6GXT36UU+PCwcpaC8F3IForj1uybWYCH/b+PCZZGAM4b4FUbIzD1wYL3kMdvpbNVrfIFc404BxFJPn37l4ab/dueZ8eBY1WISDJRviQih5/8iX32F8YcPcNADJVlrh12Z6Jvt6jUZk6mYyHcFy5+4tA+dIE3AqhqNPsmJlh5f0LhJBeAPOmspt/6Lnw5JU8UyRAqZk9zUwalcIanxTCN4r7T9pKKiSpAdPJnxr/rzwcmBugwxGWeg9Ioqi5u1XAzbmoVUiDEwKQQvo9i3PhxMRP3raqcf1t3PrsfxRoUnOFaN+++yE+oQaB4Xo1/s3w85uwEJFSQNbw7QiWRccxxumVqFbydfu1Xr1p+2HMycmnOQdzlCntkyBNJhJrGfBG4IFa 1f7JAQ7Q gYKT+S5fuQiglJpu52ReYWB+vFUb0hXdYWEMHfL9bRbgrvAj7H+ToonIUaJz3ClMXwQ64iinetwtMGkxDzmg5Uzh46cw+LJ5d/IBsNpDvlakKHKqrG43EVupTdGgSuoN5vCswpqBEo9eDASZ/B2QRVBwExw/fvJk+uINFJYeP6JmngTCCc/9nBjjxn7IefrywYPjzgKQ2NLY5nK7DTtVLj7RkrWhxmVNq6RgQ7wHR8+ItN0O1KSxPZAMFq1M0EH0VDXit0xT4uyCZe/2nu9D5jTfelB1iXoNQoOeElyoojD/5syexuxInz8PLe/PZtW3voy86ViWnu7LsImiqRvfm8bwGzMPZfGcneQ+o3L67DTZcPGh0dPiYffUmfmhLI/7q+mm4PaQdlPg4iGWiABL3tTi4reZh18IrCACU 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 Tue, Apr 09, 2024 at 05:02:55PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > In order to allow for requesting a memory region that can be used for > things like pstore on multiple machines where the memory is not the same, > add a new option to the memmap=nn$ kernel command line. > > The memmap=nn$addr will reserve nn amount of memory at the physical > address addr. To use this, one must know the physical memory layout and > know where usable memory exists in the physical layout. > > Add a '*' option that will assign memory by looking for a range that can > fit the given size and alignment. It will start at the high addresses, and > then work its way down. > > The format is: memmap=nn*align:name > > Where it will find nn amount of memory at the given alignment of align. > The name field is to allow another subsystem to retrieve where the memory > was found. For example: > > memmap=12M*4096:oops ramoops.mem_name=oops > > Where ramoops.mem_name will tell ramoops that memory was reserved for it > via the wildcard '*' option and it can find it by calling: > > if (memmap_named("oops", &start, &size)) { > // start holds the start address and size holds the size given > > Signed-off-by: Steven Rostedt (Google) > --- > arch/x86/kernel/e820.c | 91 ++++++++++++++++++++++++++++++++++++++++++ > include/linux/mm.h | 2 + > mm/memory.c | 7 ++++ > 3 files changed, 100 insertions(+) Do we need to involve e820 at all? I think it might be possible to just have pstore call request_mem_region() very early? Or does KASLR make that unstable? -- Kees Cook