On 01.07.2017 02:08, ron minnich wrote:
On Fri, Jun 30, 2017 at 4:28 PM Nico Huber
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
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
Much of the SMM/ACPI craft is about legacy compatibility, though. I
guess that's what the HW-reduced model tries to fix.