[coreboot] question on SMM

[Marc Jones]

On Fri, Jun 30, 2017 at 11:47 AM ron minnich <rminnich at gmail.com> 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
> the kernel?
>
> Thoughts on this are welcome.
>
>
Cool, Seems like you could leverage the coreboot SMM handler rmodule. Aaron
probably has some comments on this.
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?

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.

Marc







> ron
>
> On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens <lynxis at fe80.eu> wrote:
>
>> On Fri, 30 Jun 2017 04:25:06 +0000
>> ron minnich <rminnich at 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).
>>
>>
>> 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
>>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
http://marcjonesconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170630/8fd310db/attachment.html>