Re: [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library

[Achin Gupta <Achin.Gupta@arm.com>]

On Mon, Jan 07, 2019 at 07:55:36PM +0100, Ard Biesheuvel wrote:
> On Mon, 7 Jan 2019 at 19:50, Achin Gupta <Achin.Gupta@arm.com> wrote:
> >
> > On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote:
> > > On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek <lersek@redhat.com> wrote:
> > > >
> > > > On 01/04/19 12:57, Ard Biesheuvel wrote:
> > > > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek <lersek@redhat.com> wrote:
> > > > >>
> > > > >> On 01/03/19 12:03, Ard Biesheuvel wrote:
> > > > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja <jagadeesh.ujja@arm.com> wrote:
> > > > >>>>
> > > > >>>> Some of the existing DXE drivers can be refactored to execute within
> > > > >>>> the Standalone MM execution environment as well. Allow such drivers to
> > > > >>>> get access to the Standalone MM services tables.
> > > > >>>>
> > > > >>>> Add a mechanism to determine the execution mode is required.
> > > > >>>> i.e, in MM or non-MM
> > > > >>>>
> > > > >>>> Contributed-under: TianoCore Contribution Agreement 1.1
> > > > >>>> Signed-off-by: Jagadeesh Ujja <jagadeesh.ujja@arm.com>
> > > > >>>> ---
> > > > >>>>  MdePkg/Include/Library/StandaloneMmServicesTableLib.h                        | 43 ++++++++++++++++++++
> > > > >>>>  MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c   | 39 ++++++++++++++++++
> > > > >>>>  MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf | 36 ++++++++++++++++
> > > > >>>>  MdePkg/MdePkg.dec                                                            |  4 ++
> > > > >>>>  4 files changed, 122 insertions(+)
> > > > >>>>
> > > > >>>
> > > > >>> OK, so since the PI spec only refers to MM mode now, this library
> > > > >>> class should be
> > > > >>>
> > > > >>> MmServicesTableLib|Include/Library/MmServicesTableLib.h
> > > > >>>
> > > > >>> with an implementation in MdeModulePkg that exposes the deprecated SMM
> > > > >>> system table as the MM system table.
> > > > >>>
> > > > >>> In StandaloneMmPkg, we can add an implementation that exposes the
> > > > >>> standalone MM system table.
> > > > >>>
> > > > >>> (They are binary compatible, so it is just a matter of casting one
> > > > >>> pointer to the other)
> > > > >>>
> > > > >>> With this in place, we can go ahead and update FaultTolerantWrite and
> > > > >>> Variable SMM driver to switch from SmmServicesTableLib to
> > > > >>> MmServicesTableLib. This will require existing x86 platforms to define
> > > > >>> a new library class resolution for MmServicesTableLib, referring to
> > > > >>> the implementation in MdeModulePkg. This is unfortunate, but it is an
> > > > >>> unavoidable consequence of the PI spec changes.
> > > > >>
> > > > >> It shouldn't be too intrusive or hard to review, I expect.
> > > > >>
> > > > >>>
> > > > >>> Remaining question is what to do with InSmm() ...
> > > > >>
> > > > >> I'm lacking the context on this; on the other hand, I can refer back to
> > > > >> at least one earlier discussion -- there had been multiple -- of the
> > > > >> discrepancy between the PI spec and the edk2 code. See:
> > > > >>
> > > > >> - bullet (9) in
> > > > >> <http://mid.mail-archive.com/aada511c-bdb9-d833-caa5-bee56cc47d27@redhat.com>,
> > > > >> - and
> > > > >> <http://mid.mail-archive.com/0C09AFA07DD0434D9E2A0C6AEB0483103BB55B46@shsmsx102.ccr.corp.intel.com>.
> > > > >>
> > > > >> Not sure how that can be applied to Arm.
> > > > >>
> > > > >
> > > > > The code I posted yesterday does not use InMm() at all. For standalone
> > > > > MM, it should always return TRUE anyway, and any code that a driver
> > > > > would execute if it returned FALSE needs to be factored out anyway,
> > > > > since it should not end up in standalone MM binaries as dead code.
> > > > >
> > > >
> > > > OK. That seems to make sense. I've read up a bit on "standalone MM" in
> > > > the PI v1.6 spec, vol 4. Having no access to UEFI protocols even in the
> > > > entry point function, at driver init time, seems challenging to me. I
> > > > guess I'll learn more about this as a part of the usual list traffic.
> > > >
> > > > What is the MODULE_TYPE that standalone MM drivers use, in place of
> > > > DXE_SMM_DRIVER (= EFI_FV_FILETYPE_MM, 0x0A)?
> > > >
> > > > Hm... from the other patches, it seems to be MM_STANDALONE (=
> > > > EFI_FV_FILETYPE_MM_STANDALONE, 0x0E). OK.
> > > >
> > > > If I'd like to see a short summary of standalone MM, relative to
> > > > traditional MM, and why it is more suitable -- I presume -- for aarch64,
> > > > which document should I look at, from
> > > > <https://mantis.uefi.org/mantis/view.php?id=1390>, for example?
> > > >
> > >
> > > Perhaps Achin can answer this, since he has been driving the spec side
> > > of this? (and maintains StandaloneMmPkg)
> >
> > The idea behind MM Standalone mode was to sandbox MM code in self sufficient
> > execution context. This was a step to avoid some of the vulnerabilities in
> > traditional SMM due to code and data sharing with DXE.
> >
> > On AArch64, the MM standalone mode is initialised during the SEC phase. This
> > corresponds to Trustzone initialisation. Furthermore, the MM standalone
> > execution context is placed in user mode (Secure EL0) instead of running it in a
> > privileged processor mode (S-EL1 or EL3 on AArch64, Ring -2 or SMM on x86). This
> > restricts what the MM standalone context can see and do. Lastly, after SEC no
> > more MM Standalone drivers can be initialized during PEI or DXE (in contrast to
> > the example in PI 1.6 Section 1.5.2).
> >
> > Hope that makes sense?
> >
> 
> I agree, but this is not what StandaloneMmPkg implements today: it
> implements a MmFvDispatchHandler that permits a FV to be brough into
> the MM environment, and the MM dispatcher will happily dispatch all
> the MM_STANDALONE modules it contains.

Umm! Not following why is that a problem. The FV on AArch64 must only contain
MM_STANDALONE drivers. These drivers rely on the MMST which is exclusively used
in the secure world. So the isolation is still achieved right? Are you saying
that additional checks are required to enforce this on AArch64?

> 
> Also, there are some other pieces missing (which I mentioned in one of
> the other threads but I suppose you may not have caught up yet):
> EndOfDxe (as well as some other PI defined events) needs to be
> signalled to the standalone MM context by some non-MM agent, and I
> think there are other parts of the traditional SMM IPL that have not
> been ported to standalone MM yet.

Yes! I am still catching up but saw the patches that Supreeth has reviewed and
they make sense. Could you please explain the need for End of DXE signalling and
the traditional SMM IPL. It is not obvious to me :o(

cheers,
Achin

> 
> > I have not seen all the patches in this and related series but the use of InMM()
> > to allow code to have a DXE driver or a MM Standalone driver personality seems
> > to defeat the entire purpose of Standalone MM. My concern is that any code that
> > is relevant only to DXE or PEI must not be a part of the MM Standalone
> > context. This could be achieved through proper refactoring + conditional
> > compilation. If the decision is taken at runtime then this is just traditional
> > MM.
> >