On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote: > On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek <[email protected]> wrote: > > > > On 01/04/19 12:57, Ard Biesheuvel wrote: > > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek <[email protected]> wrote: > > >> > > >> On 01/03/19 12:03, Ard Biesheuvel wrote: > > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja <[email protected]> > > >>> 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 <[email protected]> > > >>>> --- > > >>>> 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/[email protected]>, > > >> - 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 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. Please let me know if I am missing something. cheers, Achin _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
