Re: [coreboot] question on SMM

[Alexander Couzens]

On Fri, 30 Jun 2017 04:25:06 +0000
ron minnich  wrote:
> there's something I am certain I don't understand about SMM on intel
> chipsets.
>
> The question is pretty simple. Consider a system with a recent intel
> chipset and flash. Is there some special secret sauce that disables
> writing to flash unless in SMM and if so, what is it?

There is also a talk explaining it (without SMM_BWP).

https://media.ccc.de/v/31c3_-_6129_-_en_-_saal_2_-_201412282030_-_attacks_on...

question on SMM

[ron minnich]

Thanks for the good explanations.

So I have a question for you all. We've been doing some testing of
linux-as-ramstage. We've done a proof of concept that linux can set up the
SMM handler at 0xa0000, the relocate stub at 0x38000, run the relocate
stub, and have a working smm handler. The smm handler can trampoline to
64-bit mode and call the kernel, using existing mechanisms. So our SMM
handler, in this scenario, is a set of functions provided by the kernel,
not a binary blob. The result is a teeny tiny SMM handler and complete
elimination of the vendor-supplied SMM code.

There are lots of benefits. The SMM is no longer at a fixed location --
it's kind of ASLR for SMM code; there is very little code that runs in SMM;
and the SMM handlers we implement run in 64-bit mode with full memory
protections. The big one for me is that persistent firmware blobs are
reduced by one -- it's part of a goal to create an air gap between firmware
and kernel. Another part of this work is that we're going to discard
firmware-supplied ACPI tables and use ones supplied by the kernel.

I realize this is not a general approach. But for small, limited
configurations, such as OCP servers which come in a small number of
flavors, it's quite doable.

The only question that has been raised: are we losing an essential security
guarantee since flash is writeable in this kernel-based "SMM"? The big
question is whether we're opening up the possibility of firmware getting
changed, once the kernel is our "smm mode". Is there a reasonable
mitigation we could use in the SMM handler before we trampoline back up to
the kernel?

Thoughts on this are welcome.

ron

On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens  wrote:
> On Fri, 30 Jun 2017 04:25:06 +0000
> ron minnich  wrote:
> > there's something I am certain I don't understand about SMM on intel
> > chipsets.
> >
> > The question is pretty simple. Consider a system with a recent intel
> > chipset and flash. Is there some special secret sauce that disables
> > writing to flash unless in SMM and if so, what is it?
>
> There is also a talk explaining it (without SMM_BWP).
>
> https://media.ccc.de/v/31c3_-_6129_-_en_-_saal_2_-_201412282030_-_attacks_on...