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

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

On Mon, 7 Jan 2019 at 20:21, Achin Gupta <Achin.Gupta@arm.com> wrote:
>
> 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?
>

It means you can invoke a standalone MM service during DXE to dispatch
additional modules on the secure side.


> >
> > 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(
>

The point is that there are PI specified events that we are currently
not signalling in standalone MM, so in that sense, we are not
implementing the PI spec fully.

Note that EndOfDxe is security sensitive - it is used as a trigger to
lock down and/or secure stuff, and if it never get signalled,
standalone MM drivers may falsely assume that the context is more
secure than it is.

If we don't want to deviate too much from the existing capsule update
implementation, we may have to rely on this: perform the
authentication on the non-secure side (but before EndOfDxe), and have
a minimal implementation in standalone MM that does little more than
write the blocks to storage. Without signalling EndOfDxe to the secure
side, this would open up a security hole.