From: Laszlo Ersek <lersek@redhat.com>
To: Ruiyu Ni <ruiyu.ni@intel.com>, edk2-devel@lists.01.org
Cc: Jiewen Yao <jiewen.yao@intel.com>, Star Zeng <star.zeng@intel.com>
Subject: Re: [PATCH] MdeModulePkg/SmmCore: Fix hang due to already-freed memory deference
Date: Thu, 1 Feb 2018 17:12:20 +0100 [thread overview]
Message-ID: <1bde96c6-7ca3-0ee8-9990-6e0ca17026fe@redhat.com> (raw)
In-Reply-To: <20180201101539.320452-1-ruiyu.ni@intel.com>
Hello Ray,
On 02/01/18 11:15, Ruiyu Ni wrote:
> SmiHandlerUnRegister() validates the DispatchHandle by checking
> whether the first 32bit matches to a certain signature
> (SMI_HANDLER_SIGNATURE).
> But if a caller calls *UnRegister() twice and the memory freed by
> first call still contains the signature, the second hang may hang.
>
> The patch fixes this issue by locating the DispatchHandle
> in all SMI handlers, instead of checking the signature.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Star Zeng <star.zeng@intel.com>
> ---
> MdeModulePkg/Core/PiSmmCore/Smi.c | 37 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 32 insertions(+), 5 deletions(-)
I'm mildly curious: can we just zero out the signature when the
de-registration / freeing happens? Otherwise, the nested loop added
below will penalize (performance-wise) correctly written client code as
well.
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c
> b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index ad483a1877ce..6596ea9560d1 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -290,6 +290,7 @@ SmiHandlerUnRegister (
> SmiEntry = SmiHandler->SmiEntry;
>
> RemoveEntryList (&SmiHandler->Link);
> + SmiHandler->Signature = 0;
> FreePool (SmiHandler);
>
> if (SmiEntry == NULL) {
Generally, if client code violates an interface contract, then the
called function is not responsible for catching the error and preventing
undefined behavior. For "quality of service", we can go to certain
lengths nonetheless, but it should hopefully not hurt valid client code.
For example, I seem to remember that the list data structure
implementation checks the internal consistency (which can be costly)
only if a PCD is set to a certain value. Is that right? Is it an option
here? (If the above zeroing is not good for some reason.)
Anyway, I'm asking mainly for my own education.
Thanks!
Laszlo
> diff --git a/MdeModulePkg/Core/PiSmmCore/Smi.c b/MdeModulePkg/Core/PiSmmCore/Smi.c
> index ad483a1877..0c09e7fa10 100644
> --- a/MdeModulePkg/Core/PiSmmCore/Smi.c
> +++ b/MdeModulePkg/Core/PiSmmCore/Smi.c
> @@ -1,7 +1,7 @@
> /** @file
> SMI management.
>
> - Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.<BR>
> + Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.<BR>
> This program and the accompanying materials are licensed and made available
> under the terms and conditions of the BSD License which accompanies this
> distribution. The full text of the license may be found at
> @@ -276,14 +276,41 @@ SmiHandlerUnRegister (
> {
> SMI_HANDLER *SmiHandler;
> SMI_ENTRY *SmiEntry;
> + LIST_ENTRY *EntryLink;
> + LIST_ENTRY *HandlerLink;
>
> - SmiHandler = (SMI_HANDLER *) DispatchHandle;
> -
> - if (SmiHandler == NULL) {
> + if (DispatchHandle == NULL) {
> return EFI_INVALID_PARAMETER;
> }
>
> - if (SmiHandler->Signature != SMI_HANDLER_SIGNATURE) {
> + //
> + // Look for it in root SMI handlers
> + //
> + SmiHandler = NULL;
> + for ( HandlerLink = GetFirstNode (&mRootSmiEntry.SmiHandlers)
> + ; !IsNull (&mRootSmiEntry.SmiHandlers, HandlerLink) && (SmiHandler != DispatchHandle)
> + ; HandlerLink = GetNextNode (&mRootSmiEntry.SmiHandlers, HandlerLink)
> + ) {
> + SmiHandler = CR (HandlerLink, SMI_HANDLER, Link, SMI_HANDLER_SIGNATURE);
> + }
> +
> + //
> + // Look for it in non-root SMI handlers
> + //
> + for ( EntryLink = GetFirstNode (&mSmiEntryList)
> + ; !IsNull (&mSmiEntryList, EntryLink) && (SmiHandler != DispatchHandle)
> + ; EntryLink = GetNextNode (&mSmiEntryList, EntryLink)
> + ) {
> + SmiEntry = CR (EntryLink, SMI_ENTRY, AllEntries, SMI_ENTRY_SIGNATURE);
> + for ( HandlerLink = GetFirstNode (&SmiEntry->SmiHandlers)
> + ; !IsNull (&SmiEntry->SmiHandlers, HandlerLink) && (SmiHandler != DispatchHandle)
> + ; HandlerLink = GetNextNode (&SmiEntry->SmiHandlers, HandlerLink)
> + ) {
> + SmiHandler = CR (HandlerLink, SMI_HANDLER, Link, SMI_HANDLER_SIGNATURE);
> + }
> + }
> +
> + if (SmiHandler != DispatchHandle) {
> return EFI_INVALID_PARAMETER;
> }
>
>
next parent reply other threads:[~2018-02-01 16:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180201101539.320452-1-ruiyu.ni@intel.com>
2018-02-01 16:12 ` Laszlo Ersek [this message]
2018-02-02 0:54 ` [PATCH] MdeModulePkg/SmmCore: Fix hang due to already-freed memory deference Ni, Ruiyu
2018-02-02 5:40 ` Shi, Steven
2018-02-02 9:55 ` Zeng, Star
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=1bde96c6-7ca3-0ee8-9990-6e0ca17026fe@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