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 233D6C77B75 for ; Tue, 16 May 2023 18:02:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92561900003; Tue, 16 May 2023 14:02:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D55F900002; Tue, 16 May 2023 14:02:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C509900003; Tue, 16 May 2023 14:02:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6D2CE900002 for ; Tue, 16 May 2023 14:02:57 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 90AD61C68A2 for ; Tue, 16 May 2023 18:02:52 +0000 (UTC) X-FDA: 80796888984.04.96E55FE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf19.hostedemail.com (Postfix) with ESMTP id C25B61A00D5 for ; Tue, 16 May 2023 18:01:53 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eDvLDKyr; spf=pass (imf19.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@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=1684260113; 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:dkim-signature; bh=/p6R+68FwabHdgtBStGenvDElp3UiSkTl9PQWfq1E0k=; b=EwE09/ti16Etm4gL/IjENU9MMnfGqPL42W0bOqx4MbdWWiaSdw9mWDaqt4VrLdnm2h8t/C /GtDjFMkW8CL+0j5fCi2G623NKRtB01YJyASit+MTvXTD5y/rAiCoxGNkNVhUa1SVcG6iZ ruVJ4XhXfVIJobaDR0lISeKNXZ03/cE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684260113; a=rsa-sha256; cv=none; b=2OkdpuOyCrLpqU50yKegdaaAuu0eAqp4P/zjWfvxxd8MySYN4fVSkwnj4kn1JaGYTasUB/ 3ahA6Md+OzHAlWH0e9DcmRm61d622+lxSovrtjcT9vZT+V9Rk+1LAF65nG3A1o6cfrF4nE 3V3po8h9AUq/Acyq1h2cfJg/Y0LHQv8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eDvLDKyr; spf=pass (imf19.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7797663CAF for ; Tue, 16 May 2023 18:01:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7FECC433A0 for ; Tue, 16 May 2023 18:01:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684260111; bh=fTMeSN7AzVHCiTkT+f9pmwZrYPpPz9puMnicx/1cTkI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eDvLDKyrpJTLq/AALKUpmbrklR8bj8I/zx7XK99zgM0BSBNI+HEookKyX5JsNdzcO Uxwy+I418kW7zGRZkGww0YBVNNhdlA2XCnP7t+4ktsb+sG0L+NBbsfMHxxaqqZOA6v XnWLbM5KSrnw+3jCqE0TshJE9Xqz90Nrz2K8hbmGTizL0OUNb2FWiJVCM/b67EUKU2 XItyCeFPe3jGzKhlFONy0F9mr47sq4+KjMniLZ3PPOXZ5To8ZxDmr+vSb9wXUuHst/ k6YtTOK+YyNskaWswIXgKSlHDQ2aJlRz4tNFvChAZTplvWceDDPNLqRIDe++5o9+a5 /XocuBLndc/uQ== Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4f38bea8be8so4933092e87.0 for ; Tue, 16 May 2023 11:01:51 -0700 (PDT) X-Gm-Message-State: AC+VfDw8INFfsGaPIz6b756DrnaU55qdcip0GHreaML8XDLjY7fRGkHi 5pfkEU3Iv6SDn1E91eIC9J3J9Pg23GUy5VnjMDE= X-Google-Smtp-Source: ACHHUZ5mkGKvbS8jLvIh+c+5mkY/if/pIGe5q1s0NkvzsdFe2AoncbM41M63JlAbaP+eAQpipVwoyg4qvgPfbmTVI+I= X-Received: by 2002:a05:651c:1728:b0:2a9:f9e0:a820 with SMTP id be40-20020a05651c172800b002a9f9e0a820mr7846949ljb.11.1684260109821; Tue, 16 May 2023 11:01:49 -0700 (PDT) MIME-Version: 1.0 References: <20230513220418.19357-1-kirill.shutemov@linux.intel.com> <20230513220418.19357-4-kirill.shutemov@linux.intel.com> <9549d984-e581-048d-95a3-7c54acd70fb8@redhat.com> <20230514211324.fymzoa263wx2hs2p@box.shutemov.name> In-Reply-To: <20230514211324.fymzoa263wx2hs2p@box.shutemov.name> From: Ard Biesheuvel Date: Tue, 16 May 2023 20:01:38 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv11 3/9] efi/libstub: Implement support for unaccepted memory To: "Kirill A. Shutemov" Cc: =?UTF-8?Q?Mika_Penttil=C3=A4?= , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Dave Hansen , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Mike Rapoport , David Hildenbrand , Mel Gorman , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, aarcange@redhat.com, peterx@redhat.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C25B61A00D5 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: oo34siwogiym7ybjwn7hqw4doxwgnmoj X-HE-Tag: 1684260113-328731 X-HE-Meta: U2FsdGVkX1+KvGb6DhwRVTU45c6fKyDiFzJyBmg38vZeG9qzxyDU75QWIp74B6RJ2Qr74FTKb2xDCmxe5p3osL/1HNHHeahzj77/qMlhLIxMjVocDXZ4aAl0u4iW5BOspLOtyrueJkEg4L8VKfXHq3RXQBvIwmUReYD2G6M6OqN+TBPoiDecFoMy0PMG/YWFywk7sgHJtzKxxvgeNSs856OoMrl0/EMsWfWOz9KVh2dRkfZAPn3rB+saJelNu7X0eJu4ioClYgvhyo1txWBYI4HTxtrUnLPF0rBXavMuIRkBPv7wbUFpZYQuC2ux/en2XXXg7Vz4gZ8llBdHp25uIkhR/lDvhKMmSu2T2nQHuVbunh6AV03dRANsvjFUhE69Tbd5CZpgPMvxybLU46aKwoNqMchf+K/T8QfxskPTUFy277QdAztBHr0FLMeimK9AOibSitOYJl//ccKlt+9ArxK7AlgPRpg0clu5PPtUrYBQOX3P9WxE6cXsA1EoJHlI61gACq2UwLseJqE9UELkrkC+21kqL+Y5rJ9W1O3nGHGsqVCh4H20g7lHy0enOOLQ10dv9q4aO7CnkgNklXGJxaNG2hkVOAmAjOsI3Ndy5wYG5anWcoeMptfZvOL6wt40Bl+P7szM6yBerY4BR/sl7rmP6GU6/D03Csx3YKjWFcBeZ+G5qsTl++GZHaIRuAPSfFhLFMpLZ0n7Go1i9KIUGGSSS0bAe3zVLqPOkaIwFGzv2H0VRBNZSW/lKF4cMU76CNWgXG4Cc2zyB9AaAKmEwnidHei4MTaAqvuD1K8K7soZ23SuOUdHagTouiHoGFemqznDZxY0lHUkDH67gvc98OfOXPOXMfx9SysbYJEd/1dgBIg1vAa0Y/cXqOazd2VYmPMBhbBI3bzgmRoLUwp9H7EyMyiMpuFbH1M6uIJv3OyllOHP4OQAzW/QGlr/G8fqZbgqcMCjPdXa6sm1LS1 1RfQ+ShB mXcJxzDDCg+Yr0ydVofRnNUha/BuspXxolM8InAfhv/pa9biiVEOduOBh3CO4RECpVhRyBasSCJY11PU/KURZorkzDGceNXUo2wFUW1eRaXLGNzqCVsqx/18GsVSs5CIsN8JXrMOj8D27BugCNM4CBVm3yf6yx4G5NM+wDabfQ76OWBvN+U5iAFQ0nY2xQ6XgAczG8OAkD0p10X6OSKt4zmPV5AgrGnoUP24r6TYlL9Y3TsCWPs7QIpg6q9ZlAq+ILc8lRIxVwj2LTazUpLe5CXnd8NrPQQA7JLOgBsCjHan/6xHl94aUnj5pX1b4U1YoDsCD 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: On Sun, 14 May 2023 at 23:13, Kirill A. Shutemov wro= te: > > On Sun, May 14, 2023 at 08:08:07AM +0300, Mika Penttil=C3=A4 wrote: > > > + status =3D efi_bs_call(allocate_pool, EFI_LOADER_DATA, > > > + sizeof(*unaccepted_table) + bitmap_size, > > > + (void **)&unaccepted_table); > > > > > > Wonder if EFI_LOADER_DATA guarantees bitmap not to be freed, or should = some > > more persistent type be used. If EFI_LOADER_DATA is enough, maybe a com= ment > > why it is safe could be added. > > Ughh.. I've lost the hunk that reserves the memory explicitly while > folding in the patch we discussed with Ard. See below. > > But the question is solid. > > Ard, do we want to allocate the memory as EFI_RUNTIME_SERVICES_DATA (or > something else?) that got reserved automatically without additional steps= ? > EFI loader data should be fine here, as long as we reserve it. EFI runtime services data is intended for allocations that have significance to the firmware itself, so it gets mapped into the EFI runtime page tables and on some architectures, it gets removed from the direct map as well. The unaccepted bitmap is only accessed by the OS itself, so runtime services data is really not the right choice. We just have to ensure the bitmap gets reserved in memblock sufficiently early. > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index e15a2005ed93..d817e7afd266 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -765,6 +765,25 @@ int __init efi_config_parse_tables(const efi_config_= table_t *config_tables, > } > } > > + if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY) && > + efi.unaccepted !=3D EFI_INVALID_TABLE_ADDR) { > + struct efi_unaccepted_memory *unaccepted; > + > + unaccepted =3D early_memremap(efi.unaccepted, sizeof(*una= ccepted)); > + if (unaccepted) { > + unsigned long size; > + > + if (unaccepted->version =3D=3D 1) { > + size =3D sizeof(*unaccepted) + unaccepted= ->size; > + memblock_reserve(efi.unaccepted, size); > + } else { > + efi.unaccepted =3D EFI_INVALID_TABLE_ADDR= ; > + } > + > + early_memunmap(unaccepted, sizeof(*unaccepted)); > + } > + } > + > return 0; > } > > -- > Kiryl Shutsemau / Kirill A. Shutemov