Bridging memory access across pre-boot and runtime phases

[0001] 1. Field

[0002] The present disclosure relates to bridging access to a memory space across pre-boot and runtime phases and, more particularly, to accessing the memory utilizing a separate pre-boot memory accessor and a runtime accessor.

[0003] 2. Background Information

[0004] Typically, the operation of computer or processing systems (hereafter, “computer”) may be divided into two stages, pre-boot and runtime. The pre-boot process or phase often comprises starting or resetting a computer. When first turned on (cold boot) or reset/reboot (warm boot), a computer executes the firmware that loads and starts the computer's more complicated operating system and prepares it for use. Thus, the computer can be said to pull itself up by its own bootstraps. The runtime process or phase often occurs after the pre-boot phase and includes the execution of an operating system and other user applications. The runtime phase is typically the phase that users interact with the computer. Thus, the computer can be said to being running application programs.

[0005] Typically, during pre-boot, the computer is first powered on and has very limited capabilities because the volatile memory contains random data and no operating system is running. To begin the pre-boot phase, the processor is often reset to a known state and instructions found at a pre-defined location are executed. Traditionally, this pre-defined location is mapped to a non-volatile memory or firmware referred to as a Basic Input/Output System (BIOS). The BIOS often includes several low-level procedures to control the initialization of the hardware components that comprise the computer. Because of the historical limitations of early computers, the BIOS generally operated in what is known as “real mode.” In real mode, the computer may only execute one program at a time and can access no more than 1 MB of volatile memory. Modern operating systems, on the other hand, often run in “protected mode.” Protected mode allows the computer to run multiple programs substantially simultaneously, referred to as multi-taking, and there is essentially no limit to the amount of volatile memory that may be accessed.

[0006] During pre-boot, the BIOS generally confirms that the computer's hardware components, such as, for example, the CPU, memory and various add-on cards, are functioning properly. In addition, these hardware components may be configured and initialized during the pre-boot phase. Often an application may, for example, desire to collect information about a hardware component during the pre-boot phase and supply the information to a runtime phase application or driver. In this context, a driver or device driver is a specialized program that augments an operating system's capability to support a hardware component.

[0007] Traditionally, runtime applications have had substantially unfettered access to the same portions of memory as the pre-boot applications. Therefore, passing information between the pre-boot and runtime phases was relatively trivial. For example, one technique for bridging information between the two phases may include the following steps. The pre-boot application may reserve a portion of volatile memory to store the information. The pre-boot application may store a pointer to this portion of volatile memory at a predefined location. Because the pre-boot phase is often limited to accessing a maximum of 1 MB of volatile memory, this predefined location is typically below that limit. During the runtime phase, the driver may directly access the pointer and, subsequently, access the information. However, this technique involves insecure and potentially uncontrolled access to the system memory.

[0008] More current systems limit the access runtime applications have to the portions of memory the pre-boot applications have. The access of runtime applications is often limited and controlled by the operating system. Therefore, the technique above, of placing a pointer within the first MB of volatile memory, will not work. The operating system will often not allow a runtime application to make a direct access to a random address in volatile memory. A need therefore exists for a technique or apparatus to address the issue of bridging a memory between pre-boot and runtime phases.

[0012] In the following detailed description, numerous details are set forth in order to provide a thorough understanding of the present disclosed subject matter. However, it will be understood by those skilled in the art that the disclosed subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as to not obscure the disclosed subject matter.

[0013] FIG. 1 is a flowchart illustrating an embodiment of a technique for bridging access to a memory space across pre-boot and runtime phases in accordance with the disclosed subject matter. Block 110 illustrates that, during the pre-boot phase, an area of volatile memory, such as, for example, system memory, may be reserved. This area may be reserved for data storage. It is contemplated that, in one embodiment, the data may be copied from a first location to the reserved memory area. It is contemplated that the data may be originally stored in a variety of locations, such as, but not limited to, the firmware of an add-on card, a mass storage device, such as, for example, a hard drive. Of course, other original storage locations are contemplated. It is also contemplated that the data may be generated, in whole or part, by a pre-boot application.

