From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.68; helo=ma1-aaemail-dr-lapp02.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id EC761211DDA22 for ; Thu, 14 Mar 2019 11:45:55 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x2EIfXls060616; Thu, 14 Mar 2019 11:45:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=qwk64cfU1GtNwJrqkT9xS1gIHg2x5IRECmFygMO7s/o=; b=nrcStdt9zvDlY1sdWRjfrzO8iS1SJJhT85N5u6mIWoTZkmq6mgXNfD34oOaaZ7Cwmevk QhwOBhosuUtnVSnkyElB6SI4kXimE4jdvvelIPoLD0OjMXBdhrD4L5j0gYn/5nWmjI3O +z9D5pdj6Q2UMyFVZ7RP7SeC0/SmNgJMFAFNdpQi6QK9JHQL9BdDFTJhi7lkFBX6MYAV lb5+IkNDiikB7xEpbshpykyF7JsMAWmnkh+o91k4iuNwNefvrNDRlKrZXSmakY5nEcPI v2jl3PuHPMM6lx6ovOBpaTqTNzcDftAGarbrFZ0AzyRmW4dLVg06met1dUsn9ALTAyd9 Jw== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2r4b2412kw-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Mar 2019 11:45:53 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0POD008SKDGFZ051@mr2-mtap-s03.rno.apple.com>; Thu, 14 Mar 2019 11:45:52 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0POD00D00D92DA00@nwk-mmpp-sz13.apple.com>; Thu, 14 Mar 2019 11:45:52 -0700 (PDT) X-Va-A: X-Va-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-Va-E-CD: f8b4b3b2078dc7a6536015969534bade X-Va-R-CD: 852f78f4846e4fb7a7f50cd9fabf2a15 X-Va-CD: 0 X-Va-ID: db200785-82f2-43e6-975f-e599a7145ef5 X-V-A: X-V-T-CD: 13715775cfe6ed78bc954dbcb503dbb2 X-V-E-CD: f8b4b3b2078dc7a6536015969534bade X-V-R-CD: 852f78f4846e4fb7a7f50cd9fabf2a15 X-V-CD: 0 X-V-ID: 6dd98958-7e3c-4832-8f6c-2ec3db746bc2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-14_08:,, signatures=0 Received: from [17.226.41.73] (unknown [17.226.41.73]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0POD008OQDGFUB20@nwk-mmpp-sz13.apple.com>; Thu, 14 Mar 2019 11:45:51 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <660D5BB9-0F4F-4B53-8B99-FEFCAB66BD33@apple.com> Date: Thu, 14 Mar 2019 11:45:45 -0700 In-reply-to: Cc: "You, Benjamin" , "edk2-devel@lists.01.org" To: Laszlo Ersek References: X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-14_08:, , signatures=0 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy" X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 18:45:56 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > 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 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 > https://lists.01.org/mailman/listinfo/edk2-devel