public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>
Cc: Ladi Prosek <lprosek@redhat.com>,
	edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: multiple levels of support for MOR / MORLock
Date: Fri, 29 Sep 2017 13:05:33 +0200	[thread overview]
Message-ID: <1aa05a42-a7a7-410b-c123-8face8be9f78@redhat.com> (raw)
In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A9C9497@shsmsx102.ccr.corp.intel.com>

On 09/29/17 03:52, Yao, Jiewen wrote:
> Thanks Laszlo.
> 
> Yes, I agree it is bug. Would you please help to file a bugzilar in EDKII?
> 
> For the fix, I think we have a way to resolve it without PCD. (I do not want to bother a platform developer to set a new PCD.)
> 
> The only invalid case we need handle is: MOR is absent, but MORL is present.
> 
> My thought is to let Variable driver check if MOR is present. Variable driver can defer the MORL setting at EndOfDxe event based upon the presence of MOR. If MOR driver is present, it sets MOR at entrypoint. EndOfDxe is good enough to know the state.
> 
> Also, because EndOfDxe is PI event, the UEFI OS is not aware of that.

Sounds great; thanks a lot!

I've filed:

  https://bugzilla.tianocore.org/show_bug.cgi?id=727

If possible I'd like the fix to be committed sometime next week. Is it
OK if I try and submit a patch soon? My plan is the following:

- In MorLockInit() [TcgMorLockSmm.c], call
gSmst->SmmRegisterProtocolNotify() in order to register a callback for
gEfiSmmEndOfDxeProtocolGuid

- In the callback function, call VariableServiceGetVariable(), with size
0, to see if MOR is present -- if EFI_BUFFER_TOO_SMALL is returned, MOR
is present; otherwise MOR is absent.

- If MOR is present, then call SetMorLockVariable(0) from the callback
function; like MorLockInit() does now. Otherwise, do nothing.

- It looks like there are no circumstances under which I should
de-register the callback. (I.e. call SmmRegisterProtocolNotify() with a
NULL Function argument.)


Now, I can see that VariableSmm.c already installs such a callback --
SmmEndOfDxeCallback(). Should I hook into that callback function through
a new BOOLEAN variable, such as "mDelayedMorLockInit" (and then
MorLockInit() would only set this variable to TRUE), or should I install
a separate callback?

Either way, I don't think that I should do the MOR/MORL stuff in the
current SmmEndOfDxeCallback() function *unconditionally*, because that
callback is set up when the *read* half of the variable services is
initialized, but MORL only becomes relevant when the *write* half of the
variable services is initialized (which occurs in the
SmmFtwNotificationEvent() callback, i.e. when the FaultTolerantWrite SMM
protocol becomes available). Hence I think we need either a separate
callback registration, or a new boolean for the existent callback.

Thanks!
Laszlo


  reply	other threads:[~2017-09-29 11:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-28 12:55 multiple levels of support for MOR / MORLock Laszlo Ersek
2017-09-29  1:52 ` Yao, Jiewen
2017-09-29 11:05   ` Laszlo Ersek [this message]
2017-09-29 13:26     ` Yao, Jiewen
2017-09-29 16:38       ` Laszlo Ersek
2017-09-30  3:53         ` Yao, Jiewen
2017-09-30 20:33           ` Laszlo Ersek
2017-10-01  3:56             ` Yao, Jiewen
2017-10-01  8:23               ` Laszlo Ersek
2017-10-01 11:36                 ` Yao, Jiewen
2017-10-02 19:48                   ` Laszlo Ersek

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=1aa05a42-a7a7-410b-c123-8face8be9f78@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