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

[Ard Biesheuvel]

On Sun, 13 Jan 2019 at 13:42, Cohen, Eugene  wrote:
>
> I saw this thread earlier this week and wanted to chime in.
>
> > > 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.
>
> I haven't been following closely the state of StandaloneMmPkg on edk2  - as 
> we were ready to sync up some of our earlier MM stuff to edk2 I learned that 
> the support in place is only partial as patches have been coming in slowly so 
> we chose to implement a version based on the early joint prototype work we 
> did ("uefiproto" repo).  In this there is a DXE component that produces the 
> SMM Communication protocol and also ensures that when key GUIDed events occur 
> in DXE that they are forwarded to MM including EndOfDxe.
>
> I don't see a strong argument for not forwarding the event signaling 
> information to MM - MM can either use the information or ignore it as it sees 
> fit.  I can see scenarios around variable services where knowing what phase 
> of boot the normal world is in is necessary.
>

I agree. If the normal world firmware is guaranteed to signal EndOfDxe
before loading any third party modules, it is not unreasonable to use
this on the secure side as a trust indicator as well.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Cohen, Eugene]

I saw this thread earlier this week and wanted to chime in.

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

I haven't been following closely the state of StandaloneMmPkg on edk2  - as we 
were ready to sync up some of our earlier MM stuff to edk2 I learned that the 
support in place is only partial as patches have been coming in slowly so we 
chose to implement a version based on the early joint prototype work we did 
("uefiproto" repo).  In this there is a DXE component that produces the SMM 
Communication protocol and also ensures that when key GUIDed events occur in 
DXE that they are forwarded to MM including EndOfDxe.

I don't see a strong argument for not forwarding the event signaling 
information to MM - MM can either use the information or ignore it as it sees 
fit.  I can see scenarios around variable services where knowing what phase of 
boot the normal world is in is necessary.


Eugene

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Laszlo Ersek]

On 01/08/19 14:27, Ard Biesheuvel wrote:
> On Tue, 8 Jan 2019 at 02:11, Laszlo Ersek  wrote:
>>
>> On 01/07/19 20:37, Ard Biesheuvel wrote:
>>> On Mon, 7 Jan 2019 at 20:21, Achin Gupta  wrote:
>>
 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.
>>
>> Yes, see PI 1.6, Vol2 ("DXE"), 5.1.2.1 "End of DXE Event".
>>
>> (I won't quote the spec here, as I could quote the entire section; all
>> of it is relevant here.)
>>
>> In my interpretation anyway, the MM infrastructure basically "trusts"
>> DXE until End-of-DXE is signaled. See also:
>> - 5.6 "DXE MM Ready to Lock Protocol",
>> - 4.6 "MM Ready to Lock Protocol",
>> in Vol4.
>>
>> The kind of "early distrust" that Achin describes up-thread may be
>> well-founded, and it might obviate the above event groups. I'm not sure.
> 
> I disagree. The whole point of standalone MM is to have parity with
> x86 in terms of having a separate execution context where platform
> specific services can reside. Even though DXE_SMM_DRIVER and
> MM_STANDALONE modules are dispatched in different ways, they should be
> able to be built from a shared source, and not signalling the EndOfDxe
> event is highly likely to cause more problems that it solves.
> 
> And actually, I think it is a valid security model to distinguish
> between before and after EndOfDxe, since EndOfDxe will be signalled
> before loading any third-party drivers, and so whatever has executed
> up to that point can be held to higher standards in terms of trust.

What you describe is absolutely *easier* to understand and to agree
with, so I'm naturally drawn to it.

I'm just pointing out -- sort of reasoning against myself! -- that Achin
wrote up-thread,

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

Through this, Achin seemed to imply that some SMM vulnerabilities had
occurred due to SMM being *capable* of reading *any* RAM (and MMIO too)
outside of SMRAM ("data sharing"); hence invalid pointer dereferences
(even just reads) could lead to really bad problems.

