From nobody Sat Nov 2 12:24:14 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zoho.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1489664139545181.20867090557; Thu, 16 Mar 2017 04:35:39 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 0849480401; Thu, 16 Mar 2017 04:35:38 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 613C7802BD for ; Thu, 16 Mar 2017 04:35:36 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id u108so29820698wrb.3 for ; Thu, 16 Mar 2017 04:35:36 -0700 (PDT) Received: from localhost.localdomain ([105.144.205.163]) by smtp.gmail.com with ESMTPSA id w97sm5852467wrc.20.2017.03.16.04.35.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Mar 2017 04:35:33 -0700 (PDT) X-Original-To: edk2-devel@lists.01.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=iPWjgPiLNr/F4o8PHrFiuHyWeXn/EHROCDdi2It3pRU=; b=cEvkDF2HjIkthywNP1o/HTXdII5S+5cpIbaqL/5UtMQKa+3oD7kAnihn7Tl3GFYl+Z Bo0X9hGqrgpCWebz4ouuBDeI/96dzXv2RJgT7q3qtDsMw0KV0e90xn2UdiLXVsAVcwU7 JJLPfSD5nnFoyPTEzXDJbhPqGMrUh+/VyVtFc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=iPWjgPiLNr/F4o8PHrFiuHyWeXn/EHROCDdi2It3pRU=; b=mxGoQ30XJ1XLlmI/krxKpHr4IH/vcoh5+jRQRNSBJFSt0MX0iQVD4j3uq/GmmBmVl7 XrxCztSwhfTbEaKlYVmbz7YgC4RRx/ryWBGXowsX+pcTCH23+JlGDhrDEX/WT8RfgdWA 6NdnA2M3Ak5wftOIkbUG5XU2IM/kkApe+m6B2fuwG7wNk/EHYi2A9bad4jFm6ZeDugvH ik+h2QoLKqD2lTAVXkEysE77OgTtLlV+YNsdkFT8rPczoRqEQUDkOACXvdBea27QhPx0 1qG/whC6Dwpe9ghL03WHz4GSB18qMhzDncMyzl4a9v0D5IbZR+Sil/ng/v19PzUxOLnC e7Mg== X-Gm-Message-State: AFeK/H1XQTpZXKUAUbu3dVUJWqlny1VmEBRPYg+OsjwaSLx794fpSsWAfGmOSRq3TvtaBLRa X-Received: by 10.223.160.143 with SMTP id m15mr8529692wrm.116.1489664134451; Thu, 16 Mar 2017 04:35:34 -0700 (PDT) From: Ard Biesheuvel To: edk2-devel@lists.01.org Date: Thu, 16 Mar 2017 11:35:28 +0000 Message-Id: <1489664128-30700-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Subject: [edk2] [PATCH] MdeModulePkg/DxeCore: deal with allocations spanning several memmap entries X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: feng.tian@intel.com, Ard Biesheuvel , star.zeng@intel.com, leif.lindholm@linaro.org, eugene@hp.com MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" When attempting to perform page allocations using AllocateAddress, we fail to check whether the entire region is free before splitting the region. This may lead to memory being leaked further into the routine, when it turns out that one of the memory map entries intersected by the region is already occupied. In this case, prior conversions are not rolled back. For instance, starting from this situation 0x000040000000-0x00004007ffff [ConventionalMemory ] 0x000040080000-0x00004009ffff [Boot Data ] 0x0000400a0000-0x000047ffffff [ConventionalMemory ] a failed EfiLoaderData allocation @ 0x40000000 that covers the BootData region will fail, but leave the first part of the allocation converted, so we end up with 0x000040000000-0x00004007ffff [Loader Data ] 0x000040080000-0x00004009ffff [Boot Data ] 0x0000400a0000-0x000047ffffff [ConventionalMemory ] even though the AllocatePages() call returned an error. So let's check beforehand that AllocateAddress allocations are covered by a single memory map entry, so that it either succeeds or fails completely, rather than leaking allocations. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- MdeModulePkg/Core/Dxe/Mem/Page.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/P= age.c index 260a30a214c7..92306b2f1b45 100644 --- a/MdeModulePkg/Core/Dxe/Mem/Page.c +++ b/MdeModulePkg/Core/Dxe/Mem/Page.c @@ -755,6 +755,17 @@ CoreConvertPagesEx ( } =20 // + // If we are converting the type of the range from EfiConventionalMemo= ry to + // another type, we have to ensure that the entire range is covered by= a + // single entry. + // + if (ChangingType && (NewType !=3D EfiConventionalMemory)) { + if (Entry->Start > End || Entry->End < End) { + DEBUG ((DEBUG_ERROR | DEBUG_PAGE, "ConvertPages: range %lx - %lx c= overs multiple entries\n", Start, End)); + return EFI_NOT_FOUND; + } + } + // // Convert range to the end, or to the end of the descriptor // if that's all we've got // --=20 2.7.4 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel