27 or Anniversary.Next^12, AI, Runtime

Anniversary

True to form, today is my work anniversary. I started Intel on February 24, 1997 This post also builds on my last posting in this vein http://vzimmer.blogspot.com/2023/02/26-or-anniversarynext11-and-wisdom-of.html. At this point I have spent more than half of my life on this planet at this single company.  

Since the last posting I've been back to the office daily, sometimes visiting the Crossroads for lunch, where I had my first sighting of a Cyber Truck.

I'd often work through lunch and eat from the local self-serve facilities but the pickings have been slim. So slim that even a 2-month-expired tuna sandwich was eaten by someone.

 I last took a sabbatical in 2011 where I smashed up my arm on the 2nd day and ended up w/ 2 surgeries. I still recall the one-handed typing away at the ITJ articles https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf that appeared later that year.  Typically sabbaticals expire but with the strangeness of COVID there were extensions that turned into a revised evergreen policy where sabbaticals no longer expire.  Regrettably, though, one stops accruing time after reaching 16 years. Looks like I need to pull the trigger on at least one month in the upcoming year, viz.,

 

Beyond cyber trucks, old sandwiches, and sabbaticals, the last year has seen a lot of energy around AI. Even the University of Washington lecture series has been dominated by this topic. An interesting talk from Meta was included in https://www.ece.uw.edu/news-events/lytle-lecture-series/ with slides https://www.ece.uw.edu/wp-content/uploads/2024/01/lecun-20240124-uw-lyttle.pdf and a recording https://www.youtube.com/watch?v=d_bdU3LsLzE. You can catch me at 6:36 on LHS of the screen

It's always interesting to be there in person. One comment that intrigued me was a comment from Yann LeCun about the Metaverse build out and GPU procurement. I cannot recall if it was on-tape or off-the-record so I've avoid going further than that.

This talk was at the Lyceum HUB but all of the other talks were across the street.

Another interesting talk https://www.cs.washington.edu/events/colloquia/details?id=3310 was from Fei-Fei Li of Stanford and ImageNet https://ieeexplore.ieee.org/document/5206848 fame.

This was near the comp sci building

LeCun's and Li's talks were like Taylor-Swift-concert-crowds but for techies. Nice to see these thought leaders share their insights and experience in person. 

Google Waymo was also in the mix with a talk https://tcat.cs.washington.edu/events/taskar-center-memorial-distinguished-lecture/ on the challenges of autonomous driving and AI https://www.youtube.com/watch?v=pK5ChzMsfE0

So let's pivot from AI lectures to a topic closer to home, namely firmware runtime. I chose this topic since one of the most popular posts is on this blog series was UEFI variable runtime http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html. I suspect this stems from the fact that most folks have interactions during life of platform at runtime. In our quest for 0-second boot this makes even more sense. 

Regarding how firmware is exposed to the operating system, and thus ultimately the user, at runtime, there are various modalities. 

These include:

• Static info tables
• Advanced Configuration and Power Interface (ACPI)
• Flattened Device Tree (FDT)
• Interpreter bytecode
• ACPI AML interpreter
• UEFI EBC sandbox
• x86 VDM for video int10h calls
• Native code runtime
• UEFI runtime
• Power9 OPAL
• Platform Runtime Mechanism (PRM)
• Opaque host modes - synchronous and asynchronous activations

• SMI(SMM)- x64
• SMC(TrustZone)- ARM
• Trap(Machine Mode) - RISC-V

These are all for the host firmware, or firmware running on the main application processor/core.

There is also device firmware running in the SOC.

In addition, at the platform level, the host can signal 'non-host' such as an Embedded Controller (EC) on client and Baseboard Management Controller (BMC) on server.

Below shows some of the latter 

 

    

 from https://link.springer.com/book/10.1007/978-1-4842-7939-7.

A lot of the flows are blended. For example, some of the descriptions of ACPI and SMI for errors described in https://cdrdv2.intel.com/v1/dl/getContent/671067 but the paper is light on ACPI.

Regrettably the collection at https://www.amazon.com/stores/Vincent-Zimmer/author/B002I6IW4A is pretty spare on ACPI, too, although https://link.springer.com/book/10.1007/978-1-4842-7974-8 covers construction and design in the case studies.

