From: "Ni, Ruiyu" <ruiyu.ni@intel.com>
To: Laszlo Ersek <lersek@redhat.com>, "Shi, Steven" <steven.shi@intel.com>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [PATCH] MdeModulePkg/SmmCore: Fix hang due to already-freed memory deference
Date: Fri, 2 Feb 2018 00:54:22 +0000 [thread overview]
Message-ID: <734D49CCEBEEF84792F5B80ED585239D5BB73DE5@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <1bde96c6-7ca3-0ee8-9990-6e0ca17026fe@redhat.com>
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Friday, February 2, 2018 12:12 AM
> To: Ni, Ruiyu <ruiyu.ni@intel.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen.yao@intel.com>; Zeng, Star <star.zeng@intel.com>
> Subject: Re: [edk2] [PATCH] MdeModulePkg/SmmCore: Fix hang due to already-
> freed memory deference
>
> 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
Laszlo,
I agree your fix is quite simple and no performance impact.
But if caller supplies an invalid DispatchHandle, checking the signature
means to read the memory whose address is provided by caller.
I remember Steven Shi submitted several bugs regarding this because
he considered such reading access is bad.
Steven,
Any comments?
>
> > 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 prev parent reply other threads:[~2018-02-02 0:48 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 ` [PATCH] MdeModulePkg/SmmCore: Fix hang due to already-freed memory deference Laszlo Ersek
2018-02-02 0:54 ` Ni, Ruiyu [this message]
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=734D49CCEBEEF84792F5B80ED585239D5BB73DE5@SHSMSX104.ccr.corp.intel.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