Then, I tried to fill the term "sandbox" with meaning -- i.e. MM would
be prevented from reading any DXE data (anything outside of MMRAM). This
looked sort of consistent with the extra restriction that standalone MM
code couldn't consume UEFI protocols even at init time.

And then I extrapolated: if MM can't trust DXE *at all*, then MM needs
no notification that, due to BDS reaching a specific point, MM can trust
DXE even *less* than before. There is no "less" than "not at all".

In short, I agree with you, I'm just trying to comprehend the "threat
model" (is that the right term?) behind Achin's story (AIUI).

Thanks!
Laszlo

>> The concept is novel to me (after having struggled for months in ~2015
>> to wrap my brain around traditional SMM in the first place), so I'm
>> having trouble at reasoning about standalone MM.
>>
> 
> I think that applies to all of us :-)
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Ard Biesheuvel]

On Tue, 8 Jan 2019 at 02:11, Laszlo Ersek  wrote:
>
> On 01/07/19 20:37, Ard Biesheuvel wrote:
> > On Mon, 7 Jan 2019 at 20:21, Achin Gupta  wrote:
>
> >> 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.
>
> Yes, see PI 1.6, Vol2 ("DXE"), 5.1.2.1 "End of DXE Event".
>
> (I won't quote the spec here, as I could quote the entire section; all
> of it is relevant here.)
>
> In my interpretation anyway, the MM infrastructure basically "trusts"
> DXE until End-of-DXE is signaled. See also:
> - 5.6 "DXE MM Ready to Lock Protocol",
> - 4.6 "MM Ready to Lock Protocol",
> in Vol4.
>
> The kind of "early distrust" that Achin describes up-thread may be
> well-founded, and it might obviate the above event groups. I'm not sure.

I disagree. The whole point of standalone MM is to have parity with
x86 in terms of having a separate execution context where platform
specific services can reside. Even though DXE_SMM_DRIVER and
MM_STANDALONE modules are dispatched in different ways, they should be
able to be built from a shared source, and not signalling the EndOfDxe
event is highly likely to cause more problems that it solves.

And actually, I think it is a valid security model to distinguish
between before and after EndOfDxe, since EndOfDxe will be signalled
before loading any third-party drivers, and so whatever has executed
up to that point can be held to higher standards in terms of trust.

> The concept is novel to me (after having struggled for months in ~2015
> to wrap my brain around traditional SMM in the first place), so I'm
> having trouble at reasoning about standalone MM.
>

I think that applies to all of us :-)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Laszlo Ersek]

On 01/07/19 20:37, Ard Biesheuvel wrote:
> On Mon, 7 Jan 2019 at 20:21, Achin Gupta  wrote:

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

Yes, see PI 1.6, Vol2 ("DXE"), 5.1.2.1 "End of DXE Event".

(I won't quote the spec here, as I could quote the entire section; all
of it is relevant here.)

In my interpretation anyway, the MM infrastructure basically "trusts"
DXE until End-of-DXE is signaled. See also:
- 5.6 "DXE MM Ready to Lock Protocol",
- 4.6 "MM Ready to Lock Protocol",
in Vol4.

The kind of "early distrust" that Achin describes up-thread may be
well-founded, and it might obviate the above event groups. I'm not sure.
The concept is novel to me (after having struggled for months in ~2015
to wrap my brain around traditional SMM in the first place), so I'm
having trouble at reasoning about standalone MM.

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Ard Biesheuvel]

On Mon, 7 Jan 2019 at 20:21, Achin Gupta  wrote:
>
> On Mon, Jan 07, 2019 at 07:55:36PM +0100, Ard Biesheuvel wrote:
> > On Mon, 7 Jan 2019 at 19:50, Achin Gupta  wrote:
> > >
> > > On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote:
> > > > On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek  wrote:
> > > > >
> > > > > On 01/04/19 12:57, Ard Biesheuvel wrote:
> > > > > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
> > > > > >>
> > > > > >> On 01/03/19 12:03, Ard Biesheuvel wrote:
> > > > > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja 
> > > > > >>>  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 
> > > > >  ---
> > > > >   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
> > > > > >> ,
> > > > > >> - and
> > > > > >> .
> > > > > >>
> > > > > >> 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
> > > > > , 

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