A curation of ACPI material can be found in the following:

Public documents on ACPI

2022

Intro to ACPI from ACPI spec

https://uefi.org/specs/ACPI/6.5/01_Introduction.html

2019 

ACPI tutorial

https://acpica.org/sites/acpica/files/asl_tutorial_v20190625.pdf 

2013

ACPI and UEFI

https://cdrdv2.intel.com/v1/dl/getContent/671067 

APEI and UEFI

ACPI overview https://www.intel.com/content/dam/www/public/us/en/documents/research/2009-vol13-iss-1-intel-technology-journal.pdf

2009

ACPI and SMM

https://link.springer.com/article/10.1007/s11416-009-0138-0 

2006

ACPI attacks

https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Heasman.pdf 

2004

ACPI HOWTO

https://tldp.org/HOWTO/pdf/ACPI-HOWTO.pdf

2003

IA64 book, including UEFI and ACPI chapter

https://www.amazon.com/Itanium-Architecture-Programmers-Understanding-Processors/dp/0131013726

 

2001

ACPI Book

https://dl.acm.org/doi/book/10.5555/940719 

1997 

ACPI implementation guide

https://www.baldwin.cx/~phoenix/reference/docs/acpi_impguide.pdf 

1996 for first spec - full history in 
https://en.wikipedia.org/wiki/ACPI 

 

A colleague suggested that I should have spent more time in the books writing about ACPI since he spends his time debugging issues on Windows and can quote many instances of poor or misunderstood ACPI constructions. I also chronicled in the past my exchange https://vzimmer.blogspot.com/2018/ with the Linux kernel leadership on the topic. 

A lot of people grouse about UEFI and ACPI when in fact it isn't the standard they are critiquing but instead the implementation.  Namely, it's often a confusion between interface and implementation. 

For example, on topics like the firmware support package (FSP), I hear complaints. I often offer the following dichotomy there:

    Consumer (caller)

    Interface (specification)

    Producer (implementation)

You can find examples of using FSP (consumer/caller) with EDKII 

https://www.intel.com/content/www/us/en/content-details/671038/a-tour-beyond-bios-using-the-intel-firmware-support-package-2-0-with-edk-ii.html or coreboot https://link.springer.com/chapter/10.1007/978-1-4842-0070-4_4. The interface itself is defined at https://github.com/intel/fsp/wiki, and one way of building (producer/implementation)

https://cdrdv2-public.intel.com/671296/a-tour-beyond-bios-creating-the-intel-firmware-support-package-with-the-efi-developer-kit-ii-fsp2-0.pdf.  As such, there are 3 layers.

Sometimes people grouse about FSP when in fact it's the implementation, not the API. And it has been a long run on FSP. The Intel IOTG folks kicked it off in 2010 and then Jiming and I conspired to have a working group that I've lead/co-lead since 2014 on the same with various other co-leads and collaborators along the way. Some of the outputs of that collaboration that record Maurice, Ravi and Jiming details can be found in the '15 book https://link.springer.com/book/10.1007/978-1-4842-0070-4, too. Maurice is now doing great things in fw at MS and Jiming at AMZN, resp., AFAIK. One of my key contributions in those 2013/2014 days was teasing out the FSP spec which was originally an amalgam of silicon details and API's into a couplet of docs, namely the main interface spec, the FSP EAS, and the respective SOC integration guides, such as can be found today in https://www.intel.com/fsp and in https://www.github.com/intel/FSP, respectively. This allowed for creating class drivers for FSP in the various platform code (e.g., coreboot and EDKII at the time) and abstracting SOC specifics. And I should forget how the decade+ of cross-group collaboration allowed for scaling FSP's from embedded to both mainstream client and servers, as demonstrated by the rich postings on Github. It's not a perfect split between EAS and integration guide, though, but as we've struggled with the 2001 Intel Framework API's and 2006+ UEFI PI spec interfaces, building that 'firmware socket' set of abstractions is tough given the variability of silicon and products over time.

Same with UEFI.  The interface is at https://uefi.org/specifications. Two implementations can be found at https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Core/Dxe and https://github.com/u-boot/u-boot/tree/master/lib/efi, respectively. Most folks complain about the EDKII implementation when they invoke 'UEFI is broken', I feel. This reminds me of the sentiment that some person with the handle of 'the_panopticon' mentioned in https://news.ycombinator.com/item?id=39481434. 

