Re: [PATCH 00/13] Extend secure variable service to be usable from Standalone MM

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On Thu, 3 Jan 2019 at 10:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Thu, 3 Jan 2019 at 08:43, Jagadeesh Ujja <jagadeesh.ujja@arm.com> wrote:
> >
> > hi Ard
> >
> > On Wed, Jan 2, 2019 at 10:45 PM Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > >
> > > On Thu, 20 Dec 2018 at 15:23, Gao, Liming <liming.gao@intel.com> wrote:
> > > >
> > > > Jagadeesh:
> > > >   MdeModulePkg Variable service/Fault tolerant/Nor Flash driver depends on StandaloneMmServicesTableLib library class header file. This header file is added into MdePkg. It has two interfaces. One is global gMmst, another is function InMm(). So, there is no dependency issue here.
> > > > And, MdePkg adds one StandaloneMmServicesTableLib library INF with empty implementation, this library is just for build. It sets gMmst=NULL, and always return FASLE in InMm(). This library can be used in MdeModulePkg.dsc to make Variable driver pass build. There is also no dependency issue here. Last, Platform DSC file will refer to the real StandaloneMmServicesTableLib library INF from StandaloneMmPkg.
> > > >
> > >
> > > I think we should avoid the need for InMm() altogether for standalone
> > > MM. It will always return TRUE for standalone MM modules, and it will
> > > always return FALSE for other modules, so the distinction should be
> > > made at build time.
> > >
> > > This means that we need to refactor the SMM 'server' modules and/or
> > > libraries so that any code they cannot share (like boot services
> > > invocations) are only included in the classic SMM versions.
> > >
> > > I have pushed my own prototype code here:
> > > https://github.com/ardbiesheuvel/edk2/commits/standalone-mm
> > >
> > > There is some overlap with Jagadeesh's work. I will work with him
> > > directly to resolve this before posting any new revisions.
> > >
> > InMm()”  and “PcdStandaloneMmVariableEnabled” are defined to reuse the
> > existing code as much as possible.
> > Initially I have done separate copy of the file to avoid “if..else”
> > but had a comment about “duplicating code primarily due to the
> > maintenance overhead”
> >
>
> We shouldn't rely on runtime functions and PCDs to make build time decision.
>
> Lots of the SMM code can be refactored. As Jian suggested, we could
> introduce a helper library with implementations for the MM protocol
> handling and memory allocation routines exposed via the system table,
> so that the users can invoke the abstract library.
>

Actually, looking at the PI spec, it seems that SMM is deprecated, and
so we should port these drivers to the new MM system table entirely.