[0014] In one specific embodiment of the technique, a video add-on card may include a series of instructions and/or data stored within a non-volatile memory that is attached with the card. It may be useful for these instructions and/or data to be accessed during the runtime phase. However, the system may not allow the firmware of the video add-on card to be accessed during the runtime phase. Alternatively, it may be prohibitive to access the firmware during runtime; most operating systems run in protected mode, virtual mode, paging and multiprocessor support. In contrast, the legacy BIOS services typically execute in real mode, without virtual memory (i.e., physical mode), run only a single processor and services are dispatched from a legacy Interrupt Vector Table (IVT) at address Oh. In order to make service calls to the BIOS from the operating system (OS), the sophisticated environment of the operating system, must be torn down. This OS tear-down is often slow and causes security/reliability issues in the S since memory protections are gone during the service call. Therefore, the disclosed subject matter may, at least in part, allow the operating system or other runtime application a technique to pass firm-ware data without making a destructive service call to the BIOS.

[0015] The system may only allow access to the firmware during the pre-boot phase. Therefore, it may be necessary to copy the data or other information embodied in firmware to a location that may be accessed during the runtime phase. However, this location may change each time the system in booted. Therefore, the pre-boot phase must communicate to the runtime phase where the data is located. It may do this by following an embodiment of the technique illustrated by FIG. 1. As part of block 110, space for the instructions may be reserved within volatile memory. It is contemplated that the memory area, or pointers to the memory area, may be of a type that designates the memory area as runtime accessible.

[0016] Block 120 illustrates that a pointer to the data or the reserved memory area may be placed within an architectural memory structure. In this context, an architectural memory structure is a section of memory having data elements that are arranged in an orderly fashion and whose existence, but not necessarily contents, is defined as being part of the architecture of the computer system. It is contemplated that the architectural memory structure may exist in volatile memory, non-volatile memory or a mixture thereof. It is further contemplated that the architectural memory structure may be contiguous or non-contiguous. It is even contemplated that the architectural memory structure may be hidden or not directly accessible via operating system services during the runtime phase.

[0017] In one specific embodiment, the architectural memory structure may include a System Table or Configuration Table substantially compliant with the tables defined in the Extensible Firmware Interface (EFI) specification. Extensible Firmware Interface (EFI) Specification, version 1.02, Dec. 12, 2000, Intel Corp. (hereafter, “the EFI specification”). Such a table may include, for example, pointers to boot service functions, pointers to runtime service functions, version information, and an extensible set of identifier and pointer pairs. Of course, it is contemplated that other data may be found within various embodiments of an architectural memory structure.

[0018] In one specific embodiment of the disclosed subject matter, the pointer to the reserved memory area may be stored within the System Table as a Globally Unique Identifier (GUID) pointer pair. Such a pointer pair may include a pointer key that identifies the information, and may be a GUID, and a pointer value that may be the actual pointer to the reserved memory area. In an embodiment utilizing the EFI specification, the GUID pointer pair may be created by utilizing the InstallConfigurationTable boot service. It is contemplated that the pointer may be stored utilizing a different mechanism, such as, for example, storing the pointer at a pre-defined location or under a pre-defined variable name. It is also contemplated that the pointer may be stored in an indirect fashion.

[0019] Block 130 illustrates that, during pre-boot, a pointer to the architectural memory stricture itself may be stored in a non-volatile memory space that is accessible during both the pre-boot and runtime phases. It is contemplated that the non-volatile memory space may be accessible during runtime because the information it contains is shadowed in volatile memory. It is further contemplated, in one embodiment, that the non-volatile memory may be accessible utilizing an accessor application programming interface.

[0020] In one specific embodiment, the pointer to the architectural memory structure may be stored in the non-volatile memory by utilizing a pre-defined variable name, such as, for example, “System Table Proxy.” However, it is contemplated that a number of variable names may be used. It is also contemplated that the pointer may be stored at a pre-defined memory address. In an embodiment utilizing the EFI specification, the location of the System Configuration Table may be stored in non-volatile memory.

