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::135; helo=mail-it1-x135.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 BD19A201B045F for ; Wed, 20 Feb 2019 04:23:46 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id l66so14924476itg.3 for ; Wed, 20 Feb 2019 04:23:46 -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=55eqII5g7DKGpRAlSIjzuLAv3BBuoOBL61FK1sFutLw=; b=sO/W7UgCObyGlU46k4alHHh/HvCj+iR7f/UO1DDB3k+31n2Eza2WKrl8rRIS/pixNy OlcqImj4OmWWzjCuwuLei2R9WqmojY2cDJhcRdC34kzByTvty/oiYowAP7CNMJrMCQfn IsHq2grvcbl0EkiidpHccgPO2wGc7bYMSy1afnhmlNCZRhE3PxwcRJ6/7TN8DM91qHcs Hd5t+fbD6QLuW/n6AJ7w4imeSLWf4RskxZHPXI7k0L4jlgl2FhoEtF5lNkq/Ncat5Ouf NmFrEIoOrI7YCERtA85yQ/BCkJ9iSVSKRWEpf8954edOM5OhdZ0IH11r2UF0PRTq7CVH 2TOA== 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=55eqII5g7DKGpRAlSIjzuLAv3BBuoOBL61FK1sFutLw=; b=CZQDTc3de1HB/eWdgL7QEZNs6v10RSZWSylAV6EnUfWftXZI4ejl5tsLaQrSwDby8W i/HM7os80znwxsgW7TrnlVUlfQl+2CVV18bCDaudoyrBVQwTd0WrGr//dok7QP27+AUc rRTL/yGmn9mJ9hckQCw0Thhb9+d1I7Izpbo4KScllpwrwdpDbW+FejdG+1BGrZNyoMMT Ynorh12oZDXoS4IQJfwo/SXLl8aOysdkmzXSIa9ZXPbEnvOtI2KOfI+jgIlAJQ1VWT3J gf+RtQA6yv1IK+/LYWQiWZL1h7z2negCorA0TdqL7U/IoFvx2zb7rU+9c3dJUbHO1B6q 0LEw== X-Gm-Message-State: AHQUAua6n48dPpN+/qzPgph4HE2VFi3quP6ApnM4a/GZYZ4RAtw/DJPH GHG3+pl0pXLtK35MatOgD5PNqHlWjPbKysn8rC1/Rg== X-Google-Smtp-Source: AHgI3IbHHhObXjq8Q8D+O+7DXY62gUgQqo3Z2qJcY7dFMBv8bsVU1WxwxZZ+nd1zaaCnC+rhoYXdFon4mhWGQvnCCKM= X-Received: by 2002:a24:1947:: with SMTP id b68mr4602085itb.121.1550665425387; Wed, 20 Feb 2019 04:23:45 -0800 (PST) MIME-Version: 1.0 References: <1550570820-29379-1-git-send-email-jagadeesh.ujja@arm.com> In-Reply-To: From: Ard Biesheuvel Date: Wed, 20 Feb 2019 13:23:34 +0100 Message-ID: To: Jagadeesh Ujja , "Zeng, Star" , "Yao, Jiewen" Cc: Achin Gupta , "Kinney, Michael D" , "edk2-devel@lists.01.org" , "Zhang, Chao B" , "Gao, Liming" 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: Wed, 20 Feb 2019 12:23:47 -0000 Content-Type: text/plain; charset="UTF-8" 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?