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 87396C433FE for ; Fri, 6 May 2022 06:19:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23A076B0073; Fri, 6 May 2022 02:19:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EAC06B0074; Fri, 6 May 2022 02:19:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B3456B0075; Fri, 6 May 2022 02:19:40 -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 F19FE6B0073 for ; Fri, 6 May 2022 02:19:39 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BF04320AB5 for ; Fri, 6 May 2022 06:19:39 +0000 (UTC) X-FDA: 79434316878.02.BA2F4EB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id AF9C940027 for ; Fri, 6 May 2022 06:19:21 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 434D061F2F for ; Fri, 6 May 2022 06:19:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2380C385B1 for ; Fri, 6 May 2022 06:19:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651817977; bh=IUl60lZB9k2Omx05KnvR9/Pnx4r4J6gGGycPuLGxQhs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Wn4TowktAoGU6/7hE0aJOA6AA+2coq7oanmB6OhX7edUBX8ZM1u/eVdxOjnfyzb05 oNHQtOn3vlgDQJ5b8jOkrKp7rTxPx8pzzWhOo9UjoClUUza9rDvpu1+KLbcttKPbXN K+Tm6Byp2i+zEVoAL2yDq60AUekvb9o6cCXSRtNhiV9kVWMJi5aMdu7+N3erAzEVmT qsRh5jUjWNsz44MV60iJ/qNxl6FKKz85fF1uKYqHTFE2s5SUmggTITni7LO2eucND+ 5Wa7GpGzSzK6fUvX8UM1SQ2chViQMTMOLNB20U6Z6PPIpg3ImWn+gEYpGDL8FlK0Yv nurSv6ESZuzEg== Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-ee1e7362caso2226021fac.10 for ; Thu, 05 May 2022 23:19:37 -0700 (PDT) X-Gm-Message-State: AOAM531xAyf2n7xDlVt/Sj9aDphYOX3GKKovB8b0tXB1UIlE9BxYHUyW lv6lS1EOFe+ZjwwpbeLmyuonAaRNqx9cPxL7GWc= X-Google-Smtp-Source: ABdhPJydfyazSt7F/4W0H97tAcaXutERRfuxdMEi3I4BCOviCwX7pCQexWP/deuaaJkfCStxlkMTky2/H4Myo/Aqm5w= X-Received: by 2002:a05:6870:eaa5:b0:da:b3f:2b45 with SMTP id s37-20020a056870eaa500b000da0b3f2b45mr3890092oap.228.1651817976736; Thu, 05 May 2022 23:19:36 -0700 (PDT) MIME-Version: 1.0 References: <20220503152131.263711-1-ardb@kernel.org> <9472d1d5-7f03-eaaf-2846-a4340163d5c0@huawei.com> <0e6b7f51-7560-3d5f-e2ee-c479e735beb1@huawei.com> In-Reply-To: <0e6b7f51-7560-3d5f-e2ee-c479e735beb1@huawei.com> From: Ard Biesheuvel Date: Fri, 6 May 2022 08:19:25 +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" X-Stat-Signature: hmsy59ps5ytuuk3ibcwcahbc8gdwtoit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: AF9C940027 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Wn4Towkt; spf=pass (imf12.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 X-Rspam-User: X-HE-Tag: 1651817961-505541 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 Fri, 6 May 2022 at 03:43, Kefeng Wang wrote: > > > On 2022/5/6 0:12, Ard Biesheuvel wrote: > > 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? > Please ignore this, replied in the previous email. > > > >> 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. > > I see, slots = get_entry_num_slots(md, *size*, ilog2(align)); > > Thanks. > > Reviewed-by: Kefeng Wang > Thank you. I have queued this up now.