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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 927ADC433F5 for ; Fri, 6 May 2022 06:19:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232493AbiEFGXb (ORCPT ); Fri, 6 May 2022 02:23:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1389388AbiEFGXW (ORCPT ); Fri, 6 May 2022 02:23:22 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 998F55C669 for ; Thu, 5 May 2022 23:19:38 -0700 (PDT) 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 34AFF61F1C for ; Fri, 6 May 2022 06:19:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98325C385AC 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-f50.google.com with SMTP id 586e51a60fabf-d6e29fb3d7so6322477fac.7 for ; Thu, 05 May 2022 23:19:37 -0700 (PDT) X-Gm-Message-State: AOAM53050c8YMHcYVDgRbaQqV/sfuPz0BiUD4jy1WketiWDZ6PaZYIpE aY85FR3j4n3xiyx1igv5M6/TPL7c7yYyKhah1eg= 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" Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org 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. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1D75FC433EF for ; Fri, 6 May 2022 06:20:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TfjzHBEWUVMpP70dndXRnXW4Wh1vF8j+hYvYk4zj93Y=; b=2jXWoBKdsbn5h/ aqnboKLR4/KAoJUIm6ES08e9ipqV074EJAPPjkblfJ8xfer2CKakVjvP4Br/uS5i4S3Q06CyKAixC /al3oev+PTBU98Pj7taTTziJumRigFwTPj0ef2RgA1mWjNZTXdYC3SgXrADjVxfGjbkSqH2dRJ9Nf NMSZZ+gtKkMGWagVCvUVbYAnaf019ilHu8cY8YGuJ/dTcErZpN3Dx+Gyqne1S6wFBhLQaFnp2GEtL w7zJIvdvHNukjwWSd0R7ltXVwC71j+rpeIW7VLS254wEkdMUFhthRksm9MagsUtAaCCuRnJXobiKa KUPMXxGAWP0HRSCqLAjw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmrJb-001YwB-3e; Fri, 06 May 2022 06:19:47 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmrJX-001Yum-7b for linux-arm-kernel@lists.infradead.org; Fri, 06 May 2022 06:19:45 +0000 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 sin.source.kernel.org (Postfix) with ESMTPS id 49BFCCE331D for ; Fri, 6 May 2022 06:19:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9053CC385A8 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-f42.google.com with SMTP id 586e51a60fabf-edf9ddb312so5394581fac.8 for ; Thu, 05 May 2022 23:19:37 -0700 (PDT) X-Gm-Message-State: AOAM530nu1LG8PxvBW1/bsCQGejbqX4mR+74REIRUr9Oc0dcn2cUCxmN TlIW9/ahNYaSajjrRBM+mSTVjIscR7CpThfSf2Y= 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220505_231943_668841_448B4672 X-CRM114-Status: GOOD ( 30.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel