<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 30, 2017 at 11:47 AM ron minnich <<a href="mailto:rminnich@gmail.com">rminnich@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the good explanations. <div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>Thoughts on this are welcome.</div></div><div dir="ltr"><div><br></div></div></blockquote><div><br></div><div>Cool, Seems like you could leverage the coreboot SMM handler rmodule. Aaron probably has some comments on this. </div><div>As for the trampoline, are you exiting SMM to the kernel to handle the event and then returning with a second software SMI?  If that is the case, the kernel wouldn't be able to write flash. How are you handling core synching? Is the trampoline only for the BSP?</div><div><br></div><div>I'm uncertain about having any more attack surface if the kernel owns SMM or not. Just seems like which side you want to trust.</div><div><br></div><div>Marc</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>ron</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens <<a href="mailto:lynxis@fe80.eu" target="_blank">lynxis@fe80.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 30 Jun 2017 04:25:06 +0000<br>
ron minnich <<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>> wrote:<br>
<br>
> there's something I am certain I don't understand about SMM on</blockquote></div></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> intel<br>
> chipsets.<br>
><br>
> The question is pretty simple. Consider a system with a recent intel<br>
> chipset and flash. Is there some special secret sauce that disables<br>
> writing to flash unless in SMM and if so, what is it?<br>
<br>
There is also a talk explaining it (without SMM_BWP).<br>
<br>
<a href="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" rel="noreferrer" target="_blank">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</a><br>
</blockquote></div>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mailman/listinfo/coreboot</a></blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><a href="http://marcjonesconsulting.com">http://marcjonesconsulting.com</a></div></div>