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 45066208AE3E2 for ; Thu, 21 Feb 2019 01:04:39 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9C8346699F; Thu, 21 Feb 2019 09:04:38 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-111.rdu2.redhat.com [10.10.120.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id 835351001DC1; Thu, 21 Feb 2019 09:04:36 +0000 (UTC) To: Ard Biesheuvel , Jagadeesh Ujja , "Zeng, Star" , "Yao, Jiewen" Cc: "Kinney, Michael D" , "Gao, Liming" , "edk2-devel@lists.01.org" , "Zhang, Chao B" References: <1550570820-29379-1-git-send-email-jagadeesh.ujja@arm.com> From: Laszlo Ersek Message-ID: <615a9ac8-1ca9-94e1-a473-b251dae57460@redhat.com> Date: Thu, 21 Feb 2019 10:04:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 21 Feb 2019 09:04:38 +0000 (UTC) Subject: Re: [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 09:04:39 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/20/19 13:23, Ard Biesheuvel wrote: > On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja wrote: >> >> hi Ard, >> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel >> wrote: >>> >>> Hello Jagadeesh, >>> >>> On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja wrote: >>>> >>>> In preparation for providing a standalone MM based non-secure variable >>>> runtime driver, factor out some portions that are specific to the >>>> traditional driver, mainly related to locating variable arch protocol >>>> and variable write arch protocol, which are not required to be located >>>> when using standalone MM based secure variable implementation. >>>> >>> >>> While i think this change is correct from a technical perspective, I >>> don't think this is the right approach. >>> >> these changes are mandatory, this is one of the possible solution. >> >>> It was a deliberate decision to expose the MM services in a way that >>> only the producer of the communication protocol is aware of the >>> implementation details, i.e., whether it is backed by tradtional MM or >>> standalone MM. >>> >> can you please provide more details on how "exposing the MM services" >> will help to resolve the issue here. if this helps, definitely i will use that. >> > > Let me rephrase this for the benefit of the MdeModulePkg maintainers, > and ask them their opinion. > > Currently, the DXE runtime driver that produces the architectural > varstore protocols that are based on communication with MM components > living elsewhere, rely on the EFI protocol database for sequencing. > I.e., after dispatch, they wait for certain protocols to be installed > into the DXE protocol database by the SMM drivers before proceeding to > install the variable arch protocols. > > This does not work for standalone MM, since it has no access to the > DXE protocol database, nor is it needed, since it may be assumed that > the MM execution context is fully configured by the time the DXE phase > starts. > > Jagadeesh's proposal is to factor this out, and create two different > .INFs to build the same DXE runtime driver in two different ways. This > defeats the purpose of having an abstract MM communication protocol, > so it is something I would like to avoid. On the other hand, is it not > obvious how to parameterize this requirement in another way. > > For the moment, I could live with putting this into a library, and > leave it up to the platform to ensure the combination of the library > resolution with the driver that produces the MM communicate protocol > is a sane one. > > Any thoughts? I think I'm missing the gist of the library approach; still, would it be possible for affected platforms (i.e. those that depend on standalone MM) to procude the necessary DXE protocols (for unblocking the variable runtime driver) in a platform DXE driver? Thanks Laszlo