From: "Laszlo Ersek" <lersek@redhat.com>
To: Dov Murik <dovmurik@linux.ibm.com>, devel@edk2.groups.io
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>,
Jordan Justen <jordan.l.justen@intel.com>,
James Bottomley <jejb@linux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
Subject: Re: [edk2-devel] [PATCH v3 0/5] OvmfPkg: Use QemuKernelLoaderFs to read cmdline/initrd
Date: Tue, 29 Jun 2021 15:30:52 +0200 [thread overview]
Message-ID: <b4bd13be-a7d8-5606-a2da-ca24f5d9edc5@redhat.com> (raw)
In-Reply-To: <feccd547-0901-8705-2f52-e04af78afdda@linux.ibm.com>
On 06/29/21 15:03, Dov Murik wrote:
> Out of curiousity, I wonder regarding the leak fixes -- is there a way
> to see that the fix works? Is there some accounting of used pages that
> we can check that decreases after the fix?
You could try a UEFI memmap comparison, but the cmdline is a pool
allocation, not a page allocation, so I don't think the difference is
noticeable in the UEFI memmap (the allocation is really small, so it is
likely satisfied from one of the preallocated "bins").
However, in DEBUG and NOOPT builds of OVMF, FreePool() should actually
wipe (part of) the freed area (with the PcdDebugClearMemoryValue=0xAF
byte value), and then a double-free would trigger an assertion failure
(signature missing), if I remember correctly.
See the CoreFreePoolI() function in "MdeModulePkg/Core/Dxe/Mem/Pool.c",
in particular the signature checks on top, and later DEBUG_CLEAR_MEMORY().
Thanks
Laszlo
prev parent reply other threads:[~2021-06-29 13:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 10:51 [PATCH v3 0/5] OvmfPkg: Use QemuKernelLoaderFs to read cmdline/initrd Dov Murik
2021-06-28 10:51 ` [PATCH v3 1/5] OvmfPkg/GenericQemuLoadImageLib: plug cmdline blob leak on success Dov Murik
2021-06-29 9:27 ` [edk2-devel] " Laszlo Ersek
2021-06-29 10:23 ` Laszlo Ersek
2021-06-28 10:51 ` [PATCH v3 2/5] OvmfPkg/X86QemuLoadImageLib: " Dov Murik
2021-06-29 9:31 ` [edk2-devel] " Laszlo Ersek
2021-06-29 11:18 ` Laszlo Ersek
2021-06-28 10:51 ` [PATCH v3 3/5] Revert "OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command line" Dov Murik
2021-06-29 9:32 ` [edk2-devel] " Laszlo Ersek
2021-06-29 10:23 ` Laszlo Ersek
2021-06-28 10:51 ` [PATCH v3 4/5] OvmfPkg/GenericQemuLoadImageLib: Read cmdline from QemuKernelLoaderFs Dov Murik
2021-06-29 9:44 ` [edk2-devel] " Laszlo Ersek
2021-06-29 10:23 ` Laszlo Ersek
2021-06-28 10:51 ` [PATCH v3 5/5] OvmfPkg/X86QemuLoadImageLib: State fw_cfg dependency in file header Dov Murik
2021-06-29 9:45 ` [edk2-devel] " Laszlo Ersek
2021-06-29 12:54 ` [edk2-devel] [PATCH v3 0/5] OvmfPkg: Use QemuKernelLoaderFs to read cmdline/initrd Laszlo Ersek
2021-06-29 13:03 ` Dov Murik
2021-06-29 13:30 ` Laszlo Ersek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b4bd13be-a7d8-5606-a2da-ca24f5d9edc5@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox