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 7BB0EC433F5 for ; Thu, 5 May 2022 16:12:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A30066B0071; Thu, 5 May 2022 12:12:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DF266B0073; Thu, 5 May 2022 12:12:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 881A46B0074; Thu, 5 May 2022 12:12:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 78B816B0071 for ; Thu, 5 May 2022 12:12:17 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 48302121E27 for ; Thu, 5 May 2022 16:12:17 +0000 (UTC) X-FDA: 79432181514.13.576D41F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf28.hostedemail.com (Postfix) with ESMTP id D8F7FC008B for ; Thu, 5 May 2022 16:12:01 +0000 (UTC) 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 ams.source.kernel.org (Postfix) with ESMTPS id EBE1FB82C77 for ; Thu, 5 May 2022 16:12:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1001C385A4 for ; Thu, 5 May 2022 16:12:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651767133; bh=ipdW/XK4EChOh7CNBfnV5DfI8o2DDjutNch/JdNzlgM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CV7GqME4fDg3wwymQJWMV28qap2cOfLHFgr7gUDW1On0x/tAYmCvvtpeSjqtyKKhn OA3YNDmegDz47F7w3Bb7pTlx0itz7L8HZzdMWC2wFk7vnihyWGE+sQZEkeMBuWs3iD IlvEqAp51aOnI0IC3F/8AbYoVn1NG1wkTfyiEefixGLNSughoqETMFh3xBpEGN/u5E xPSKnMHG0B150gY1RHunS/g2NE4aZ4y6dDTM/TwW4Tsqm8UGrGaQAQvpSum+AmCzDr wwxl/00n622KHycdHHE/FJZJ/14UtBxG6/7Cc+QcdHDNfRnZjaKlCF3wq9pjMxlYH0 jN7neIC0H/F+g== Received: by mail-oi1-f172.google.com with SMTP id v66so4823689oib.3 for ; Thu, 05 May 2022 09:12:13 -0700 (PDT) X-Gm-Message-State: AOAM533m5xRiSx0L+fvOtJT5YodEqKgq6fyHk9m12gNy0FX9FmCrsxPb YPPtgtbk6QRvuZ7pcoPj94ajjzq/NMrYqG5S8J8= X-Google-Smtp-Source: ABdhPJxKZwloLkKq0RUD/Xi1dUNvDYLjRTku73thHqgWWBdFLvsVWi3P3+Hf1krvwR2iTMa1wG4DMWTtsgyuuBsw5oI= X-Received: by 2002:a05:6808:e8d:b0:322:bac0:2943 with SMTP id k13-20020a0568080e8d00b00322bac02943mr2921525oil.126.1651767132906; Thu, 05 May 2022 09:12:12 -0700 (PDT) MIME-Version: 1.0 References: <20220503152131.263711-1-ardb@kernel.org> <9472d1d5-7f03-eaaf-2846-a4340163d5c0@huawei.com> In-Reply-To: <9472d1d5-7f03-eaaf-2846-a4340163d5c0@huawei.com> From: Ard Biesheuvel Date: Thu, 5 May 2022 18:12:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] efi: stub: prefer mirrored memory for randomized allocations To: Kefeng Wang Cc: linux-efi , Linux ARM , Wupeng Ma , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CV7GqME4; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D8F7FC008B X-Rspam-User: X-Stat-Signature: hncyht55c3sq91wjnko41k9ekjdwyt7a X-HE-Tag: 1651767121-792538 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 Thu, 5 May 2022 at 15:43, Kefeng Wang wrote: > > > On 2022/5/3 23:21, Ard Biesheuvel wrote: > > If the system exposes memory regions with the EFI_MORE_RELIABLE > > attribute, it is implied that it is intended to be used for allocations > > that are relatively important, such as the kernel's static image. > > > > Since efi_random_alloc() is mostly (only) used for allocating space for > > the kernel image, let's update it to take this into account, and > > disregard all memory without the EFI_MORE_RELIABLE attribute if there is > > sufficient memory available that does have this attribute. > > > > Note that this change only affects booting with randomization enabled. > > In other cases, the EFI stub runs the kernel image in place unless its > > placement is unsuitable for some reason (i.e., misaligned, or its BSS > > overlaps with another allocation), and it is left to the bootloader to > > ensure that the kernel was loaded into EFI_MORE_RELIABLE memory if this > > is desired. > > > > Signed-off-by: Ard Biesheuvel > > --- > > drivers/firmware/efi/libstub/randomalloc.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/firmware/efi/libstub/randomalloc.c b/drivers/firmware/efi/libstub/randomalloc.c > > index 724155b9e10d..07a762910312 100644 > > --- a/drivers/firmware/efi/libstub/randomalloc.c > > +++ b/drivers/firmware/efi/libstub/randomalloc.c > > @@ -56,6 +56,7 @@ efi_status_t efi_random_alloc(unsigned long size, > > unsigned long random_seed) > > { > > unsigned long map_size, desc_size, total_slots = 0, target_slot; > > + unsigned long total_mirrored_slots = 0; > > unsigned long buff_size; > > efi_status_t status; > > efi_memory_desc_t *memory_map; > > @@ -86,8 +87,14 @@ efi_status_t efi_random_alloc(unsigned long size, > > slots = get_entry_num_slots(md, size, ilog2(align)); > > MD_NUM_SLOTS(md) = slots; > > total_slots += slots; > > + if (md->attribute & EFI_MEMORY_MORE_RELIABLE) > > + total_mirrored_slots += slots; > > } > > > > + /* only consider mirrored slots for randomization if any exist */ > > + if (total_mirrored_slots > 0) > > + total_slots = total_mirrored_slots; > > + > > The kernel will check 4G lower limit to enable kernelcore=mirror feature. > Why? I mean, why is 4G a magic number also on arm64? > Do we need some fallback mechanism in case of small mirror slots which > > leads to fail allocation for Image? > This code only counts slots that are large enough to hold the Image so this can never happen. If total_mirrored_slots > 0, there is at least one possible placement of the kernel where it falls entirely inside a EFI_MORE_RELIABLE region. > > > /* find a random number between 0 and total_slots */ > > target_slot = (total_slots * (u64)(random_seed & U32_MAX)) >> 32; > > > > @@ -107,6 +114,10 @@ efi_status_t efi_random_alloc(unsigned long size, > > efi_physical_addr_t target; > > unsigned long pages; > > > > + if (total_mirrored_slots > 0 && > > + !(md->attribute & EFI_MEMORY_MORE_RELIABLE)) > > + continue; > > + > > if (target_slot >= MD_NUM_SLOTS(md)) { > > target_slot -= MD_NUM_SLOTS(md); > > continue;