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::141; helo=mail-it1-x141.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 EFB3B208AE3E2 for ; Thu, 21 Feb 2019 01:11:58 -0800 (PST) Received: by mail-it1-x141.google.com with SMTP id l15so21737876iti.4 for ; Thu, 21 Feb 2019 01:11:58 -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=+rZ1Qcir4nK5q4x8TXy+aoEEF2ow6wPt6CJplBPJSmw=; b=ngloqMZw2iEU9auopo2R10Wbi9wd4MMZvOjClBQiGWy2ze27r/IwusI+Q3tYA1j0+C f2lecV6jdGx1ieXnkSHg1TVFnGVTfHxZ2evziecuQpAlIoFqjXW9u6xrMgOj8OWW2l7D h8BMYPHV8UvBHxafSJ0MH+STuAOxUF4KwVQ6QOzXzjThrrktde8xCLHbNElVgVUifiQ6 9tni7tuqpKXwd0XTE+NE+ybrHM1zydJlaIWHxn7erXekuxuCIQCEK+PPkTGLGfRF0l8+ HzcbLBOq1kfihhr/uUu6VBNgQZ79IOPyI3wJkhWe1XiWTY4Eib/zz1SGDFCvMqpwir/F E+8g== 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=+rZ1Qcir4nK5q4x8TXy+aoEEF2ow6wPt6CJplBPJSmw=; b=XUzw4zjHdiPQyjeScv+XqvXWlZS8P/ctFCyveMFk7ttOaPDXM6J01MHslHZsEuWrBd a2cE0rJT+yiClRcrBOGScNY17x0QM5hEmQEXbnup/+nrsDQVPjVIalEXS18BHlY+agp7 lgM1NIOsNHX8mZGIyx3CtVj82YjmVuyaEDTnApwdo0L8Y1xN8rSL7Nn7HHPHGY3PUniY NoVtpTrH1+fzMw+w87yptYX7CP0PmTibO4QdNDA2xDqHaVPLai13fgGoSLV5a8qf8XHF DR4LYhM/SJt2PZByp9q7qP2O06Ux2ISb1O7/s+Slc7VsPVBgL4VwwkVaVzga85l8QzV5 v4Nw== X-Gm-Message-State: AHQUAubE87m0Y64DSFRiZKEId8Cdn9ZWdPT9W3V3swRV//h/xvi/NWbo Nt8bMyZTkvZ0MGotnekVooQxDMmPYuxfShaalUk4qg== X-Google-Smtp-Source: AHgI3IbdLbWDJbd8OWCfIT8m6B6Upl/8aiXD2Vy9+pwh2TW4Eq95LkzOVRUknxArciNSlo3haK9B8Z4MSGSt+ynJcoE= X-Received: by 2002:a02:3342:: with SMTP id k2mr19534362jak.62.1550740317179; Thu, 21 Feb 2019 01:11:57 -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: <615a9ac8-1ca9-94e1-a473-b251dae57460@redhat.com> From: Ard Biesheuvel Date: Thu, 21 Feb 2019 10:11:44 +0100 Message-ID: To: Laszlo Ersek Cc: Jagadeesh Ujja , "Zeng, Star" , "Yao, Jiewen" , "Kinney, Michael D" , "Gao, Liming" , "edk2-devel@lists.01.org" , "Zhang, Chao B" 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:11:59 -0000 Content-Type: text/plain; charset="UTF-8" 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.