So back to ACPI. The evolution of ACPI in the did-90's predates late 90's EFI. EFI started as a sample and then the Tiano project with EDK and then EDKII subsumed Framework/PI and EFI/UEFI but not the ACPI specification. As such, no modularization of ACPI from the beginning because of Conway's Law (i.e., the folks who owned the UEFI spec and its reference implementation didn't own the ACPI spec for the first nearly 2 decades). In fact a lot of the ACPI table construction on the Intel platforms was derived was the DaVinci/Kittyhawk clean-room C BIOS that pre-dated Tiano in that hotbed of late 90's BIOS innovation called DuPont, WA Intel site. This model of static tables differs from the ARM ecosystem which does dynamic table generation since they started much later on the journey and had a single-team/Linaro view of entering standards-based firmware.

An advantage of dynamic table generation is flexibility but a downside is that it is harder to do attestation since the table fields are not known at build time. Even build time calculations, though, are aggravated by patching. So in practice it is not really done, just like a lot of configuration and PCR[1] content not really be reconstructed for some attestation / verifier flows.

Thinking about these taxonomies of firmware, from SAL+BIOS to Kittyhawk to ACSFL to EDK to EDKII to slim bootloader to coreboot to.... I realize that I might have the dubious honor of having worked on the broadest variety of host firmware at my employer.

Time marches on. In mentioning DaVinci/Kittyhawk workstation BIOS, I realize that my colleagues on that late 90's adventure have largely left the company, from retirement to downsizing to becoming execs at other tech shops (e.g., MS). Similar to the thinning of the crowd of others, such as even my 2015 colleagues from https://www.usenix.org/conference/woot15/workshop-program/presentation/bazhaniuk who have all left for startups (e.g., Eclypsium) or retirement or other big tech (e.g., Amazon). Well, given those statistics and chaos in tech, this might by be my last Next^* blog. Even if it is, though, I have enjoyed the run and people I've met along the way. Hopefully I have re-payed my employer's and colleagues trust with sufficient contributions these last 27 years.  

Cheers

another meta-blog, no runtime, and a taste of Rust

I hate to blog about blogs, but I wanted to mention https://www.jsnover.com/blog/2011/10/16/on-becoming-a-senior-technical-individual-contributor/#more-49 and https://www.jsnover.com/blog/2011/12/24/focus-on-reality/#more-137, especially the quotation  “My job is to ship the best ideas not come up with them“. This quotation follows the sentiment of http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html where I noted that invention is just a part of innovation, where innovation is delivering on an idea to the market. I enjoy this type of post, including more recent ones like https://blog.jessfraz.com/post/defining-a-distinguished-engineer/.

Speaking of 'shipping' things, one area of pain has been the support of UEFI run time variables, especially honoring the semantic of 'success means durably stored' and authenticated variables means 'no bypass of the SetVariable API to the SPI NOR storage,' as described in our design material https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII_V2.pdf. Given those complexities, I am happy to see efforts toward having a UEFI conformant platform elide support for certain run time services. From https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

Specifically the EFI_RT_SUPPORTED_SET_VARIABLE. This work was driven by the U-boot community implementing UEFI https://github.com/u-boot/u-boot/blob/master/doc/README.uefi since having a separate, isolated persistent storage if difficult, especially on 'single NAND' devices, for which many U-Boot devices can be found. In the future this could be the extended to a broad class of systems wherein the OS could elect to 'stage' UEFI variable writes during the pre-OS, such as saving to EFI system partition during OS run time and then setting on a subsequent boot prior to Exit Boot Services, in lieu of today's run time accesses. Some people refer to this as double-clutching.

This approach follows the existing UEFI PI Threat model https://members.uefi.org/learning_center/presentationsandvideos/Intel-UEFI-ThreatModel.pdf where the more secure environment is in the early boot. This is often referred to 'temporal isolation.' We historically considered all of the OEM code (SEC, PEI, DXE) to be trustworthy, but option ROM’s, OS loader, and the OS kernel to be potentially hostile. As such, having the boot service time manage the write is easier since the UEFI PI implementation manages the hardware. Although http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html is historically the most accessed entry on this blog, I'd be happy to see the above UEFI 2.8 capability make that blog posting moot.

