You can reduce the window of time that the flash is writable by setting
the PRR registers and FLOCKDN bits before moving out of the bootblock --
this prevents even SMM from being able to write to the protected regions of
the flash. If someone can get code execution in the bootblock or
during S3 resume (Dark Jedi/Thunderstrike 2), they might have a window
of opportunity to overwrite the flash.
Handling upgrades requires that the bootblock consider if it should
lock the configuration, which does introduce a dependency on outside
data and would require additional consideration.
On Fri, Jun 30, 2017 at 05:46:19PM +0000, ron minnich wrote:
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
Thoughts on this are welcome.
On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens <lynxis(a)fe80.eu> wrote:
> On Fri, 30 Jun 2017 04:25:06 +0000
> ron minnich <rminnich(a)gmail.com> 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).