From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id 2F1C2D8030C for ; Fri, 10 Jan 2025 17:33:43 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=mCg/5D6BimYM5MGxzaMhPKuTFV5m28yWtP8sXFrQ9lo=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20240830; t=1736530423; v=1; x=1736789622; b=mG/Ei+Ff7VB4JoJsEL62KJBj2m8tmyUCabcm+DxF2+K+c8SeQHwgqePDCb8jxRkzheqD/Bl2 fYUhgZL2dtkouELxxb2d63rhlpJ03liIJQIuslNw5pL/rV32EPK9qthUmPdNjHCpj9377yb7B8Z oJXdwUQWJx+eQKvQdhI9TBohQsiTqDt+zHZwVijNVBoXG+9kXE+9FAa1I4Ht7nTBgBODksFIEYi Kj44upkILQTu9OB00GzbqTOz73PfCSwJ2iTwn5sikE3Vmcs8zTQp76Bym4bror3CHTJJoHZyZnC 3IXodIk9sM52kD8JfaxxWco1dNaihB9mFxtxTmvKtmMug== X-Received: by 127.0.0.2 with SMTP id 8mGQYY7687511xVPohZu8dil; Fri, 10 Jan 2025 09:33:42 -0800 X-Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by mx.groups.io with SMTP id smtpd.web10.25194.1736530421726404099 for ; Fri, 10 Jan 2025 09:33:41 -0800 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 7A3BDA42767 for ; Fri, 10 Jan 2025 17:31:52 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95999C4CEE1 for ; Fri, 10 Jan 2025 17:33:40 +0000 (UTC) X-Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-53e3778bffdso2412163e87.0 for ; Fri, 10 Jan 2025 09:33:40 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWwLMrDLw8Z3TMDO44uvipTS0d1HvwODLjOsx1WiIk5BmFm6WWcOpoAdnQywcg5j/ZqoJcIgQ==@edk2.groups.io X-Gm-Message-State: yaMcXfB7Y3tuFCdjQqTLh8Q8x7686176AA= X-Google-Smtp-Source: AGHT+IEuxGh8/T/s4PRuzCDPZjJ30Nh6MVT+V5a4g3NgK4duCm/rvIxWbI/taLS4BGyAZZsJuYhCJRUHs5tmVT5suFI= X-Received: by 2002:a05:6512:3f12:b0:542:6366:762a with SMTP id 2adb3069b0e04-54284545e1bmr3182431e87.25.1736530418923; Fri, 10 Jan 2025 09:33:38 -0800 (PST) MIME-Version: 1.0 References: <20250108215957.3437660-1-usamaarif642@gmail.com> <20250108215957.3437660-3-usamaarif642@gmail.com> <20250110-tricky-grasshopper-of-maturity-21771f@leitao> In-Reply-To: <20250110-tricky-grasshopper-of-maturity-21771f@leitao> From: "Ard Biesheuvel via groups.io" Date: Fri, 10 Jan 2025 18:33:27 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AbW1kvZLYSGGczVN_3S8j4nI__QcdSl-X1qZVWuLdX8pTn1lTfcnMroSAbHPcAM Message-ID: Subject: Re: [edk2-devel] [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved region in 820_table_firmware To: Breno Leitao Cc: Usama Arif , linux-efi@vger.kernel.org, devel@edk2.groups.io, kexec@lists.infradead.org, hannes@cmpxchg.org, dyoung@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, gourry@gourry.net, kernel-team@meta.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Fri, 10 Jan 2025 09:33:42 -0800 Resent-From: ardb@kernel.org Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b="mG/Ei+Ff"; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=pass (policy=none) header.from=groups.io On Fri, 10 Jan 2025 at 12:36, Breno Leitao wrote: > > Hello Ard, > > On Fri, Jan 10, 2025 at 08:32:08AM +0100, Ard Biesheuvel wrote: > > On Thu, 9 Jan 2025 at 17:32, Usama Arif wrote: > > > > I think in the end whoevers' responsibility it is, the easiest path forward > > > seems to be in kernel? (and not firmware or libstub) > > > > > > > Agreed. But as I pointed out in the other thread, the memory > > attributes table only augments the memory map with permission > > information, and can be disregarded, and given how badly we mangle the > > memory map on x86, maybe this is the right choice here. > > If this augmented memory is not preserved accross kexec, then the next > kexec'ed kernel will be able to find the original table? > > I understand that the memattr region(s) need to be always (in each kexec > instances) `memblocked_reserved` to protect it from being used as a > System RAM, right? > > Thus, if it is not passed throught e820, kexec'ed kernel needs to fetch > it again from original EFI table at kexec/boot time. > Not sure what 'fetching' means here. > This brings me another question. > > If the kexec'ed kernel sees the original memory, why can't it > augment/update the RX permissions *again*, instead of passing the > previous augmented version from previous kernel in this crazy dance. > I don't understand what original memory means. I think we're talking past each other tbh. > > This is a kexec problem (on x86 only) so let's fix it there. > > Would you mind explaining what kexec needs to be done differently? > Should it preserve the augmented memattr table independently if it is > mapped in e820? > I don't know what 'mapped in e820' means. Let's forget about what the memory attributes table actually contains, and just assume we can live without it, ok? So when booting x86 via kexec (which is already detected in arch/x86/platform/efi/efi.c), the kernel should pretend that the table does not exist. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120981): https://edk2.groups.io/g/devel/message/120981 Mute This Topic: https://groups.io/mt/110518541/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-