On the topic of isolation, EndOfDxe event is the last point at which only OEM code runs. Afterward, many more parties run on the platform. For pre-OS isolation from 3rd party hardware devices we have https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf. And for isolation of pre-OS host agents we have defense in depth among ring 0 UEFI and DXE with   https://legacy.gitbook.com/book/edk2-docs/a-tour-beyond-bios-mitigate-buffer-overflow-in-ue/details and other options like pushing your PI implementation ring -1

https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Launching_VMM_in_EFI_Developer_Kit_II_0.pdf.  

In general eliding the UEFI runtime or isolating existing 3rd party binaries present challenges with compatibility for the existing catalog of .efi images generated since the late 90's. You cannot easily apply NX to .efi images that combine code and data sections, or to images that implement their own image loaders (i.e., turning a data page into a code executable). As such, UEFI and the existing code is now a 20 year compatibility surface. I was reminded by the power and challenges of binary compatibility when reading 

https://www.amazon.com/Open-Compaq-Domination-Helped-Computing/dp/B00EZB9UGK. 

Beyond isolation, the fashionable idea in the air right now is to re-write a bunch of stuff in Rust https://firmwaresecurity.com/2017/11/05/biors-bios-implementation-in-rust-language/, but that doesn’t handle the existing catalog of potentially errant or malicious native code objects out in the market. The nice part of language based security (LBS) approaches like Rust, though, is that existing C artifacts can incrementally be migrated to Rust. And Rust seems to have the mind share momentum, with representative OS https://www.tockos.org/assets/papers/rust-kernel-apsys2017.pdf ports https://doc.redox-os.org/book/ in hand. And Hacker news reminded me of other advantages as I type up this blog https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/ https://kkimdev.github.io/posts/2019/04/22/Rust-Compile-Time-Memory-Safety.html.

32 versus 64 bit and measuring UEFI Secure Boot

This blog begins with a discussion of the execution mode of the pre-operating system (OS) and the operating system run time (RT).   This is a question that comes up often, so I wanted to given some overview and history.

32v64 - The OS view of the world
We'll being with the OS-visible portion of the pre-OS, or the UEFI boot services (BS) environment.  For today's 64-bit (aka x64) operating systems, you need a 64-bit kernel to be booted from 64-bit UEFI firmware.  Or BS and RT execution modes need to match the kernel execution mode.  Similarly, a 32-bit OS kernel needs a 32-bit RT and 32-bit BS.  For example, x64 (aka x86-64, EM64T, AMD64, Intel64....) Ubuntu or Windows8 need to have x64 UEFI.

On this point UEFI differs from 16-bit PC/AT BIOS where you can boot 16, 32 or 64-bit kernels.  In 1982, BIOS was 16-bit, as was Microsoft DOS.  The I/O subsystem of DOS was the BIOS, so the DOS run time calling into the 16-bit BIOS int-calls worked out well.   DOS was single-threaded, BIOS calls are blocking, and everyone was happy.  This worked through Windows3.1 where DOS was still effectively the kernel.  The tension in this model appeared with 32-bit OS's where the kernel would 'thunk' or make down-calls into BIOS when necessary, alongside the 32-bit native driver model with VxD's.   With NT and beyond, though, the kernel would have native drivers such that the BIOS was only used for booting.  Same story for Linux with its pure native drivers.

And on the point of booting, the first stage OS loader would typically stay in 16-bit mode in order to read the kernel from disk or network using 16-bit BIOS calls.  Then the kernel would trampoline into 32-bit mode in order to run the native OS kernel.  When x64 came on the scene in the mid-2000's, this trampoline process was extended to go from 16-to-32-to-64 bit mode.   

The notable point on PC/AT BIOS and OS run times today is that modern OS kernels do not invoke 16-bit services after the initial loader.   This is distinct from EFI/UEFI with its 'runtime' (RT) services which are by-design intended for OS kernel invocation.

Specifically, UEFI, on the other hand, took a different path.  The original EFI 1.02 specification in 1999 had an IA32 (aka x86) binding that was 32-bit only.  EFI antedated the relase of x64.  EFI1.02 continued having only the IA32 binding.  When x64 became public, it was still prior to 2006 and the standardization of EFI as UEFI.  Intel owned the EFI specification at the time and pondered how to address support of x64.  One side of the EFI house advocated today's behavior where the firmware Instruction Set Architecture (ISA) mode == kernel ISA mode, whereas a smaller group was in the camp of a modal solution.  