[0021] After the pre-boot phase is substantially completed, the runtime phase may commence. It is contemplated that in some embodiments of the disclosed subject matter, the portions of the pre-boot and runtime phase may occur simultaneously. Block 140 illustrates that the pointer to the architectural memory structure may be read utilizing the non-volatile memory. It is contemplated that, in one embodiment, the operating system may govern the access to the non-volatile memory and that runtime applications may be prohibited from directly accessing the non-volatile memory. In one embodiment, the operating system may, for example, allow applications to read from the non-volatile memory but not write to the memory. It is also contemplated that the operating system may shadow the contents of the non-volatile memory, in whole or part, in volatile memory. In this context, it is understood that references to non-volatile memory may include the portions of the non-volatile memory shadowed in volatile memory.

[0022] In a specific embodiment utilizing the EFI specification, the pointer to the architectural memory structure may be accessed by a performing an operating system runtime function, such as, the GetVariable service. Of course, it is contemplated that other embodiments may access the pointer via other services. It is contemplated that this access may be either direct or indirect.

[0023] Block 140 illustrates that the pointer to the reserved memory area may be read from the architectural memory structure. It is contemplated that the pointer may be read by utilizing an operating system service, directly reading from the physical memory address of the structure or another technique. It is contemplated that the architectural memory structure may be hidden or not directly accessible via operating system services during the runtime phase.

[0024] In a specific embodiment, utilizing the EFI specification, the pointer to the reserved memory space may be stored utilizing a GUID pointer pair. In addition, the operating system may not provide a service to conveniently access the architectural memory structure. In this embodiment, the pointer to the reserved memory may be accessed by walking through the contents of the architectural memory structure and searching for the GUID associated with the pointer. It is contemplated the GUID may be a predefined value. It is also contemplated that the GUID may be communicated to the runtime phase application utilizing a technique similar to that described in block 140; however, other techniques are within the scope of the disclosed subject matter.

[0025] Block 160 illustrates that once the pointer to the reserved memory area is read, the reserved memory area may be accessed. It is contemplated that the reserved memory area may be accessed either directly or via operating system services.

[0026] In the specific embodiment involving the video add-on card, described in relation to block 110, the video add-on card had instructions that might have been accessed during the runtime phase. During the pre-boot phase, these instructions were copied to a reserved portion of volatile memory. The pointer to that area may have been stored in an architectural memory structure, for example, the EFI System Table. A pointer to a structure was then stored in non-volatile memory. During the runtime phase, the pointers where followed to eventually determine the physical, or virtual, address of the reserved memory area. Once the address of the memory area was determined, the instructions stored there, in this embodiment, could be accessed and processed. This is one specific embodiment of the technique illustrated by FIG. 1, other embodiments are with the scope of the disclosed subject matter.

[0027] In a specific embodiment of the disclosed subject matter, the technique illustrated by FIG. 1 may be utilized within a system substantially compliant with the Extensible Firmware Interface (EFI) specification, described above. It is understood that this is merely one specific example and the disclosed subject matter is not limited by this illustrative example. In the pre-boot EFI environment, the EFI Core may allocate memory for the architecturally defined memory structure, System Table. This allocation may be in a memory region of type Runtime memory. The EFI Core will populate the allocated memory region with function pointers relative to services that are proxied through the System Table. An EFI compliant driver or application will be passed a pointer to the System Table. This application may then make EFI service calls, including but not limited to the installation of domain-specific information in the Globally Unique Identifier (GUID)/Pointer Pair using the boot service InstallConfigurationTable.

[0028] Therefore, an EFI compliant driver or application may, as illustrated by Block 110, reserve an area of memory for data storage. Using a private accessor or the InstallConfigurationTable boot service, the EFI application may, as illustrated by Block 120, install an entry into the GUID/Pointer table. The GUID/Pointer table includes a GUID to index and entry and a data component to store a Pointer value. The EFI application may ensure that of type Runtime Memory, if the intent is to have a Runtime agent or application ascertain the information.

[0029] A given EFI application may issue the ExitBootServices call to the EFI Core in order to terminate access to the EFI Services. The EFI core may then create an EFI variable with the string “System Table Proxy” and a GUID of EFI_SYSTEM_TABLE_PROXY. This variable and GUID may act as a pointer to the System Table architectural memory structure, as illustrated by Block 130. However, it is contemplated that this is merely one specific example and other embodiments of the disclosed subject matter are contemplated.

