On 01.07.2017 02:08, ron minnich wrote:
On Fri, Jun 30, 2017 at 4:28 PM Nico Huber nico.h@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
-
Nico Huber