On 30-Jun-17 10:46, 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.
How do you do the relocation on a system where the vendor bios has
already relocated the SMM_BASE (i.e. when not running on a machine you
have the bios source code for)?
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.
SMM was never a blob on coreboot.
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?
You could add the security that your bios implemented back into your
kernel SMM handler ;-) Look at the open source SMM handler in coreboot
for how that is done.
Thoughts on this are welcome.
ron
On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens <[email protected]
<mailto:[email protected]>> wrote:
On Fri, 30 Jun 2017 04:25:06 +0000
ron minnich <[email protected] <mailto:[email protected]>> 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_uefi_security_inspired_by_darth_venamis_s_misery_and_speed_racer_-_rafal_wojtczuk_-_corey_kallenberg
Stefan
--
coreboot mailing list: [email protected]
https://mail.coreboot.org/mailman/listinfo/coreboot
