> On Mar 14, 2019, at 7:28 AM, Laszlo Ersek <ler...@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>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
