US20080244252A1 - Using protected/hidden region of a magnetic media under firmware control - Google Patents
Using protected/hidden region of a magnetic media under firmware control Download PDFInfo
- Publication number
- US20080244252A1 US20080244252A1 US12/135,076 US13507608A US2008244252A1 US 20080244252 A1 US20080244252 A1 US 20080244252A1 US 13507608 A US13507608 A US 13507608A US 2008244252 A1 US2008244252 A1 US 2008244252A1
- Authority
- US
- United States
- Prior art keywords
- firmware
- media
- protected area
- access
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
Abstract
A method and firmware for accessing a protected area of a magnetic storage device via firmware control. During early system initialization, various firmware components are loaded and executed to initialize a computer system. These firmware components include a firmware driver for accessing magnetic storage devices connected to the computer system. The system firmware enables a protected area on a magnetic storage device's media to be accessed under firmware control. After firmware accesses, the protected area is closed from access by non-firmware entities (e.g., operating systems) by “hiding” the true size of the media such that those entities are unaware of this area of the media. Mechanisms are disclosed for providing firmware access to the protected area only during pre-boot, and for both pre-boot and run-time operations. The firmware-controlled media access scheme may be used to load firmware stored on magnetic media during pre-boot and to store system information in the protected area during pre-boot and/or run-time operations.
Description
- This application is a continuation of U.S. patent application Ser. No. 10/364,994 filed Feb. 12, 2003 and allowed Feb. 26, 2008.
- 1. Field of the of the Invention
- The field of invention relates generally to computer system and, more specifically but not exclusively relates to firmware-controlled access to a protected or hidden area of a magnetic media.
- 2. Background Information
- Computer platform firmware is used during initialization of computer systems to verify system integrity and configuration. It also generally provides the basic low-level interface between hardware and software components of those computer systems, enabling specific hardware functions to be implemented via execution of higher-level software instructions contains in computer programs that run on the computer systems. In computers, a primary portion of this firmware is known as the Basic Input/Output System (BIOS) code of a computer system. The BIOS code comprises a set of permanently recorded (or semi-permanently recorded in the case of systems that use flash BIOS) software routines that provides the system with its fundamental operational characteristics, including instructions telling the computer how to test itself when it is turned on, and how to determine the configurations for various of built-in components and add-on peripherals.
- In a typical PC architecture, the BIOS is generally defined as the firmware that runs between the processor reset and the first instruction of the Operating System (OS) loader. This system initialization time-frame is commonly referred to as “pre-boot,” and the execution environment prior to OS loading is called the pre-boot environment. As shown in
FIG. 1 , in a typical PC 100, the base portion of the BIOS code is stored in some type of ROM (read only memory) device on the PC's mainboard (i.e., motherboard) 102, such as astandard PROM 104 or aflash memory device 106. In some configurations, this base portion may be extended using code stored inROM BIOS chips 108 contained on one or more add-onperipheral cards 110, such as SCSI controllers and bus-mastering devices. This portion of the BIOS is stored in components that are commonly referred to as “option ROMs.” The BIOS code in peripheral cardROM BIOS chips 108 typically concerns specific functionality provided by their corresponding peripheral card and is executed during initialization of that peripheral card according to a (mostly) well-defined set of rules. In either of the foregoing configurations, all BIOS firmware is stored on non-volatile memory devices, either on the motherboard or in option ROMs on the peripheral card(s) added to a system. - In many instances, the basic functionality of a computer system platform is defined by the plafform's firmware. Accordingly, in order to enhance this functionality, corresponding code needs to be added to or modified in the firmware. In today's PC's, this may be accomplished by either replacing the BIOS chip(s) on the motherboard (and/or peripheral cards), or, if those BIOS code is contained in rewritable chips (e.g., flash memory chips), executing a BIOS update software program that replaces the existing BIOS code with new code. Both of these methods requires user actions that may be prone to error, including improperly installing the new BIOS chips and inadvertently damaging the BIOS code by updating it with the wrong code or having a power failure or system crash in the middle of the code-update process. Furthermore, extensions to the system firmware are limited to the firmware code that may be stored on these IC-based firmware devices.
- The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified:
-
FIG. 1 is a schematic diagram of a computer system containing conventional firmware for describing a conventional firmware loading scheme; -
FIG. 2 is a flowchart illustrating high level operations corresponding to pre-boot operations performed subsequent to loading a computer operating system; -
FIG. 3 is a flowchart illustrating a process in accordance with one embodiment of the invention by which magnetic media may be accessed under firmware control; -
FIG. 4 is a schematic diagram of a computer system containing firmware in accordance with embodiments of the invention that enable access to a protected area of media on a magnetic storage device; -
FIG. 5 is a state diagram illustrating various mechanisms for invoking state transitions in accordance with a security scheme that may be implemented by embodiments of the invention; -
FIG. 6 is a schematic diagram illustrating a firmware configuration employed by one embodiment of the invention for accessing a protected area of media containing extended firmware in accordance with the Extensible Firmware Interface (EFI) framework; -
FIG. 7 is a block schematic diagram illustrating a multi-phase computer system initialization scheme corresponding to a system boot under the EFI framework; -
FIG. 8 is a block diagram of a protocol stack corresponding to a firmware volume access scheme in accordance with the EFI framework; -
FIG. 9 is a flow diagram illustrating the process of loading and executing firmware to further access extended firmware stored on one or more firmware volumes in accordance with the EFI framework; and -
FIG. 10 is a flowchart illustrating a process for storing system configuration information in the protected area of the media and for rolling back a system configuration in the event an unauthorized system configuration change has occurred. - Embodiments of methods and systems that enable access to and employ a protected or hidden region of a hard disk in a pre-boot environment are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
- Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments
- Conventional BIOS Operation
- In a conventional computer system, the BIOS starts to work as soon as a system is turned on. For example, when modern Intel microprocessors (e.g., Pentium III, IV) start to work, they immediately set themselves up in real mode and look at a special memory location 16 bytes short of the top of the one-megabyte real mode addressing range, absolute address 0FFFF0 (Hex). This location holds a jump instruction that redirects the processor to begin execution of code at another address corresponding to where the base portion of the BIOS is actually stored, such as
ROM chip 102. - Execution of the first portion of BIOS code performs a series of diagnostic routines, called the Power-On Self Test (POST) routine, which ensures the major hardware components in a computer system are functioning properly. As depicted by a
block 200 inFIG. 2 , during a first (i.e., early firmware) phase of the POST routine the BIOS enumerates and initializes the system memory and performs other critical chipset initialization operations. One by one, the POST routine checks the integrity of the motherboard, processor, and memory, and checks for the existence of various devices, including a mouse, a keyboard, various storage devices (e.g., floppy drive, hard drives, CD ROM drives, tape drives, etc.), and other components corresponding to configuration information stored in the computer's CMOS memory, or similar persistent storage. As depicted by asecond phase block 202, after the BIOS makes sure that the system is operating properly, it enumerates all non-memory devices on all busses in the system and initializes and starts these devices, as appropriate. In athird phase 204, the BIOS provides means for initiating the loading of the OS and produces runtime interfaces. - Magnetic Media Firmware-Controlled Access Scheme
- As discussed above, in conventional personal computers, all of the BIOS code is stored in ROM-type devices local to the computer, either entirely on the motherboard, or via ROM devices on the motherboard and option ROMs on one or more peripheral add-on cards. Such local storage devices are termed silicon firmware devices as used herein. In accordance with aspects of the invention, a mechanism is now disclosed for enabling access to one or more firmware resources stored on magnetic media, such as that employed by a computer's hard disk system. More particularly, the mechanism employs a protected or hidden region of a hard disk media that is used to store important data in a manner that is transparent to the operating system, and is accessible in the pre-boot environment.
- Recently, a mechanism has been introduced that allows a system to access storage locations on magnetic media without depending on disk access functionality that is normally provided by an operating system during run-time. This mechanism may be employed on magnetic storage devices having controllers that support the Host Protected Area (HPA) feature set. In particular, the Host Protected Area is a feature that was introduced by the ATA/ATAPI-4 (AT Attachment Packet Interface) standard, and accordingly, hard disk controllers that support the standard (and subsequent versions such as ATA/ATAPI-5, which updated the standard) provide direct access to store data on and retrieve data from magnetic media via a corresponding HPA feature command set. Currently, this standard is used to achieve a pseudo-disk capability such that the system can have an alternate location to boot from other than the O/S controlled remainder of the disk. This has been used to launch items like system diagnostics in the past.
- In accordance with the principles and teachings of the invention, techniques for supporting various new usage models are disclosed that take advantage of HPA access for enhanced system functionality. These usage models include: 1) the ability to deprecate FAT (file allocation table) driver support from firmware flash so a firmware volume (which firmware has native support for) can be placed in the HPA area; 2) the ability to store many extensibility modules in the HPA region for additional pre-boot support without encumbering flash overhead which is at a premium; 3) Firmware can enable the saving of critical file-system structures to the HPA for recovery of broken boot structures, since these structures could have been affected by viruses or malfunctioning programs. An operating system would not normally be able to recover a failure in a boot structure since it has yet to be loaded in this case; 4) one can place data to the HPA region in an O/S independent fashion. This allows for critical system core dumps to take place in the pre-boot and the storing of this information without the need to understand the native file-system on the media. Using ram firmware formats to write this data is sufficient for this private region of the media. Generally, the HPA region may be used to store almost any system-related data, and may further include storing system secrets for further security extensibility, storing manageability information (e.g., even logs, manufacturing data, etc.), and storing other types of configuration information.
- With reference to the flowchart
FIG. 3 , a generalized process for accessing firmware stored on a hard disk in accordance with one embodiment of the invention begins in ablock 300 corresponding to a system start/power on event (i.e., a cold boot or system reset). In response to the event, early system firmware is loaded and executed in a manner similar to that discussed above with reference to block 200 ofFIG. 2 . For example,FIG. 4 shows acomputer system 400 including amainboard 402 on which aflash device 404 is mounted. The flash device contains firmware for initializing the computer system and for supporting BIOS run-time services. This firmware is loaded and executed by aprocessor 406 to perform the system initialization operations described herein. In general, firmware may be copied intomemory 408 prior to execution and for subsequent use for run-time firmware drivers. These initialization operations continue in ablock 304, wherein a firmware-level hard disk/controller interface is initialized. This interface provided the low-level interface between software (specifically an operating system), and the hard disk subsystem (controller and hard disk device). In one embodiment, the interface comprises anATAPI 5 compatible device driver. - The disk interface enables firmware to access hard disks connected to an ATAPI-compatible hardware interface via a set of commands. Typically, a peripheral device or chip is employed to facilitate this hardware interface, such as shown in
FIG. 4 , whereincomputer system 400 includes anATAPI 5 controllerperipheral card 410 that is inserted into anexpansion slot 410 inmainboard 402. Optionally, the ATAPI hardware interface may be facilitated by an ATAPI peripheraldevice controller chip 412. - Returning to the flowchart, the process continues in a
block 306 in which the firmware disk interface issues a READ_NATIVE_MAX_ADDRESS command to the ATAPI controller (peripheral card or chip) to determine the native size of the media (hard disk) connected to the controller. This command is one of the commands employed by theATAPI 5 HPA feature command set. As shown inFIG. 4 , this command will return the highest address (size) of the storage space available on an ATAPI 5-compatible storage device (e.g., hard disk) 414 (i.e., the media). The firmware will then issue a SET_MAX_ADDRESS=the value returned from the READ_NATIVE_MAX_ADDRESS command in ablock 308. This enables access to all of the storage space on the media. - Next, in a
block 310, any media access operations corresponding to anHPA region 416 on the media are performed. As described above, the HPA region comprises a special portion of the media that is not visible to the operating system, and thus data may be stored in this region of the media in an OS-independent manner. For example, the firmware may define it's own data storage scheme, such as a firmware-specific file system. - Generally,
HPA region 416 may contain data that is either pre-loaded (e.g., by a system vendor or integrator), or is generated by the system during pre-boot and/or run-time operations. Typically, this portion of the media may be used to store data that are specific to the computer system, such as system configuration information, fault diagnostic information, performance information, etc. In one implementation, the HPA region is used to store additional firmware that is loaded and executed during pre-boot, as described below in further detail. - After the HPA region of the media has been accessed, it is necessary to redefine the size of the media such that the operation system cannot overwrite data stored in the HPA region. Under the
ATAPI 5 HPA feature command set, a scheme is employed to “hide” the HPA region from the operating system. This is accomplished by providing information to the OS that indicates the size of the media is the media's native size minus the portion of the media reserved for HPA access. Thus, in ablock 312 the firmware issues a SET_MAX_ADDRESS=Watermark value that defines the top of the media address that will be visible to the operating system. The region between the media's top native address and this watermark comprises the HPA region of the media. - The SET_MAX_ADDRESS command allows the host to redefine the maximum address of the user accessible address space. Accordingly, when the SET_MAX_ADDRESS command is issued with a maximum address that is less than the native maximum address, the device reduces the user accessible address space to the maximum set, providing a protected area above that maximum address. Under the
ATAPI 5 specification, a SET_MAX_ADDRESS command is to be immediately preceded by a READ_NATIVE_MAX_ADDRESS command. - After the SET_MAX_ADDRESS command has been issued, the device will report only the reduced user address space in response to an IDENTIFY_DEVICE command (which is commonly used by the OS (through the firmware device driver) to determine the Media size and other device parameters). Any read or write command to an address above the maximum address specified by the SET_MAX_ADDRESS command will cause command completion with an error indication returned, or otherwise aborting the command.
- Depending on the implementation, access to the HPA region may be provided only during pre-boot, or may be provided both during pre-boot and run-time. Accordingly, in a decision block 314 a determination is made to whether run-time support is to be provided. If the answer is NO, the firmware issues a SET_MAX_FREEZE command in a
block 316 to disable changing the maximum address until the next system reset. Internally, issuance of the command toggles a volatility bit in the Sector Count register that enable the host to specify whether the maximum address set is to be preserved across power-on or hardware reset cycles. On power-on or hardware resets, the device maximum address returns to the last non-volatile address setting regardless of subsequent volatile SET_MAX_ADDRESS commands. Issuance of the SET_MAX_FREEZE command locks out access to any address above the most recently issued SET_MAX_ADDRESS command until the next system reset or power on event, and thus if this command is issued during pre-boot, access to the HPA region will be disabled during run-time operations. - In some implementations, it may be desired to provide access to the HPA region during OS run-time. However, in order to preserve the integrity of the HPA region data, this should be done in a manner that is transparent to the operating system. As a secondary measure, it may be advantageous to employ security measures provided by HPA feature command set. Accordingly, in an
optional block 318, HPA security support measures are set up. The security features include password support that enables rogue, malicious, or otherwise errant code from accessing the HPA region. In addition to providing run-time security support, the security feature may also be employed during pre-boot to prevent non-trusted firmware components from accessing the HPA region. - With reference to the state diagram of
FIG. 5 , security measures underATAPI 5 operate in the following manner. Page 43. The state diagram contains for states: SMO: the Set_Max_Security_Inactive state; SM1: the SET_Max_Unlocked state; SM2: the SET_Max_Locked state; and SM3: the Set_Max_Frozen state. The SM0: Set_Max_Security Inactive state is the default state that is entered with the device is first powered on. When in this state, SET MAX security is disabled. Subsequently, state transitions proceed as follows: - Transition SM0a:SM0: When a SET MAX ADDRESS command is received, the command will be executed and the device will make a transition to the SM0: Set_MAX_Security Inactive state.
- Transition SM0b:SM0: When a SET MAX LOCK, SET MAX UNLOCK, or SET MAX FREEZE LOCK command is received, the device will abort the command and make a transition to the SM0: Set_MAX_Security_Inactive state.
- Transition SM0:SM1: When a SET MAX-SET PASSWORD command is received, the device will make a transition to the SM1: Set_Max_Unlocked state. SM1: Set_Max_Unlocked: This state is entered when a SET MAX SET PASSWORD or a SET MAX UNLOCK command is received. When in this state, a SET MAX security password has been established and the SET MAX security is unlocked.
- Transition SM1a:SM1: When a SET MAX ADDRESS command is received, the command will be executed and the device will make a transition to the SM1: Set_MAX_Unlocked state.
- Transition SM1b:SM1: When a SET MAX SET PASSWORD is received, the password stored by the device will be changed to the new value and the device will make a transition to the SM1: Set_MAX_Unlocked state.
- Transition SM1c:SM1: When a SET MAX UNLOCK command is received, the command will not be executed and the device will make a transition to the SM1: Set_MAX_Unlocked state.
- Transition SM1:SM2: When a SET MAX LOCK command is received, the device will make a transition to the SM2: Set_Max_Locked state.
- Transition SM1:SM3: When a SET MAX FREEZE LOCK command is received, the device will make a transition to the SM3: Set_Max_Frozen state.
- SM2: Set_Max_Locked: This state is entered when a SET MAX LOCK command is received. When in this state, a SET MAX security password has been established and the SET MAX security is locked.
- Transition SM2a:SM2: When a SET MAX ADDRESS or SET MAX SET PASSWORD command is received, the command will be aborted and the device will make a transition to the SM2: Set_Max_Locked state.
- Transition SM2b:SM2: When a SET MAX LOCK command is received, the command will be executed and the device will make a transition to the SM2: Set_Max_Locked state.
- Transition SM2:SM1: When a SET MAX UNLOCK command is received, the device will make a transition to the SM1: Set Max Unlocked state.
- Transition SM2:SM3: When a SET MAX FREEZE LOCK command is received, the device may make a transition to the SM3: Set_Max_Frozen state. Hosts should not issue the SET MAX FREEZE LOCK command when in this state. (This transition is proposed to be removed in the ATA/ATAPI-6 standard).
- SM3: Set_Max_Frozen: This state is entered when a SET MAX FREEZE LOCK command is received. In this state, the device may not transition to any other state except by a power cycling.
- Transition SM3:SM3: When a SET MAX ADDRESS, SET MAX SET PASSWORD, SET MAX UNLOCK, SET MAX FREEZE LOCK, or SET MAX LOCK command is received, the command will be aborted and the device will make a transition to the SM3: Set_Max_Frozen state.
- Run-time HPA region access support might be enabled under situations in which it is desired to store system data and parameters during run-time in a manner that is transparent to the operating system. In particular, such information may be saved without requiring any operations by the operating system, and in fact may even be performed when the operating system crashes. Typically, the implementation will be enabled through some OS-transparent event detection and service mechanism, such as the System Management operational mode (SMM) provided by various Intel processors. For example, a SMM system management interrupt (SM1) may be invoked in response to a pre-selected event (e.g., OS crash), and a corresponding interrupt service routine may be performed in which various data, such as register values, memory contents, etc., are written to the HPA region. Returning to the flowchart of
FIG. 3 , operations performed by such an event detection and service mechanism are depicted in block 320-330, beginning with the detection of the event and invocation of an appropriate service routine. - Next, in
blocks block 326. - A determination is next made in a
decision block 326 to whether continued run-time support is wanted. As discussed above, it may be desired to save register and/or memory data in the case of a particular event, such as an OS crash. In such a case, subsequent run-time support will not be applicable until a system reset is performed, and the operating system is re-booted. Thus, the answer to decision block 326 will be no, and the process will exit. In cases in which the OS is still operating, it may be desired to continue to provide run-time access to the HPA. Since the maximum accessible address has been raised to provide HPA region access, it is possible that the operating system (via appropriate firmware device driver calls) could access the HPA region at this point. To prevent this, the maximum address is reset via the SET_MAX_ADDRESS command in ablock 330 to the OS-VIS_MAX_ADDRESS watermark, and the cycle returns to wait for the next detected event. - It is noted that it may be possible under some circumstances for the operating system to access the HPA region after
block 326. However, if the HPA access is set up to be performed during an OS-transparent operation, such as servicing of an SM1 with a service routine that concludes by returning the maximum address to the OS-VIS_MAX_ADDRESS watermark inblock 330 prior to returning control to the operating system, the OS will be precluded from accessing the HPA region. - In one embodiment, the magnetic media firmware access mechanism is implemented during pre-boot in accordance with a recently introduced firmware load and execution framework called the Extensible Firmware Interface (EFI) (http://developer.intel.com/technology/efi). More particularly, EFI enables firmware to be loaded, in the form of firmware modules and drivers, from a variety of different resources, including primary and secondary flash devices, option ROMs, and various persistent storage devices (e.g., hard disks, CD ROMs, etc.)
- With reference to
FIG. 6 , in response to a cold boot or system reset, the instruction pointer of a EFI-compliant computer system's microprocessor is directed to the first instruction in a set of platforminitialization firmware code 600 that is stored on a firmware device (FD)0. This firmware device, which typically will comprise a non-volatile memory component such as a flash device or ROM BIOS chip, comprises the boot firmware device (BFD) for the system. Execution of the platform initialization firmware begins at areset code portion 602, and proceeds sequentially until all of the firmware to initialize the computer system has been executed. Under the EFI 2.0 architecture, this initialization process includes various execution phases of the firmware, as shown inFIG. 7 . These execution phases, which include a Pre-EFI Initialization (PEI) phase 700 a Driver eXecution Environment (DXE)phase 702, and an EFI 1.0execution phase 704, enable initialization and set-up of various platform devices and services, and enable an operating system (OS) to be booted in accordance with anOS launch phase 706. Accordingly, the phases preceding the OS launch phase are collectively referred to herein as the pre-boot phase or simply “pre-boot.” - The PEI phase is responsible for main memory initialization and setting up enough of the platform fabric and resources to hand-off control to the DXE phase. As such, the firmware code that is executed to perform the PEI phase includes an Instruction Set Architecture (ISA)-
specific PEI core 708, which is also referred to asPEI framework 708. The PEI framework includes firmware corresponding to adispatcher 710, which upon execution is used to locate and dispatch for execution one or more Pre-EFI initialization modules, also referred to herein as PEI Modules or PEIMs. Firmware code in the PEIMs is used to abstract the particular platform, chipset, and policy abstractions from the baseboard. - During the DXE phase, an ISA-specific DXE core (i.e., DXE framework 712) is executed, enabling one or more DXE drivers to be loaded. The DXE drivers are responsible for providing input/output (I/O) services, such as block device abstraction, consoles, and the EFI file system. These drivers include a distinguished driver called the Boot-Device Selection (BDS) that is responsible for abstracting the operation system load and console selection policy.
- During the EFI 1.0 execution phase, firmware code corresponding to an
EFI framework 714 that provides core EFI operations is executed. The EFI framework also registers anEFI library 716, and one ormore EFI applications - Each of the PEIMs and the DXE drivers may be provided by the microprocessor vendor (e.g., Intel), the platform manufacturer or integrator (e.g., Hewlett-Packard, Dell, Compaq, etc.), a BIOS vendor (e.g., AMI, Phoenix, etc.), or an independent third party. Firmware code corresponding to the PEIMs and DXE drivers provided by a microprocessor vendor or platform manufacturer will typically be stored in the BFD and/or another firmware device that is accessible to the platform (e.g., mounted to the plafform's baseboard) and is included in the original computer system. For example, as shown in
FIG. 6 , firmware code corresponding to a PEIM module A, a PEIM module B and aDXE driver 1 are stored on FD0, whileDXE drivers - In one embodiment, various sets of firmware code are arranged on various firmware devices in the form of “firmware volumes.” This is enabled through use of a firmware abstraction interface known as a firmware volume protocol instance. The firmware volume protocol instance is published by a corresponding firmware volume driver that is loaded during execution of the early firmware phase.
- As a starting point, any firmware code that is accessed by a system is stored in some sort of firmware device. A firmware device is a persistent physical repository containing firmware code and/or data. While a firmware device may typically comprise a PROM or a FLASH component, other types of persistent storage devices may also be used, such as a local hard disk. A single physical firmware device may be divided into smaller pieces to form multiple logical firmware devices. Similarly, multiple physical firmware devices may be aggregated into one larger logical firmware device. A logical firmware device is called a firmware volume. In EFI 2.0, the basic storage repository for data and/or code is the firmware volume. In general, each firmware volume is organized into a file system. In one embodiment, this file system is called a firmware file system (FFS). Other file systems may also be used. As such, the file is the base unit of storage for EFI 2.0 firmware.
- The DX phase accesses firmware volumes using the file abstraction contained in the Firmware Volume Protocol. The Firmware Volume Protocol allows DXE to access all types of firmware volumes, including those that are not memory mapped and those that do not implement the Firmware File System (FFS) format, a firmware-based file system construct. Typically, the Firmware Volume Protocol will be produced by the FFS driver and will layer on top of the Firmware Volume Block Protocol to access the firmware volume hardware. This implementation yields the protocol stack shown in
FIG. 8 . - With reference to
FIG. 9 , in one embodiment a firmware volume access mechanism is implemented as follows. During execution ofearly firmware 900, one or morefirmware volume drivers 902 are loaded from a local firmware device 904 (e.g., flash device 404) and executed. Execution of each firmware driver causes one or more firmware volume protocol instances to be published, as depicted byFV protocol instances firmware volumes - Returning to
FIG. 7 , in accordance with principles of the invention, one or more firmware volumes may be stored on an HPA region of one or more system magnetic storage devices, such ashard disk 414. For example, in the illustrated embodiment ofFIG. 7 ,HPA region 416 comprises a logical firmware device FD1, which contains a set of data corresponding to asingle firmware volume 604. In one embodiment, data within a firmware volume is logically configured based on a block-based allocation scheme. - In addition to providing a firmware storage and access mechanism, the protected media area access techniques disclosed herein may be implemented during pre-boot to save various system information, such as event logs, firmware and/or hardware configuration data, etc. For example, a process that implements this aspect of the invention in accordance with one embodiment is now described with reference to the flowchart of
FIG. 10 . The process begins in astart block 1000, which corresponds to a system reset or power on startup event. As before, appropriate firmware is loaded in ablock 1002 to access the HPA of a selected magnetic media (e.g., the OS boot device, although another magnetic storage device may be used as well). - Next, in a block 1004, current system information is collected. This information may typically include various firmware and/or hardware configuration information. For instance, this information may be collected in one embodiment by storing such information in an event log during firmware initialization. After the configuration information is collected, the HPA is opened, the configuration information is saved in the HPA, and the HPA is closed, as depicted by a
block 1006. - Subsequently, a new system reset or power on startup event occurs in accordance with a
start block 1008. Again, firmware is loaded to access the HPA in ablock 1010, and current system configuration information is collected in ablock 1012 in a similar manner to the operations ofblocks 1002 and 1004. The HPA is opened in ablock 1014, and the prior system configuration information that was previously written to the HPA is retrieved. The current and prior configuration information data are then compared in ablock 1016. - A determination is then made in a
decision block 1018 to whether the current and prior configuration information is the same (indicating no configuration change) or different (indicating a configuration change has occurred. If the configuration hasn't changed, the logic proceeds to ablock 1020 in which access to the HPA is closed. The operating system then boots and the pre-boot phase has completed in the normal manner, as depicted by ablock 1022. - If the configuration information indicates a change has occurred, the logic proceeds to a
block 1024 in which the system and/or user is notified of the change. In some instances, an undesired or unauthorized system change might be made by a rogue entity, such as a third-party firmware component. In other instances, an improperly coded firmware component may produce an unwanted configuration change. Accordingly, a determination is made in adecision block 1026 to whether the change should be authorized. Generally, this determination may be automatically made by the system firmware, or could be determined by a user through an appropriate user interface. - If the configuration change is authorized, the logic proceeds to a
block 1028 in which the configuration information in the HPA is updated, whereupon the access to the HPA is closed followed by subsequent booting of the operating system boots inblocks - In one embodiment, it is desired to prevent unstable configurations. Accordingly a configuration rollback mechanism is employed in a
block 1030 in response to a determination that the change was not authorized, whereby the current system configuration is changed back to a prior configuration. In general, this change may take immediate effect, or may require a system reset, wherein the new configuration is prevented from being entered during a subsequent pre-boot. For instance, data may be stored in the firmware (either in a non-volatile memory device or the HPA to prevent one or more firmware components from being loaded. Since the new (temporally) configuration information was never updated in the HPA and is no longer valid, the HPA is simply closed from access inblock 1020, completing the process. - Generally, the firmware for performing the operations discussed herein will be stored on the system's BFD, and possibly other system firmware devices, such as a secondary flash component or the like. Typically, such firmware may either be included with an original system, or updated at a subsequent point in time, such as via a flash rewrite using firmware code that is stored on removable media (e.g., CD-ROM or floppy disk), or downloaded over a computer network. As used herein, these firmware storage means machine-readable mediums. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium may include such devices as a read only memory (ROM); a magnetic disk storage media; an optical storage media; and a flash memory device, etc. In addition, a machine-readable medium may include propagated signals such as electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.) that are received via wired or wireless computer networks.
- The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
- These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
Claims (30)
1. A method for accessing computer system firmware, comprising:
accessing, via a first portion of firmware, a protected area of media on which data are stored by a magnetic storage device, said data including a second portion of firmware;
loading the second portion of firmware for subsequent use by the computer system, and preventing an operating system to run on the computer system from accessing the protected area of the media.
2. The method of claim 1 , wherein the operating system is prevented from accessing the protected area of the media by hiding the protected area of the media from the operating system.
3. The method of claim 1 , wherein the protected area of the media comprises a portion of the media having an address range defined by respective lower and upper address limits, and wherein the protected area is accessed by performing operations including:
setting a maximum accessible address for the media to correspond to the upper address limit;
accessing the second portion of firmware; and
resetting the maximum accessible address for the media to correspond to the lower address limit.
4. The method of claim 3 , wherein the upper limit correspond to the native size of the media, the method further comprising determining the native size of the media.
5. The method of claim 3 , further comprising freezing the maximum accessible address such that it may not be changed until the computer system is reset or restarted.
6. The method of claim 1 , wherein the magnetic storage device is controlled by a controller that is compliant with the ATAPI 5 or later standard, and the method is implemented via commands corresponding to the ATAPI 5 or later host protected area (HPA) feature command set.
7. The method of claim 1 , further comprising accessing the protected area of the media during operating system runtime in a manner that is transparent to the operating system.
8. The method of claim 1 , further comprising employing a security mechanism to prevent components that are not authorized to access the protected area from accessing the protected area.
9. The method of claim 1 , wherein the second portion of firmware is stored in a firmware volume corresponding to the Extensible Firmware Interface (EFI) standard.
10. The method of claim 1 , further comprising saving system information to the protected area of the media.
11. The method of claim 10 , wherein the system information comprises an image of the boot code for the operating system.
12. The method of claim 10 , wherein the system information comprises system state information.
13. The method of claim 10 , wherein the system information comprises operating system file system information.
14. The method of claim 10 , wherein the system information is saved during system run-time.
15. A machine-readable media on which firmware is stored, which when executed on a computer system performs operations including:
loading a firmware driver for accessing a magnetic storage device;
accessing, via the firmware driver, a protected area of media on which data are stored by the magnetic storage device, said data including extended firmware; and
loading the extended firmware into system memory to enable subsequent use of the extended firmware by the computer system.
16. The machine-readable media of claim 15 , wherein execution of the firmware further performs the operation of configuring an access scheme for the magnetic storage device such that the protected area of the media is hidden from an operating system to run on the computer system.
17. The machine-readable media of claim 15 , wherein the protected area of the media comprises a portion of the media having an address range defined by respective lower and upper address limits, and wherein execution of the firmware accesses the protected area by performing operations including:
setting a maximum accessible address for the media to correspond to the upper address limit prior to accessing the protected area of the media; and
resetting the maximum accessible address for the media to correspond to the lower address limit after completing access of the protected area of the media.
18. The machine-readable media of claim 17 , wherein execution of the firmware further performs the operation of freezing the maximum accessible address such that it may not be changed until the computer system is reset or restarted.
19. The machine-readable media of claim 15 , wherein execution of the firmware further performs the operations of:
opening up the protected area of the media for access during system run-time operation;
saving system information to the protected area; and
closing the protected area of the media from access.
20. The machine-readable media of claim 19 , wherein the protected area is accessed in a manner that is transparent to the operating system.
21. The machine-readable media of claim 19 , wherein the system information is saved in response to a system event and execution of the firmware performs the further operations of:
detecting the system event;
switching execution of a computer system processor from an operating system controlled execution mode to an execution mode that is hidden from the operating system;
servicing the system event by opening the protected area, writing system information pertaining to the system event to the protected area, and closing access to the system area; and
returning the execution mode of the processor back to the operating system controlled execution mode.
22. The machine-readable media of claim 21 , wherein the system event is an operating system crash, and the system information comprises system state information at the time of the operating system crash.
23. A method comprising:
collecting current system configuration information during computer system pre-boot operations;
opening, via firmware control, a protected area of media corresponding to a magnetic storage device for access;
writing data corresponding to the current system configuration in the protected area of the media; and
closing the protected area of the media from access.
24. The method of claim 23 , wherein the current system configuration information pertains to a configuration of the computer system's firmware.
25. The method of claim 23 , wherein the current system configuration information pertains to a configuration of the computer system's hardware.
26. The method of claim 23 , further comprising:
in response to a system reset or power on startup event, collecting new current system configuration information during current computer system pre-boot operations;
opening, via firmware control, the protected area of media corresponding to a magnetic storage device for access;
retrieving data stored in the protected area of the media corresponding to a prior system configuration;
comparing the current system configuration information with the prior system configuration information; and
determining if a change in the system configuration has occurred based on the comparison.
27. The method of claim 26 , wherein it is determined that no change to the system configuration has occurred, further comprising closing access to the protected area of the media.
28. The method of claim 26 , wherein it is determined that a change in the system configuration has occurred, further comprising notifying at least one of the system and/or a user that a system configuration change has occurred.
29. The method of claim 28 , further comprising determining, via input from one of the system or the user, whether the change is authorized, and if it is, updating the system configuration information in the protected area of the media to reflect the new current configuration of the computer system.
30. The method of claim 28 , further comprising determining, via input from one of the system or the user, whether the change is authorized, and if it is not, rolling back the system configuration to correspond to the configuration defined by the prior system configuration information.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/135,076 US20080244252A1 (en) | 2003-02-12 | 2008-06-06 | Using protected/hidden region of a magnetic media under firmware control |
US12/347,840 US8281116B2 (en) | 2003-02-12 | 2008-12-31 | System and method for utilizing a protected/hidden region of semiconductor based memory/storage |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/364,994 US7395420B2 (en) | 2003-02-12 | 2003-02-12 | Using protected/hidden region of a magnetic media under firmware control |
US12/135,076 US20080244252A1 (en) | 2003-02-12 | 2008-06-06 | Using protected/hidden region of a magnetic media under firmware control |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/364,994 Continuation US7395420B2 (en) | 2003-02-12 | 2003-02-12 | Using protected/hidden region of a magnetic media under firmware control |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/347,840 Continuation-In-Part US8281116B2 (en) | 2003-02-12 | 2008-12-31 | System and method for utilizing a protected/hidden region of semiconductor based memory/storage |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080244252A1 true US20080244252A1 (en) | 2008-10-02 |
Family
ID=32824533
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/364,994 Expired - Fee Related US7395420B2 (en) | 2003-02-12 | 2003-02-12 | Using protected/hidden region of a magnetic media under firmware control |
US12/135,076 Abandoned US20080244252A1 (en) | 2003-02-12 | 2008-06-06 | Using protected/hidden region of a magnetic media under firmware control |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/364,994 Expired - Fee Related US7395420B2 (en) | 2003-02-12 | 2003-02-12 | Using protected/hidden region of a magnetic media under firmware control |
Country Status (1)
Country | Link |
---|---|
US (2) | US7395420B2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090259784A1 (en) * | 2008-04-10 | 2009-10-15 | Sandisk Il Ltd. | Peripheral device locking mechanism |
WO2010043071A1 (en) * | 2008-10-16 | 2010-04-22 | Lin Hui | Memory card and establishing or cancelling method for its digital content protection area |
US9135447B1 (en) | 2012-01-30 | 2015-09-15 | Symantec Corporation | Systems and methods for deploying a pre-boot environment to enable an address offset mode after execution of system bios for booting a operating system in a protected area |
WO2016024967A1 (en) * | 2014-08-13 | 2016-02-18 | Hewlett Packard Enterprise Development Lp | Secure non-volatile random access memory |
CN107247646A (en) * | 2017-05-26 | 2017-10-13 | 郑州云海信息技术有限公司 | The method and guiding flow of mainboard VR chip FW versions can be accurately positioned |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7093116B2 (en) * | 2003-04-28 | 2006-08-15 | Intel Corporation | Methods and apparatus to operate in multiple phases of a basic input/output system (BIOS) |
US20040249828A1 (en) * | 2003-06-05 | 2004-12-09 | International Business Machines Corporation | Automated infrastructure audit system |
US20060080517A1 (en) * | 2003-11-14 | 2006-04-13 | Brown Christopher L T | Accessing a protected area of a storage device |
US7523097B1 (en) * | 2004-01-13 | 2009-04-21 | Juniper Networks, Inc. | Restoration of archived configurations for a network device |
TWI262444B (en) * | 2004-04-28 | 2006-09-21 | Compal Electronics Inc | Method for creating multiple main partitions on IDE hard disk |
US7774596B2 (en) * | 2005-02-02 | 2010-08-10 | Insyde Software Corporation | System and method for updating firmware in a secure manner |
CN100383761C (en) * | 2005-03-10 | 2008-04-23 | 联想(北京)有限公司 | Method for setting hard disk physical partition |
US7827376B2 (en) * | 2005-06-27 | 2010-11-02 | Lenovo (Singapore) Pte. Ltd. | System and method for protecting hidden protected area of HDD during operation |
CN100428157C (en) * | 2005-10-19 | 2008-10-22 | 联想(北京)有限公司 | A computer system and method to check completely |
US7565524B2 (en) * | 2006-07-03 | 2009-07-21 | Itzhak Levy | Computer backup system at BIOS level |
US7873807B1 (en) * | 2006-07-28 | 2011-01-18 | American Megatrends, Inc. | Relocating a program module from NVRAM to RAM during the PEI phase of an EFI-compatible firmware |
US20090145184A1 (en) * | 2007-12-05 | 2009-06-11 | International Business Machines Corporation | Apparatus, system, and method for opening a security lock slot of an electronic device |
US8220041B2 (en) * | 2007-12-13 | 2012-07-10 | Trend Micro Incorporated | Method and system for protecting a computer system during boot operation |
KR20090087689A (en) * | 2008-02-13 | 2009-08-18 | 삼성전자주식회사 | Multi channel flash memory system and access method thereof |
US10496608B2 (en) * | 2009-10-28 | 2019-12-03 | Sandisk Il Ltd. | Synchronizing changes in a file system which are initiated by a storage device and a host device |
US8886597B2 (en) * | 2009-10-28 | 2014-11-11 | Sandisk Il Ltd. | Synchronizing changes in a file system which are initiated by a storage device and a host device |
US20110107393A1 (en) * | 2009-11-03 | 2011-05-05 | Rotem Sela | Enforcing a File Protection Policy by a Storage Device |
US20110107047A1 (en) * | 2009-11-03 | 2011-05-05 | Rotem Sela | Enforcing a File Protection Policy by a Storage Device |
JP5378308B2 (en) * | 2010-06-23 | 2013-12-25 | レノボ・シンガポール・プライベート・リミテッド | Main memory backup method and data protection system |
US8769228B2 (en) * | 2010-12-17 | 2014-07-01 | Intel Corporation | Storage drive based antimalware methods and apparatuses |
CN103430147B (en) * | 2011-03-18 | 2016-03-30 | 富士通株式会社 | The control method of signal conditioning package and signal conditioning package |
WO2013095573A1 (en) | 2011-12-22 | 2013-06-27 | Intel Corporation | Activation and monetization of features built into storage subsystems using a trusted connect service back end infrastructure |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5557674A (en) * | 1993-07-22 | 1996-09-17 | Kok-Wah Yeow | Absolute static lock of files and directories on magnetic disk storage media in single machine personal microcomputers |
US5781794A (en) * | 1993-12-01 | 1998-07-14 | Fujitsu Limited | Data processing system having an addition unit for preparing new control tables for new hardware modules and dynamically adding the tables to the present control tables |
US6240511B1 (en) * | 1998-12-14 | 2001-05-29 | Emc Corporation | Method and apparatus for detecting system configuration changes |
US6594756B1 (en) * | 1999-09-08 | 2003-07-15 | Intel Corporation | Multi-processor system for selecting a processor which has successfully written it's ID into write-once register after system reset as the boot-strap processor |
US6633876B1 (en) * | 2000-06-07 | 2003-10-14 | Sun Microsystems, Inc. | Analyzing post-mortem information on a remote computer system using a downloadable code module |
US6633976B1 (en) * | 2000-08-10 | 2003-10-14 | Phoenix Technologies Ltd. | Method of storing BIOS modules and transferring them to memory for execution |
-
2003
- 2003-02-12 US US10/364,994 patent/US7395420B2/en not_active Expired - Fee Related
-
2008
- 2008-06-06 US US12/135,076 patent/US20080244252A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5557674A (en) * | 1993-07-22 | 1996-09-17 | Kok-Wah Yeow | Absolute static lock of files and directories on magnetic disk storage media in single machine personal microcomputers |
US5781794A (en) * | 1993-12-01 | 1998-07-14 | Fujitsu Limited | Data processing system having an addition unit for preparing new control tables for new hardware modules and dynamically adding the tables to the present control tables |
US6240511B1 (en) * | 1998-12-14 | 2001-05-29 | Emc Corporation | Method and apparatus for detecting system configuration changes |
US6594756B1 (en) * | 1999-09-08 | 2003-07-15 | Intel Corporation | Multi-processor system for selecting a processor which has successfully written it's ID into write-once register after system reset as the boot-strap processor |
US6633876B1 (en) * | 2000-06-07 | 2003-10-14 | Sun Microsystems, Inc. | Analyzing post-mortem information on a remote computer system using a downloadable code module |
US6633976B1 (en) * | 2000-08-10 | 2003-10-14 | Phoenix Technologies Ltd. | Method of storing BIOS modules and transferring them to memory for execution |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090259784A1 (en) * | 2008-04-10 | 2009-10-15 | Sandisk Il Ltd. | Peripheral device locking mechanism |
US7953913B2 (en) * | 2008-04-10 | 2011-05-31 | Sandisk Il Ltd. | Peripheral device locking mechanism |
WO2010043071A1 (en) * | 2008-10-16 | 2010-04-22 | Lin Hui | Memory card and establishing or cancelling method for its digital content protection area |
US9135447B1 (en) | 2012-01-30 | 2015-09-15 | Symantec Corporation | Systems and methods for deploying a pre-boot environment to enable an address offset mode after execution of system bios for booting a operating system in a protected area |
WO2016024967A1 (en) * | 2014-08-13 | 2016-02-18 | Hewlett Packard Enterprise Development Lp | Secure non-volatile random access memory |
CN107247646A (en) * | 2017-05-26 | 2017-10-13 | 郑州云海信息技术有限公司 | The method and guiding flow of mainboard VR chip FW versions can be accurately positioned |
Also Published As
Publication number | Publication date |
---|---|
US7395420B2 (en) | 2008-07-01 |
US20040158698A1 (en) | 2004-08-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7395420B2 (en) | Using protected/hidden region of a magnetic media under firmware control | |
US8281116B2 (en) | System and method for utilizing a protected/hidden region of semiconductor based memory/storage | |
AU635690B2 (en) | An apparatus and method for loading a system reference diskette image from a system partition in a personal computer system | |
US6993649B2 (en) | Method of altering a computer operating system to boot and run from protected media | |
US6862681B2 (en) | Method and system for master boot record recovery | |
US5214695A (en) | Apparatus and method for loading a system reference diskette image from a system partition in a personal computer system | |
JP3539907B2 (en) | Computer with bootable program | |
US7702894B2 (en) | System and method for loading programs from HDD independent of operating system | |
US7111203B2 (en) | Method for implementing data backup and recovery in computer hard disk | |
EP1634170B1 (en) | Method for firmware variable storage with eager compression, fail-safe extraction and restart time compression scan | |
US6711660B1 (en) | System and method for performing disk drive diagnostics and restoration using a host-inaccessible hidden partition | |
KR100924497B1 (en) | System and method for booting from a non-volatile application and file storage device | |
US6085318A (en) | Computer system capable of booting from CD-ROM and tape | |
US20030233534A1 (en) | Enhanced computer start-up methods | |
US7017039B2 (en) | Method of booting a computer operating system to run from a normally unsupported system device | |
US6421776B1 (en) | Data processor having BIOS packing compression/decompression architecture | |
US20030110369A1 (en) | Firmware extensions | |
US6594756B1 (en) | Multi-processor system for selecting a processor which has successfully written it's ID into write-once register after system reset as the boot-strap processor | |
US20070006220A1 (en) | Computer system, system software installation method, and software installation method of portable computer | |
US6961848B2 (en) | System and method for supporting legacy operating system booting in a legacy-free system | |
US11907071B2 (en) | Storage failover protocol for secure and seamless extended firmware load | |
US20050050313A1 (en) | Method of turning on a computer | |
CN117707431A (en) | BIOS-based software RAID data reading method and device | |
GB2309560A (en) | Computer systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |