UEFI Runtime Services

From owner-svn-doc-head@freebsd.org Tue Oct 25 03:19:51 2016 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20C69C20C41; Tue, 25 Oct 2016 03:19:51 +0000 (UTC) (envelope-from bjk@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D2A60F3A; Tue, 25 Oct 2016 03:19:50 +0000 (UTC) (envelope-from bjk@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u9P3JnDP054955; Tue, 25 Oct 2016 03:19:49 GMT (envelope-from bjk@FreeBSD.org) Received: (from bjk@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u9P3Jn0T054954; Tue, 25 Oct 2016 03:19:49 GMT (envelope-from bjk@FreeBSD.org) Message-Id: <201610250319.u9P3Jn0T054954@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bjk set sender to bjk@FreeBSD.org using -f From: Benjamin Kaduk Date: Tue, 25 Oct 2016 03:19:49 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r49571 - head/en_US.ISO8859-1/htdocs/news/status X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 03:19:51 -0000 Author: bjk Date: Tue Oct 25 03:19:49 2016 New Revision: 49571 URL: https://svnweb.freebsd.org/changeset/doc/49571 Log: Add entry on EFI Runtime Services from kib Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml Mon Oct 24 20:22:54 2016 (r49570) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml Tue Oct 25 03:19:49 2016 (r49571) @@ -1424,4 +1424,105 @@ The FreeBSD Foundation + + + UEFI Runtime Services + + + + + Konstantin + Belousov + + kib@FreeBSD.org + + + + +

UEFI (Unified Extensible Firmware Interface) specifies two + kinds of services for use by operating systems. Boot Services are + designed for OS loaders to be able to load and initialize kernels, + while Runtime Services are supposed to be used by the kernels + during regular system operations. The boot and runtime phases are + explicitely separated. During boot, when loaders are executed, + the machine configuration is owned by UEFI. During runtime, the + kernel manages the configuration, but needs to inform the firmware + about any changes that are made.

+ +

The model of split boot/runtime configuration makes assumptions + about the OS architecture that do not quite apply to the existing + &os; codebase. For instance, the firmware notification of the + future runtime configuration must be done while the loader is + effectively still in control. In technical terms, the + SetVirtualAddressMap() call must be made with the 1:1 + physical:virtual mapping on amd64 systems, which for &os; means + that the call can be only issued by the loader. But the loader + needs to know intimate details of the kernel address map to + provide the requested information. This creates a new, + unfortunate, coupling between loader and kernel.

+ +

Reading the publicly available information about the MS + Windows boot process explained the UEFI control transfer + model. The Windows loader constructs the address map for the + kernel, and with such a division of work the UEFI model is + reasonable. The &os; kernel constructs its own address + space, only relying on a minimal map constructed by the + loader, which is enough for the pmap subsystem to bootstrap + itself and then to perform machine initialization in common + code.

+ +

Initial experiments with enabling runtime services were + centered around utilizing the direct address map (DMAP) on + amd64, which currently always exists and linearly maps at + least the lower 4G of physical addresses at some KVA location. + It was supposed that kernel would export the DMAP details like + linear base and guaranteed size for loader from its ELF image, + and provide the needed overflow map if the DMAP cannot + completely serve. Unfortunately, two show-stopper bugs were + discovered with this approach.

+ +

First, EDK-based firmwares apparently require that the + runtime mapping exists simultaneously with the physical + mapping for the SetVirtualAddressMap() call. Second, there + were references from other open-source projects mentioning + that some firmwares required the presence of the physical + mapping during runtime call. Effectively, this forces both + kernel and loader to provide both mappings for all runtime + calls.

+ +

With such restrictions, informing the firmware about the + details of the kernel address space only adds useless work. + We could just as easily establish the 1:1 physical mapping + during runtime and get rid of SetVirtualAddressMap() entirely. + This approach was coded and the kernel interface to access + runtime services is based on it.

+ +

During the development, in particular, when trying to make + the loader modifications, it was quickly realized that there + were no fault-reporting facilities in loader.efi. Machine + exceptions resulted in a silent hang. Curiosly, in such a + situation the Intel firmware outputs the error code over the + serial port on 115200/8/1 settings, regardless of UEFI console + configuration, which was discovered by accident. + Unfortunately, the error code alone is not enough to diagnose + most problems.

+ +

A primitive fault reporter was written for loader.efi on + amd64, which intercepts exceptions from the firmware IDT and + dumps the machine state to the loader console. Due to + complexity of the interception and possible bugs which might + do more harm than good there, the dumper is only activated by + explicit administrator action.

+ +

Note that the described work only provides the kernel + interfaces to make calling the EFI runtime services as easy as + calling a regular C function. User-visible feature + development making use of the new interfaces is being + performed right now.

+ + + + The FreeBSD Foundation + +