[staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy"

[staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy"

[You, Benjamin]

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/

Thanks,


-        ben

Re: [staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy"

[Laszlo Ersek]

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


My apologies if I've missed details, or if my comments are otherwise
misguided.

Thanks
Laszlo

Re: [staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy"

[Andrew Fish]

> On Mar 14, 2019, at 7:28 AM, Laszlo Ersek <lersek@redhat.com> 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 out well in the end. My crack commentt was even in the primitive security awareness of my younger days. Anything that helps move code out of SMM is a good thing.

In the old days the only safe way to do SMM was to drop all the cores into SMM (PCI config access was via IO port 0xCF8/0xCFC), but that requires a big lock that scales very poorly when you have a lot of cores dropping into SMM (one of the cores could have been doing a cache flush and take a while to drop into SMM). So then folks try and cheat and send a directed SMI, but that yanks a single core away from the OS. Having a CPU just go away for a while is kind of a really bad thing for an OS. Thus I'd say while I share some of your concerns, anything that moves large blocks of code out of SMM is a net win for the platform. 

Thanks,

Andrew Fish

PS I was looking at the foils too, and my big question is why did they have a slide that was a picture of Ron "Cadillac Margarita" Story? 

> 
> My apologies if I've missed details, or if my comments are otherwise
> misguided.
> 
> Thanks
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>