[Achin Gupta]

On Mon, Jan 07, 2019 at 07:55:36PM +0100, Ard Biesheuvel wrote:
> On Mon, 7 Jan 2019 at 19:50, Achin Gupta  wrote:
> >
> > On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote:
> > > On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek  wrote:
> > > >
> > > > On 01/04/19 12:57, Ard Biesheuvel wrote:
> > > > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
> > > > >>
> > > > >> On 01/03/19 12:03, Ard Biesheuvel wrote:
> > > > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja 
> > > > >>>  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 
> > > >  ---
> > > >   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
> > > > >> ,
> > > > >> - and
> > > > >> .
> > > > >>
> > > > >> 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
> > > > , 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
> > 

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

[Ard Biesheuvel]

On Mon, 7 Jan 2019 at 19:50, Achin Gupta  wrote:
>
> On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote:
> > On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek  wrote:
> > >
> > > On 01/04/19 12:57, Ard Biesheuvel wrote:
> > > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
> > > >>
> > > >> On 01/03/19 12:03, Ard Biesheuvel wrote:
> > > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  
> > > >>> 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 
> > >  ---
> > >   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
> > > >> ,
> > > >> - and
> > > >> .
> > > >>
> > > >> 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
> > > , 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 

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

[Achin Gupta]

On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote:
> On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek  wrote:
> >
> > On 01/04/19 12:57, Ard Biesheuvel wrote:
> > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
> > >>
> > >> On 01/03/19 12:03, Ard Biesheuvel wrote:
> > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  
> > >>> 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 
> >  ---
> >   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
> > >> ,
> > >> - and
> > >> .
> > >>
> > >> 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
> > , 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 

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

[Ard Biesheuvel]

On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek  wrote:
>
> On 01/04/19 12:57, Ard Biesheuvel wrote:
> > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
> >>
> >> On 01/03/19 12:03, Ard Biesheuvel wrote:
> >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  
> >>> 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 
>  ---
>   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
> >> ,
> >> - and
> >> .
> >>
> >> 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
> , for example?
>

Perhaps Achin can answer this, since he has been driving the spec side
of this? (and maintains StandaloneMmPkg)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Laszlo Ersek]

On 01/04/19 12:57, Ard Biesheuvel wrote:
> On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
>>
>> On 01/03/19 12:03, Ard Biesheuvel wrote:
>>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  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 
 ---
  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
>> ,
>> - and
>> .
>>
>> 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
, for example?

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Ard Biesheuvel]

On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek  wrote:
>
> On 01/03/19 12:03, Ard Biesheuvel wrote:
> > On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  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 
> >> ---
> >>  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
> ,
> - and
> .
>
> 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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Laszlo Ersek]

On 01/03/19 12:03, Ard Biesheuvel wrote:
> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  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 
>> ---
>>  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
,
- and
.

Not sure how that can be applied to Arm.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Ard Biesheuvel]

On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja  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 
> ---
>  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.

Remaining question is what to do with InSmm() ...


