> On Mar 14, 2019, at 7:28 AM, Laszlo Ersek wrote:
>
> On 03/14/19 09:46, You, Benjamin wrote:
>> Hi,
>>
>>
>>
>> A new feature branch "PRMCaseStudy" is being created in edk2-staging.
>>
>>
>> Platform Runtime Mechanism (PRM) is an architecture for ACPI codes to call
>> into UEFI BIOS's Runtime Services at OS runtime. Traditionally, ACPI codes
>> call into BIOS through the invocation of Software SMIs. When applicable, PRM
>> provides an alternative for ACPI codes to invoke UEFI Runtime Services,
>> which runs in OS kernel space, without invoking SMM.
>>
>> This package contains proof-of-concept codes that implement the ideas of PRM.
>>
>> Resources:
>>
>> - PRM introduction: https://www.opencompute.org/events/past-summits (Please
>> search for "UEFI Implementation Intel(r) Xeon Based OCP Platform" in the
>> webpage, which lists pointers to video and presentation that introduce the
>> concept of PRM)
>> - TianoCore: http://www.tianocore.org
>> - UEFI Forum: https://uefi.org/
>
> (I've read the slides now. Hopefully I understand them sufficiently for
> making reasonable comments below.)
>
> While this feature looks exciting and nice from a technical standpoint,
> I think it would have a bad effect on operating system drivers, in
> particular in open source operating systems.
>
> Currently, as far as I know, the best quality OS hw drivers are those
> that (a) manipulate hardware directly, and (b) are developed against
> open hardware specs.
>
> In comparison, this feature promotes a generic OS->firmware call
> interface. It allows platform vendors to liberally define UEFI runtime
> services, and OS-level drivers to call those platform-specific UEFI
> runtime services through semi-standardized ACPI methods.
>
> As a result, more and more OS hw drivers (especially for platform
> hardware) would be written on top of ACPI, and not on top of hardware
> access / hardware specs. I don't think that ACPI-based OS drivers for
> platform hardware are a bad thing; I think that making that kind of
> driver development *too easy* is a bad thing. Here's why:
>
> - every such OS driver is harder to develop & debug for the OS
> developer, because there's another layer of software between them and
> the hardware that they cannot change, and can debug only with difficulties
>
> - if the semi-standardized ACPI interfaces are too heavy-weight or too
> coarse-grained, then they might not integrate well into the driver
> framework of an OS. This can lead to bad performance and/or missing
> features.
>
> - the *easy* availability of such a runtime OS->firmware interface will
> tempt hardware vendors to cut corners and add platform hacks to e.g. PCI
> Express or USB devices, or even to implement devices that should be PCIE
> or USB in the first place as platform devices. We've already seen too
> much of that mess. Devices with platform hacks, and platform devices,o
> are very hard to isolate and to use from virtual machines (as assigned
> (aka "passthrough") devices), for example. But even without
> virtualization, the same kind of isolation may be necessary for hw
> drivers implemented in userspace.
>
> I'm totally a fan of ACPI (over DT, e.g.) for devices that *must* be
> platform devices. I'm very much not a fan of platform devices themselves.
>
> In summary:
>
> The runtime involvement of firmware should be minimized. The PRM
> approach seems to make that problem *worse* however, by widening the
> firmware's runtime role, through side-stepping the current problems of SMM.
>
Laszlo,
I understand your concerns, but I think the reality today for OS/Firmware
interactions that are not UEFI Spec Runtime services are currently implemented
in ACPI, and anything you can't do in ACPI ASL ends up in either an EC
(Embedded Controller) or SMM. There seems to be a trend to put more and more
features into SMM, especially on server. I recently saw a server code base
that had a SMM memory region that defaulted to 256 MiB.
Writing a buch of platform features in SMM that has more privilege than the OS
seems to be a security disaster waiting to happen. It looks like the PRM
(Protected Runtime Mechanism) is a hybrid of the UEFI runtime model and ACPI.
The most interesting statement is PRM runs Ring-0, in kernel driver context,
and uses ASL to access hardware. Given all that it seems like it would be a lot
easier to debug PRM code vs. SMM code. Also hopefully having the code tied to
ACPI hardware access mechanisms would make it hard to move things into PRM that
should be really done with an OS driver. I also think going forward it is going
to be important to be able to disambiguate between UEFI Runtime and PRM
drivers.
As you know I'm the one always pointing out how complex it is to write EFI
Runtime drivers so I'm not really pushing for an expansion of the role of EFI
at OS runtime. I coined the term a long time ago that SMM was crack as the 1st
time you use it fells OK, but things don't turn
