]> git.proxmox.com Git - mirror_edk2.git/commit - MdeModulePkg/Core/Dxe/Mem/Page.c
MdeModulePkg/DxeCore: deal with allocations spanning several memmap entries
authorArd Biesheuvel <ard.biesheuvel@linaro.org>
Thu, 16 Mar 2017 11:35:28 +0000 (11:35 +0000)
committerArd Biesheuvel <ard.biesheuvel@linaro.org>
Fri, 17 Mar 2017 18:50:55 +0000 (18:50 +0000)
commit3f2ae009ec66430f13bd24f2de475965eb3bc6df
tree06feffbf159d0cb61920ecfa1aab93a1665f1c57
parent01eb3f39bbcc5b6474d69cff3922be8eb1856636
MdeModulePkg/DxeCore: deal with allocations spanning several memmap entries

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 <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
MdeModulePkg/Core/Dxe/Mem/Page.c