[0030] Once the system has completed the pre-boot phase, the system will operate in the runtime phase. If a kernel mode driver, for example, wishes to ascertain the location of the allocated area of memory, the driver may call the KeGetConfigurationInformation function or an equivalent OS system call. Using the EFI_SYSTEM_TABLE_PROXY GUID and the “System Table Proxy” variable, or some appropriate permutation/subset thereof, receive the physical address of the EFI System Table, as illustrated by Block 140. The driver may use the appropriate kernel or system call to get a physical mapping to the address of the EFI System Table. By casting a pointer to type EFI_SYSTEM_TABLE, and then referencing a member function of type EFI_CONFIGURATION_TABLE the location of the architectural memory structure, Configuration Table, may be obtained. The Configuration table is a subset of the System Table and includes the GUID/Pointer pair structure.

[0031] As illustrated by Block 150, the driver may walk through the Configuration table entries comparing GUIDs and looking for a driver specific GUID. Once found, the driver may read the appropriate Pointer entry and receive a pointer to the allocated memory space. The driver, as illustrated by Block 160, may then access the allocated memory space. The above is merely one embodiment of the disclosed subject matter and other embodiments may exist.

[0032] FIG. 2 is a block diagram illustrating an embodiment of a system for bridging access to a memory space across pre-boot and runtime phases in accordance with the disclosed subject matter. It is contemplated that an embodiment of such a system may take many forms, such as for example, everything from small handheld electronic devices, such as personal data assistants and cellular phones, to application-specific electronic devices, such as set-top boxes, digital cameras, and other consumer electronics, to medium sized mobile systems, such as, notebook, sub-notebook, and tablet computers, to desktop systems, workstations, and servers. However, the system is not limited to the forms described above and other forms are contemplated.

[0033] An embodiment of a system in accordance with the disclosed subject matter may include a volatile memory space 250, an architectural memory structure 240 and a non-volatile memory space 230. In one embodiment, these memory spaces may function and be arranged in accordance with the blocks described in FIG. 1.

[0034] The system may also include a pre-boot application 210. It is contemplated that, in one embodiment, the pre-boot application may perform actions substantially in compliance with the pre-boot actions described above in regard to FIG. 1. It is contemplated that the pre-boot application may utilize a pre-boot non-volatile memory accessor 220 to access non-volatile memory space 230. It is contemplated that the pre-boot memory accessor may govern how and what information is read from or written to the non-volatile memory. It is also contemplated that the pre-boot memory accessor may govern access to only a portion of the non-volatile memory space.

[0035] The system may also include a runtime application 260. It is contemplated that, in one embodiment, the runtime application may perform actions substantially in compliance with the runtime actions described above in regard to FIG. 1. It is contemplated that the runtime application may utilize a runtime non-volatile memory accessor 270 to access non-volatile memory space 230. It is contemplated that the runtime memory accessor may govern how and what information is read from or written to the non-volatile memory. It is also contemplated that the runtime memory accessor may govern access to only a portion of the non-volatile memory space.

[0036] The techniques described herein are not limited to any particular hardware or software configuration; they may find applicability in any computing or processing environment. The techniques may be implemented in hardware, software, firmware or a combination thereof. The techniques may be implemented in programs executing on programmable machines such as mobile or stationary computers, personal digital assistants, and similar devices that each include a processor, a storage medium readable or accessible by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. Program code is applied to the data entered using the input device to perform the functions described and to generate output information. The output information may be applied to one or more output devices.

[0037] Each program may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. However, programs may be implemented in assembly or machine language, if desired. In any case, the language may be compiled or interpreted.

[0038] Each such program may be stored on a storage medium or device, e.g., compact read only memory (CD-ROM), digital versatile disk (DVD), hard disk, firmware, magnetic disk or similar medium or device, that is readable by a general or special purpose programmable machine for configuring and operating the machine when the storage medium or device is read by the computer to perform the procedures described herein. The system may also be considered to be implemented as a machine-readable or accessible storage medium, configured with a program, where the storage medium so configured causes a machine to operate in a specific manner. Other embodiments are within the scope of the following claims.

[0039] While certain features of the disclosed subject matter have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes that fall within the true spirit of the disclosed subject matter.