Enter the '2-headed firmware.'   The idea of the firmware having two modes or 'heads' was to forever keep EFI as 32-bit and having the ability for a 32-bit or 64-bit set of run time services to be published from the firmware for the kernel (32 or 64) to call.'  

The requirement for the kernel to match the firmware begins with the ISA mode of the EFI RT.  To support run time services, the kernel maps the EFI run time and directly calls into it from ring 0.  Since the EFI run time is defined to be the same as the EFI boot services in the EFI system table, RT and BS must be the same.  This leads to the model where if you want to boot a 64-bit OS, you need 64-bit firmware.   Modern OS eschew 'thunking' or down-calling into 32-bit mode from a 64-bit kernel, unlike the practice of doing this from user mode (e.g., WOW64 in Windows and capability binary support in Linux).

So back to the 2-headed BIOS versus the pure 64-bit firmware.  Both solutions were built, but it was quite tricky to implement the 64-bit RT.  We ended up with building a shim that invoked an SMI so that the bulk of code shared between 64-bit and 32-bit RT was handled by the Framework SMM DXE code (i.e., SMM driver model prior to the UEFI PI).  The 64-bit EFI was cleaner since the mode of EFI is also the mode of DXE, our EFI core.  And with the UEFI 2.0 specification in 2006, the 64-bit work was contributed and became one of the central features of the industry-owned specification.

For a refresher on UEFI versus PI, check out Beyond BIOS http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/ or chapter 3 of Hardware Dependent Software http://www.amazon.com/Hardware-dependent-Software-Principles-Wolfgang-Ecker/dp/9048181283/.

After all of the that, you can see why ACPI and its static tables and interpreted AML byte-codes are the preferred run time interface to the platform for PC/AT BIOS and UEFI systems today.  The co-location of the UEFI RT with the kernel in ring 0 and some of the vagaries listed above in implementation argue for not growing the corpus of UEFI RT capabilities.

32v64 - The platform construction view of the world
You will note above some discussion of DXE along with the EFI ISA mode work.  Just as the UEFI RT dictates the UEFI BS mode of operation, the UEFI BS mode dictates the Driver Execution Environment (DXE) mode of operation since the Framework and UEFI Platform Initialization (PI) DXE forms the core of the EFI and UEFI interface sets, respectively.   The same holds true for Framework and PI SMM in the DXE is the SMM loader, so the ISA mode of DXE boot service-time became the mode of the SMM DXE.   Once the die was cast for 64-bits, almost everything in the pre-OS became 64-bit.

"Almost everything" was the case because there are a couple of modes of operation prior to DXE, namely the SEC and PEI phases.  These two phases commence after a processor reset.  Even with the advent of x64, Intel Architecture CPU's still commence operation in 16-bit mode.  As such, the SEC phase mode switches to the PEI mode of operation.  PEI can execute in 32-bit or 64-bit mode.  Some of the complexities of 64-bit long mode entail larger binaries and having to run with paging enabled.  These can be covered by budgeting for the flash space for larger code images and setting up ROM'd page tables with the AD bits pre-set so that page fault walkers don't panic trying to update read-only PTE's.  The advantages of having the ISA mode of PEI and DXE match also include having codes from PEI that can be passed into DXE and re-used, such as the PE/COFF loader and the report status code logic.  The latter is especially important in that prior to loading the DXE architectural protocols, a HOB proxied report status code pointer can be used to update the boot progress during the grey period between PEI hand-off and DXE start up.  32-bit mode, on the other hand, can run in physical mode without paging.  Since such PEI execute in place (XIP) codes rarely need greater than 32-bit addressing and need to be penurious on code size and data usage because of cache-as-RAM size limitations, today PEI implementations are typically 32-bit and the final PEI, or the DXE IPL PEIM, will mode switch to 64-bit as part of invoking DXE Main.

So in summary, the ISA mode of the firmware and the OS kernel is not so simple of a story, and the story is again distinct from the ISA mode of the early PI phases of execution.

So enough on 32-bit and 64-bit.   

