From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::d42; helo=mail-io1-xd42.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 56075208AE35F for ; Thu, 21 Feb 2019 01:45:50 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id p17so947098iol.7 for ; Thu, 21 Feb 2019 01:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eTUEnLVPHCPCL7klUkqntwWzVIkXScZ6rkE9tiOONLU=; b=MfvT7z8yrDELgPdJ1b+jitTH6hD496/86E40GSenizUfTMyqDpcsx32CH8QEpqbvxP 8pkMLyXmQJkNtvs0zcCjM67you6noBqzEb4l2AhIDgRGr97HaYF7e/m3zb0AWQkHAmjG BCragTQzROnK1JY1I/e2WDcDVGkHywRLnLTWepv2rmEgwejrnQxN4Q5MR/06fm0f4KV3 xypDPLx/tWqd459kqrY/4D4KqxIqGoAPt1zCiPPE01KmiWJWdcMeTa3nF+ElGUw8hRiQ F35FzbMY403vmnaf5V5lw+uJNszBdONPZ6T1tsCjlFEo8N+3LhHQDhR3z1eK3rZrEB7u YcCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eTUEnLVPHCPCL7klUkqntwWzVIkXScZ6rkE9tiOONLU=; b=GvC2F/CiQhRPxFYvc9sZhUVJkPrBYP2sDCL8kmRa4u04q6F2wOz+DopK6a5U9RHN/U 8bhw2QccUKVQE6lQmxmJ7azTg3jkTNbs+rxQzZLYAkp8mRoUE4kQk8vlu2QiAoTM7b4a rjMd2l6nj7asxIs1HLAulBBg6BPGzBla8/2l9FusFrrv//pUMVJ3rMqiomM2gHp/mbqL 1RZ/djDHK4VhnaUjQURNZxJa23sGRvUBpwomCkcFKnYtP5R4tDvUTQX3XiRqbTjXHnwx EE13pRMXNN2dLm3rYX0Vzap7HjszGGfMNF29CIj46w/Qh9rI0hVlV1WkUCVolGBBfn7u DhDQ== X-Gm-Message-State: AHQUAuacVuqXkcFKndNO0jtyGKT53vrYEWJHcLPKPdAN5MOnsHhxxKhx n0eBPPVM35kYEoBC2KMWmnlrVBR758OV26pMH06uHIMwAOs= X-Google-Smtp-Source: AHgI3IbmrKGAstjYqQy9G4CBWb1nux5Qxte+QUhnwOD0C+tvtFTdgxfccTNWcfO/W35PqMRpofPNodmiN2CcKiYF4fM= X-Received: by 2002:a5e:d609:: with SMTP id w9mr21650310iom.170.1550742349776; Thu, 21 Feb 2019 01:45:49 -0800 (PST) MIME-Version: 1.0 References: <1550570820-29379-1-git-send-email-jagadeesh.ujja@arm.com> <615a9ac8-1ca9-94e1-a473-b251dae57460@redhat.com> In-Reply-To: From: Ard Biesheuvel Date: Thu, 21 Feb 2019 10:45:37 +0100 Message-ID: To: "Zeng, Star" Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , "Gao, Liming" , "Yao, Jiewen" , "Zhang, Chao B" , "Kinney, Michael D" 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:45:51 -0000 Content-Type: text/plain; charset="UTF-8" On Thu, 21 Feb 2019 at 10:33, Zeng, Star wrote: > > On 2019/2/21 17:11, Ard Biesheuvel wrote: > > On Thu, 21 Feb 2019 at 10:04, Laszlo Ersek wrote: > >> > >> 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? > >> > > > > Yes, that is the other option: we could create a library that > > unconditionally produces those protocols and hook it into the MM > > communication driver via NULL library class resolution. > > > > I am not familiar with standalone MM, either ARM. So may have no much > valuable opinion. > > For this case, standalone MM could not install DXE protocols into DXE > protocol database to notify the wrapper (VariableSmmRuntimeDxe), so need > another way to install the DXE protocols, right? Yes > Could standalone MM assume the MM handler for variable is ready when MM > communication driver runs? Yes > If yes, a NULL library instance should work (as a stub to install the > DXE protocols in its constructor). :) > Yes, that was my suggestion. So Jagadeesh, could you please take this approach instead? - Create a library in StandaloneMmPkg with LIBRARY_CLASS = NULL and a constructor that installs the two protocols. - Update your platform so that the MM communication driver is included as ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf { NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf } I don't think this will violate any ordering constraints, given that the drivers that have a dependency on these protocols also have a dependency on the MM communicate driver itself. Thanks, Ard.