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 09A24C10F16 for ; Mon, 6 May 2024 10:38:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BA306B0083; Mon, 6 May 2024 06:38:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76A066B0085; Mon, 6 May 2024 06:38:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60ACF6B0087; Mon, 6 May 2024 06:38:51 -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 3B3C16B0083 for ; Mon, 6 May 2024 06:38:51 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B6C0A8029B for ; Mon, 6 May 2024 10:38:50 +0000 (UTC) X-FDA: 82087622820.14.BBD9147 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id C64B44000D for ; Mon, 6 May 2024 10:38:47 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=p5chX6W+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714991928; 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=+sMre+0s8XuSqhviOvxYhM1E9EHHXARPAYeKH8OPY78=; b=n/C+Zx0PGi9sbamxTRitYilaj1jcb8DeHGSsvCXTWpkqvU8TtYRPOA/2CDlDQArc6ibGLV u/pKxGkUMM7Q6Z58xIUMdsF1P3P+1WiCurq5W+j/hvKZPt4T9Pju9wibk7/T1eb9nny1Ft 2pY4o88AeNt46oCrgA48mUe6x6oessA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=p5chX6W+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714991928; a=rsa-sha256; cv=none; b=LSpix7zzd3BuFACs9SJP3ZDPl7ytaqEH0RDqsVBzYr2MK/Erl2OdtxSU7GZ5F6LQui2PpE 3K23FnbfD1jdZAy2t8elhAQ+IBUPhMZpJD4or1gJaouBJgdBMPungM0wBVgS4sGojNvs4K uxfwKyJRzFloi35D6wGCpfxRZTOesdw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9B84161193 for ; Mon, 6 May 2024 10:38:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5A9EC4DDE9 for ; Mon, 6 May 2024 10:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714991925; bh=+sMre+0s8XuSqhviOvxYhM1E9EHHXARPAYeKH8OPY78=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=p5chX6W+7I2fDJkE1QqM9wRxsSH/i/mgVUsH3W5V8yEUMBAthAeB0+rRqPoEY3JCr vpo80Tf8X8DlxxksbetRo+ksekpb00QRchH8UT8aa9L99POHSKNMbkzkx9BJXribmZ 6qAU9u5zE9mhdIwL+BVu7hWwGzUQs8Xxl6rr41WErC51eyPSjn2Gvi3TZDdimZwxYP a7SrGaLFiuBJvmFMPQ8saRtckD+3jNPkdU1QasHUnXKomBZVFzTAKnOMa+59hjkVC3 5AV9Mvyxy64NPjOzCu9cqaoc+ivkUdY4feLk15FDsZrT5aBJ9+QDooMekmIkYSNLzZ ozqdCoso0VJ9A== Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-52006fbae67so2316606e87.0 for ; Mon, 06 May 2024 03:38:45 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVfnSaw/LYPsqXDfzYqYCg92SBwsQrLR2y3rTyyhtTsW1Vdvrz0bv7zXe60O1+jDRaQlVWkJYIKWy1MIbBpNT00Scs= X-Gm-Message-State: AOJu0YwqCO6J9hY1jlkAJkyECvvg1uMtbb+GYOZ0UbrpyLZlVFXudfEd bxmKQ98ihOBGkgBmNBfhPhvlHEcA/3rLZii08q6wV2lvsVzj3pUrv0K/pyi6vQOx1tx8OOd2a9n fsQUD6NGbq3tgwbZJ4IXQW7eBgkQ= X-Google-Smtp-Source: AGHT+IGrmdoDC9OU2KevduoZC6ArmZA6QOhPgQmvYxG1IrrYVOP27uC3VgBT/7g9DgqcivO0pnNgMPGrMBtlEAKwxG0= X-Received: by 2002:a05:6512:33c5:b0:51e:1bed:13a8 with SMTP id d5-20020a05651233c500b0051e1bed13a8mr6619509lfg.29.1714991924016; Mon, 06 May 2024 03:38:44 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Ard Biesheuvel Date: Mon, 6 May 2024 12:38:32 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [POC][RFC][PATCH 1/2] mm/x86: Add wildcard * option as memmap=nn*align:name To: Mike Rapoport Cc: Kees Cook , 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 , "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 Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 8eqzzedwx6f9ioqf5j4459kdu4rwqyc1 X-Rspamd-Queue-Id: C64B44000D X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1714991927-563466 X-HE-Meta: U2FsdGVkX1905J31sj609SmhNKaEKd2QcpU4dqS7uAvukfz29LylQQxXQoAjp/etIDlhZ4VS6J6abvFaxHbz9T2I+6KVL8nDcgdtadY7TQjvz+uTqMiqYaOvZrAxtnpfySBCcV+3DmJRXMTYfkFbi6N4l/1Sxxdn4LrsCO5OPBMNPFnH1B1DlzR7dvjGBcP6Nwf9K1HPOVpj7GxWfL7hHJ8HquvvoNIGqIfneR/rsNEOke+nnNShgS4Y4n/Rot4JlYU4NwyPRVQFXKYxqaIf6P5uRsP2OMcrlJEmbN4geBzeZ0ijSLg0Tg4CgRVah20cOb92K7EHfWEL20TXAdX0nNfrnFDqLjholXKJ8CqxbU+WfCH1bh59J6zBxyK+6qctLxnhy7Mu8v+qt5UWwMDCtvgCptH3QkSxBEpT0f5UB3I5tCnVlpJ2vAfgixU2KLf5MqwJgEDHPdYrUabPCRHG8MJtsuTpk4rEJU6BiRrF56UpQ4A29P9OShHFcXw/RfdjjXAFmGolKCCh5bdVaKlmyrg7UuerQnl6QbIJ/nv06SdMCCJAD7gRiSxNr+uRbWVddcUJWlkEjUMu2TJrJT7eECP+oL0xoVzhpTUM2I1OxD8oOi5r0n1n00egL7Ou/EtsOddy1WzoklEZt8eglqWBKkH1a2kQaJJrt/1EruirHU7VbQtEB3ae7jXgQccfDVfFa3nk0MvCQOsokfz1EkGhhHqTj31U39ub3+elONvTzKTasPa7Fp/ywD8A1XcMY+ncGeBflQtIqtFK0dyutcwzZFsYhZReM/VW0fqeS4pIOYq1UJCOo3Q214TMBlX1/VbtR3rh8n/mCnLQklg9jVaDYZy21jeCKEKk1a9s2Evky34t3kOHizNQiJF4guwuLLrYYKmoG4Kq+yYUOTTVO9B+UgrTboQs1MuynyVR6ETLicdigFrrcogZGozFLLuZTzUltxtNu+jn/6342UBx0vt hlS7gNsi ctqUIWqjT0LnynjDNxmJBynWZYZFXPxvEdsrF4slVjptnKIzkJ4iG/lxV2iS2miK5sz3zmAFQTXCY4ljhFDALmsRku+8PeZw1+XfLhYCUDQAa2hBzdmQlk7NqCO4mDQGeL5nREPCAn7+rhPuiH+cpji5rd+vnokAYv1zwRwsTPXddi3Bc7SYmTUGgOEyblxG8+5k+jTn9YbSIz857VICCgt8j4taqMMyWQLZ/X4AbJxFxatbB+jxqlS+bK7VatruigViYQakr2QUJyjY+KGUdS99HbaNyO5thyN0Npvofhjax3lU1oyKVkUq2nYnMm2gdNJMptdvaosHKMq8dW53+rSmAGQ== 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 Wed, 1 May 2024 at 16:59, Mike Rapoport wrote: > > On Mon, Apr 15, 2024 at 10:22:53AM -0700, Kees Cook wrote: > > On Fri, Apr 12, 2024 at 06:19:40PM -0400, Steven Rostedt wrote: > > > On Fri, 12 Apr 2024 23:59:07 +0300 > > > Mike Rapoport wrote: > > > > > > > On Tue, Apr 09, 2024 at 04:41:24PM -0700, Kees Cook wrote: > > > > > On Tue, Apr 09, 2024 at 07:11:56PM -0400, Steven Rostedt wrote: > > > > > > On Tue, 9 Apr 2024 15:23:07 -0700 > > > > > > Kees Cook wrote: > > > > > > > > > > > > > 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? > > > > > > > > > > > > Yeah, would that give the same physical memory each boot, and can we > > > > > > guarantee that KASLR will not map the kernel over the previous location? > > > > > > > > > > Hm, no, for physical memory it needs to get excluded very early, which > > > > > means e820. > > > > > > > > Whatever memory is reserved in arch/x86/kernel/e820.c, that happens after > > > > kaslr, so to begin with, a new memmap parameter should be also added to > > > > parse_memmap in arch/x86/boot/compressed/kaslr.c to ensure the same > > > > physical address will be available after KASLR. > > > > > > But doesn't KASLR only affect virtual memory not physical memory? > > > > KASLR for x86 (and other archs, like arm64) do both physical and virtual > > base randomization. > > > > > This just makes sure the physical memory it finds will not be used by the > > > system. Then ramoops does the mapping via vmap() I believe, to get a > > > virtual address to access the physical address. > > > > I was assuming, since you were in the e820 code, that it was > > manipulating that before KASLR chose a location. But if not, yeah, Mike > > is right -- you need to make sure this is getting done before > > decompress_kernel(). > > Right now kaslr can handle up to 4 memmap regions and parse_memmap() in > arch/x86/boot/compressed/kaslr.c should be updated for a new memmap type. > > But I think it's better to add a new kernel parameter as I suggested in > another email and teach mem_avoid_memmap() in kaslr.c to deal with it, as > well as with crashkernel=size@offset, btw. > 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, 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) So I would strongly urge to address this properly, and work with firmware folks to define some kind of protocol for this.