[coreboot] question on SMM

[Nico Huber]

On 01.07.2017 02:08, ron minnich wrote:
> On Fri, Jun 30, 2017 at 4:28 PM Nico Huber <nico.h at gmx.de> 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 hope so. I would expect that you can disable all SMIs by simply set-
ting the whole SMI_EN register 0. Some of them can't be routed to SCIs.
Wouldn't expect that you need them, though.

Regarding OSL, does it mean OS Load? It's not in the standard but im-
mediately reminded me of the APMC mechanism to switch from SMI to SCI.
Hope that does the trick: SMI_CMD in the FADT should be set to zero and
you'd have to set SCI_EN manually, I suppose. Spec says about SMI_CMD:

    System port address of the SMI Command Port. During ACPI
    OS initialization, OSPM can determine that the ACPI
    hardware registers are owned by SMI (by way of the SCI_EN
    bit), in which case the ACPI OS issues the ACPI_ENABLE
    command to the SMI_CMD port. The SCI_EN bit effectively
    tracks the ownership of the ACPI hardware registers. OSPM
    issues commands to the SMI_CMD port synchronously from
    the boot processor. This field is reserved and must be zero on
    system that does not support System Management mode.

Other than that, there is the HW-Reduced ACPI Model that doesn't expect
SMM. But I don't know the implications of running that on a system that
isn't designed for it. Might be worth looking into it (ACPI 6.1 Chapters
3.11.1 and 4.1). It's mentioned as being useful for legacy free systems.

> 
> 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.

What usually is done is either having a trusted, write-protected part
of the flash that can verify the remaining parts, or enough code in the
flash that can load updates on its own (or a combination of both, write
updates in the rw part first and let the ro part overwrite itself after
verification). You would write-protect (trusted parts of) the flash
before starting the fully-fledged, less trusted OS.

> 
>> 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.

Well, beside fixing issues that ACPI brings with itself, there is a
valid idea underlying: Having an OS-independent way to write board-
specific OS drivers. I would expect the lists of board-specific quirks
(laptops mostly) in Linux to explode without ACPI. But that's just a
feeling...

Much of the SMM/ACPI craft is about legacy compatibility, though. I
guess that's what the HW-reduced model tries to fix.

Nico