> diff --git a/MdePkg/Include/Library/StandaloneMmServicesTableLib.h 
> b/MdePkg/Include/Library/StandaloneMmServicesTableLib.h
> new file mode 100644
> index 000..3a27ac4
> --- /dev/null
> +++ b/MdePkg/Include/Library/StandaloneMmServicesTableLib.h
> @@ -0,0 +1,43 @@
> +/** @file
> +  Provides a service to retrieve a pointer to the Standalone MM Services 
> Table.
> +  Provides a InMm implementation for RUNTIME DXE drivers
> +
> +Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD 
> License
> +which accompanies this distribution.  The full text of the license may be 
> found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __MM_SERVICES_TABLE_LIB_H__
> +#define __MM_SERVICES_TABLE_LIB_H__
> +
> +#include 
> +#include 
> +
> +extern EFI_MM_SYSTEM_TABLE *gMmst;
> +
> +/**
> +  This function allows the caller to determine if the driver is executing in
> +  Standalone Management Mode(SMM).
> +
> +  This function returns TRUE if the driver is executing in SMM and FALSE if 
> the
> +  driver is not executing in SMM.
> +
> +  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
> +  @retval  FALSE The driver is not executing in Standalone Management Mode 
> (SMM).
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +InMm (
> +  VOID
> +  );
> +
> +#endif
> diff --git 
> a/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c 
> b/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
> new file mode 100644
> index 000..6f37cd8
> --- /dev/null
> +++ 
> b/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
> @@ -0,0 +1,39 @@
> +/** @file
> +  Standalone MM Services Table Library.
> +
> +  Copyright (c) 2018, ARM Limited. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD 
> License
> +  which accompanies this distribution.  The full text of the license may be 
> found at
> +  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +
> +EFI_MM_SYSTEM_TABLE *gMmst = NULL;
> +
> +/**
> +  This function allows the caller to determine if the driver is executing in
> +  Standalone Management Mode(SMM).
> +
> +  This function returns TRUE if the driver is executing in SMM and FALSE if 
> the
> +  driver is not executing in SMM.
> +
> +  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
> +  @retval  FALSE The driver is not executing in Standalone Management Mode 
> (SMM).
> +
> +**/
> +BOOLEAN
> +EFIAPI
> +InMm (
> +  VOID
> +  )
> +{
> +  return FALSE;
> +}
> diff --git 
> 

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

[Jagadeesh Ujja]

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

diff --git a/MdePkg/Include/Library/StandaloneMmServicesTableLib.h 
b/MdePkg/Include/Library/StandaloneMmServicesTableLib.h
new file mode 100644
index 000..3a27ac4
--- /dev/null
+++ b/MdePkg/Include/Library/StandaloneMmServicesTableLib.h
@@ -0,0 +1,43 @@
+/** @file
+  Provides a service to retrieve a pointer to the Standalone MM Services Table.
+  Provides a InMm implementation for RUNTIME DXE drivers
+
+Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __MM_SERVICES_TABLE_LIB_H__
+#define __MM_SERVICES_TABLE_LIB_H__
+
+#include 
+#include 
+
+extern EFI_MM_SYSTEM_TABLE *gMmst;
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Standalone Management Mode(SMM).
+
+  This function returns TRUE if the driver is executing in SMM and FALSE if the
+  driver is not executing in SMM.
+
+  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
+  @retval  FALSE The driver is not executing in Standalone Management Mode 
(SMM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  );
+
+#endif
diff --git 
a/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c 
b/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
new file mode 100644
index 000..6f37cd8
--- /dev/null
+++ b/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c
@@ -0,0 +1,39 @@
+/** @file
+  Standalone MM Services Table Library.
+
+  Copyright (c) 2018, ARM Limited. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+
+EFI_MM_SYSTEM_TABLE *gMmst = NULL;
+
+/**
+  This function allows the caller to determine if the driver is executing in
+  Standalone Management Mode(SMM).
+
+  This function returns TRUE if the driver is executing in SMM and FALSE if the
+  driver is not executing in SMM.
+
+  @retval  TRUE  The driver is executing in Standalone Management Mode (SMM).
+  @retval  FALSE The driver is not executing in Standalone Management Mode 
(SMM).
+
+**/
+BOOLEAN
+EFIAPI
+InMm (
+  VOID
+  )
+{
+  return FALSE;
+}
diff --git 
a/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf 
b/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
new file mode 100644
index 000..c94b605
--- /dev/null
+++ 
b/MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf
@@ -0,0 +1,36 @@
+## @file
+#  Provides StandaloneMmServicesTableLib.
+#
+#  Copyright (c) 2018, ARM Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions
+#  of the BSD License which accompanies this distribution.  The
+#  full text of the license may be found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = StandaloneMmServicesTableLib
+  FILE_GUID  = 8099cfbf-9564-4c9b-9052-e66b1da88930
+  MODULE_TYPE= DXE_RUNTIME_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  =