From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C185620945B68 for ; Fri, 29 Sep 2017 04:02:19 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3DE1B883A0; Fri, 29 Sep 2017 11:05:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3DE1B883A0 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-150.rdu2.redhat.com [10.10.120.150]) by smtp.corp.redhat.com (Postfix) with ESMTP id 600EA627D9; Fri, 29 Sep 2017 11:05:34 +0000 (UTC) To: "Yao, Jiewen" Cc: Ladi Prosek , edk2-devel-01 References: <039cf353-80fb-9f20-6ad2-f52517ab4de7@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503A9C9497@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <1aa05a42-a7a7-410b-c123-8face8be9f78@redhat.com> Date: Fri, 29 Sep 2017 13:05:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A9C9497@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 29 Sep 2017 11:05:35 +0000 (UTC) Subject: Re: multiple levels of support for MOR / MORLock X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 11:02:21 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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