Note (3/4/14):  Matt Fleming has an experimental patch treating booting a 64-bit Linux kernel on a 32-bit UEFI platform https://lkml.org/lkml/2014/3/4/242 

UEFI Secure Boot - Measuring Policy
The other thing I wanted to mention was a recent publication on MSDN, namely the Trusted Execution Environment (TrEE)  EFI Protocol and measurement updates, which can be found at http://msdn.microsoft.com/en-us/library/windows/hardware/jj923068.aspx.  This publication is important because the language toward the end around PCR[7] logging of the UEFI 2.3.1c PK, KEK, and DB/DBX addresses one of the architectural gaps of scenarios that employ both measured and secure boot.  Recall that the paper "UEFI Networking and Pre-OS Security" at https://noggin.intel.com/content/uefi-networking-and-pre-os-security-0  describes the relationship of measured and secure boot.  Specifically, on page 94 of the same, "...Measured Boot must include the Allowed, Forbidden, KEK, and PK variables (databases) in its measurements of a Secure Boot-configured platform."  As a result, the measurement language in the TrEE protocol provides a solution for recording the state of the UEFI Secure Boot enforcement policy.   

Accessing UEFI from the operating system runtime

Sometimes the question arises about accessing UEFI services during the operating system runtime.   Recall that UEFI demarcates its core services into boot services and runtime services.   The former are only available prior to the invocation of ExitBootServices(), whereas the latter are available during the life of the platform for a UEFI-aware operating system.   This is the design intent.   Other boot services components can expose content during runtime if said content is allocated in runtime services memory and exposes itself through infrastructure like an installable GUIDed table.

In practice today, these services are not necessarily exposed 1:1 between an operating system services and the corresponding UEFI runtime service.

For Windows, the only API that I know of for accessing UEFI entail the UEFI variable services.   Check out Get/Set firmware environment variables services http://msdn.microsoft.com/en-us/library/windows/desktop/ms724934(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/ms724325(v=vs.85).aspx, respectively.

Linux provides access to the UEFI variable services through sysfs, too.  Some detail can be found at 

http://cateee.net/lkddb/web-lkddb/EFI_VARS.html

Beyond variables, though, UEFI interfaces are opaque at OS runtime for Windows.   For Linux the UEFI system table is a kernel global object for Linux drivers.

The net result is that you cannot get to the UEFI RT or the system table at OS runtime, I'm afraid.   The Linux sysfs is the closest but even there it doesn't expose each UEFI RT call point.  The reason that the UEFI variable services are exposed in the fashion they are via Win32 calls is that OS installer programs have needed them since EFI1.02 back in 1999.   Writing UEFI RT code is pretty tricky because of things like the OS owning the hardware, the virtual mapping of the firmware, etc.(i.e., tough for firmware folks).  Also, the OS guys don't necessarily trust firmware and the UEFI RT code/data isn't hardware isolated from the other OS kernel components and drivers.

As such, the preferred industry approach to having a runtime interface to the platform is ACPI since ACPI runs in a sandbox with an interpreted bytecode AML.  There is some interesting open source implementations of ACPI at http://www.acpica.org/, for example.   UEFI is great for pre-OS applications and usages, of course.  And one model observed today is to stage activities from the OS, such as writing a file to the UEFI system partition, and then rebooting so that an associated UEFI application can act upon the file or directive from the OS agent.

Of course, UEFI runtime services are always available in the pre-OS, namely during the boot services (BS) phase.

3/10/14 update-
Windows now has kernel-mode variants of its access API's http://msdn.microsoft.com/en-us/library/windows/hardware/jj151553(v=vs.85).aspx and there is a nice description of variable access from Linux at firmware.intel.com/blog/accessing-uefi-variables-linux

5/22/14 update-
Regarding the protection of the platform resources by the OS, you need to have administrative privileges in Windows and Linux in order to access the OS API's that abstract the UEFI variable interface from user-land code.

11/5/14 update -
if you boot via Int19h PC/AT BIOS process, the UEFI runtime memory is given back to the OS and is reported as available via the memory map call in E820h Int15h call. As such, there is no way to invoke Get/Set Variable from a PC/AT "Legacy" BIOS boot.

Regarding an open source UEFI runtime service implmentation of variables, https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII_V2.pdf