Re: [coreboot] question on SMM

[Nico Huber]

On 30.06.2017 19: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.
>
> 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.

Sounds really doable, but I'm a bit confused here, maybe because I
didn't look at SMM handlers for some time. Did you evaluate if you
need SMM at all? I just thought if you add board specific code to
the kernel, why would you have to do anything in SMM? In the case
of ACPI, most interrupts are already directly routed to the kernel
(as SCI instead of SMI).

Also, if you are going to reimplement the vendor ACPI tables, why
not write kernel-native drivers? ACPI is just a weird OS-independent
way of writing drivers.

Nico

question on SMM

[ron minnich]

On Fri, Jun 30, 2017 at 4:28 PM Nico Huber  wrote:
> Sounds really doable, but I'm a bit confused here, maybe because I
> didn't look at SMM handlers for some time. Did you evaluate if you
> need SMM at all? I just thought if you add board specific code to
> the kernel, why would you have to do anything in SMM? In the case
> of ACPI, most interrupts are already directly routed to the kernel
> (as SCI instead of SMI).

That would be optimal -- just turn it off. We're seeing a problem with
linux startup, while booting no smm enabled, where Linux really wants to do
that OSL nonsense via SMI for ACPI. Can we really configure hardware such
that an SMI is impossible, and will Linux continue to work if we do?

I like your idea a lot -- just do whatever it takes to make SMM interrupts
turn into normal SCI -- I just don't know for sure it's possible to make it
happen. But I'll look.

The remaining problem is the "security" offered by having an SMI gatekeeper
on the flash. Given the history of such "security" approaches, I suspect
we're better off without them. BUT, there is concern that if we don't use
these approaches, there are scenarios where flash gets written by the wrong
people.
> Also, if you are going to reimplement the vendor ACPI tables, why
> not write kernel-native drivers? ACPI is just a weird OS-independent
> way of writing drivers.

I agree with you here, but we can only kill one dragon at a time.

We ran supercomputers at LANL for years, up until 2010 or so, with no SMM
and ACPI and all was well. I've never quite figured out what problem SMI
and ACPI solved that could not have been solved better in other ways.

ron