Enabling optional system features

TECHNICAL FIELD

[0001] This invention relates to enabling optional system features.

BACKGROUND

[0002] The BIOS (Basic Input/Output System) of a computer is a collection of low-level, machine dependent software that serves to isolate an operating system (e.g., MS-DOS on a personal computer) from the details of the hardware. For example, the BIOS includes procedural calls that read from and write to an absolute disk address, read a character from the keyboard, and write a character to the screen. The BIOS is typically placed on a non-volatile memory chip, e.g., ROM (Read-Only Memory), flash memory, and EEPROM (Electrically Erasable Programmable ROM), supplied by a computer manufacture. The contents of the non-volatile chip are not affected when the computer is powered off. The BIOS is usually stored separately from the OS (Operating System) of the computer to allow independent upgrade of the OS and the BIOS.

[0003] Because BIOS of newer versions can be developed during the life span of a computer, it may be necessary to upgrade the BIOS for enhanced performance. Therefore, most modern personal computers store the BIOS on a re-writable memory chip. In particular, a flash memory chip is most often adopted because of its simplicity in use and efficiency to update.

[0004] Some computer manufacturers add a RAM (Random Access Memory) for use by the BIOS because RAMs are in general faster than most of the non-volatile memory chips. Each time the computer is rebooted, the BIOS is copied from the non-volatile memory chip to the RAM to accelerate operations of the BIOS. The copying procedure is also known as a “shadowing” procedure.

[0005] When a computer is turned on, or rebooted, the BIOS is read and executed by a pre-determined rebooting process. In particular, a bootstrap procedure in the BIOS is executed. The bootstrap procedure carries out hardware tests to ensure that the computer is ready for executing user commands. The BIOS also reads from a diskette, a hard drive, or other storage devices when further information is required for rebooting the computer. Thus, by using the BIOS to reboot the computer and handling input/output operations, hardware details of the computer are hidden from users and high-level software.

DESCRIPTION OF DRAWINGS

[0006]FIG. 1 shows using a BIOS to enable optional system features; and

[0007]FIG. 2 shows a process for enabling the optional system features.

DETAILED DESCRIPTION

[0008] Referring to FIG. 1, a processing system <b>10</b> includes a BIOS memory <b>12</b>, an OS (Operating System) memory <b>13</b>, and system resources <b>25</b>. OS memory <b>13</b> stores an OS <b>33</b>, which manages system resources <b>25</b> and contains high-level software to provide a user-friendly programming environment. BIOS memory <b>12</b> stores a BIOS <b>22</b>, which is a collection of device drivers that allow users of system <b>10</b> and OS <b>33</b> to interact with the hardware of the system, but hide machine-dependent details from them. An exemplary memory for BIOS memory <b>12</b> is a flash memory, which is re-writable. System resources <b>25</b> includes elements of system <b>10</b> that contribute to processing power, storage capacity, redundancy, and speed, e.g., memory, input/output devices, processors, redundant power supplies, and PCI (Peripheral Component Interconnect) bus.

[0009] Some of system resources <b>25</b> have system features that can be optionally selected or configured on an as-needed basis. The features generally include on/off status of the elements of system <b>10</b> and adjustable parameters of these elements, e.g., memory size, number of processors, number of PCI slots, PCI bus speed, number of redundant power supplies, and processor speed.

[0010] In certain scenarios, it is desirable to selectively enable some of the system features as needed for run-time usage. For example, a manufacturer, e.g., an OEM (Original Equipment Manufacturer), can produce computer systems with the same number of processors. When an end-user purchases one of the computer systems but only uses a few of the processors for performing tasks, the OEM can enable the number of processors as needed by the user. In general, the OEM can produce computer systems with uniform resources and configurations, and can enable the system features selectively after client needs and cost options are determined. The capability of enabling optional system features can be useful in situations where an end-user wants to rent or lease system capacity, performance, or manageability as an alternative to outright purchasing these features. This capability can also be useful when a system provider wishes to reduce the number of available stocked computers, each having different system features, for a given hardware/software set. The number of different stocked computers can be reduced by differentiating the identical computers by enabling different system features. Furthermore, this capability also allows end-users to update or upgrade system capacity or system features without opening the system.

[0011] The capability of enabling optional system features is preferably secure, because the OEM may not want the system features to be enabled without authorization. For security purposes, system <b>10</b> includes a write-once non-volatile storage <b>31</b>. Storage <b>31</b> is protected from write and erase operations. For example, storage <b>31</b> can be a flash memory protected by chipset options, e.g., SMI (System Management Interrupt) protection. The SMI is a special and high-priority interrupt in a PC AT bus architecture that prevents any non-BIOS software application from writing or erasing storage <b>31</b>.

[0012] Storage <b>31</b> stores a decryption key <b>310</b>, a public key <b>311</b>, and GUID <b>312</b> (Globally Unique Identifier). GUID <b>312</b> is a long identifier, e.g., 128 bytes, which uniquely identifies system <b>10</b>. BIOS <b>22</b> uses the above contents of storage <b>31</b> to implement a secure environment; specifically, the secure environment guarantees authenticity, privacy, and validation of messages from the OEM. The secure environment assures that a message from the OEM for enabling system features will be received and processed in a secure manner.

[0013] A BIOS-based control mechanism, as will be described in detail below, is used to provide the capability of enabling optional system features in a secure manner. BIOS <b>22</b> includes a flash update code <b>23</b> that accesses the contents of storage <b>31</b>. BIOS <b>22</b> also includes a feature set <b>24</b> where status of the system features are recorded. In one embodiment, BIOS update code <b>23</b> includes a decryption function <b>232</b> that decrypts the message sent from the OEM, an authentication function <b>233</b> that authenticates a digital signature of the message, a verification function <b>234</b> that verifies the message, and a flash update utility <b>235</b> that updates a secure non-volatile storage <b>32</b>. Operations of flash update code <b>23</b> will be discussed in detail below.

[0014] When the OEM of system <b>10</b> wishes to enable certain features of the system, the OEM sends a message to BIOS <b>22</b>. The message can be transmitted to BIOS <b>22</b> in a number of ways, for example, through a network in the form of “feature packets” <b>27</b>, on a floppy diskette inserted into a floppy drive of system <b>10</b>, using a file copy, or by electronic mail. Regardless how the message is transmitted to BIOS <b>22</b>, it is important that the authenticity, validity, and privacy when appropriate, of the message be guaranteed. The authenticity, validity, and privacy of the feature packet's content are protected by encryption and digital signature. Because of the protection of the encryption and digital signature, it is not required that the message be transmitted via secure mechanisms. The BIOS <b>22</b> at the final destination of the feature packet (i.e., system <b>10</b>) can perform complete authentication and validation of the feature packet's content regardless of the transmission medium and/or number of time the feature packet is transferred. Furthermore, the privacy of the feature packet's content is guaranteed at all times as a result of the encryption.

[0015] Specifically, when the OEM sends the message to BIOS <b>22</b>, the OEM generates a digital signature with a private key known only to the OEM. The digital signature is attached to the message to assure the recipient (i.e., BIOS <b>22</b>) that the message is from an authentic sender. When BIOS <b>22</b> receives the message, authentication function <b>233</b> uses a public key <b>311</b> to confirm that the digital signature is correct, valid, and has not been tampered with. If the content of the message also requires privacy, the OEM can encrypt the message with an encryption key using an encryption algorithm (e.g., 128-bit RSA) to guarantee privacy of the message. When BIOS <b>22</b> receives the message, decryption function <b>232</b> uses decryption key <b>310</b>, which is known only to system <b>10</b>, to decrypt the received message. The encryption ensures that the message will not be meaningful to anyone other then the intended recipient.

[0016] In addition to authenticity and privacy, the recipient also needs to verify that it is indeed the intended recipient of the message. Therefore, the message from the sender also includes an identifier that will be verified against GUID <b>312</b>. Only the message with an identifier matching the GUID of system <b>10</b> will be processed by BIOS <b>22</b>.

[0017] Referring to FIG. 2, an example of a process <b>40</b> is shown for enabling optional system features of system resources <b>25</b>. BIOS <b>22</b> receives a message from the OEM, for example, in the form of feature packets <b>27</b> arriving from a network connected to system <b>10</b> (block <b>41</b>). If the message is encrypted, decryption function <b>232</b> decrypts the message using decryption key <b>310</b> (block <b>42</b>). Authentication function <b>233</b> authenticates the digital signature in the message using public key <b>311</b> (block <b>43</b>). Verification function <b>234</b> verifies the identifier in the message against GUID <b>312</b> (block <b>44</b>). If failure occurs (blocks <b>411</b>, <b>412</b>, and <b>413</b>) during the decryption, authentication, or verification, process <b>40</b> is aborted, and the message is discarded (block <b>49</b>).

[0018] If no failure occurs, in one scenario, BIOS <b>22</b> executes flash update utility <b>235</b> to write the message into a secure non-volatile storage <b>32</b> (block <b>45</b>), which only accepts inputs from a trusted source, e.g., BIOS <b>22</b>. System <b>10</b> is then rebooted (block <b>46</b>). During the rebooting process, BIOS <b>22</b> retrieves the information in storage <b>32</b> and executes according to the information to enable optional system features (block <b>47</b>). BIOS <b>22</b> then records the optional system features in feature set <b>24</b> (block <b>48</b>).

[0019] It should be noted that while reboot at block <b>46</b> is shown in process <b>40</b>, in certain scenarios, system <b>10</b> does not need to be rebooted. With appropriate stack support from OS <b>33</b> and software, system <b>10</b> can continue to operate while the system features are being enabled. However, one benefit of rebooting the system is that the current OS <b>33</b> and hardware can be used in this BIOS-based control mechanism without modifications.

[0020] At block <b>45</b> of process <b>40</b>, secure non-volatile storage <b>32</b> can be connected to system <b>10</b> either locally, or remotely via network links. Storage <b>32</b> serves as a database that stores the decrypted and validated message from the OEM. Only a trusted source, e.g., BIOS <b>22</b>, can write or erase the contents of storage <b>32</b>. In one embodiment, storage <b>32</b> identifies BIOS <b>22</b> as the trusted source, and accepts any input coming from BIOS <b>22</b>. In another embodiment, BIOS <b>22</b> encrypts the message before it is sent to storage <b>32</b>, and storage <b>32</b> decrypts the message in the same manner as performed by decryption function <b>232</b>. Other techniques for ensuring the trust between BIOS <b>22</b> and storage <b>32</b> are also possible. Examples of storage <b>32</b> include a flash memory, an EEPROM, and a disk, or any other device that is secure, non-volatile, and re-writable.

[0021] In certain scenarios, BIOS <b>22</b> does not need to write the message to storage <b>32</b>, and therefore can skip block <b>45</b> of process <b>40</b>. For example, if the message from the OEM contains BIOS-executable code, BIOS <b>22</b> can splice the code into its normal execution path, thus effectively modifying itself or erasing part of itself in response to the message. This “splicing” approach is better suited for controlling system features such as number of processors or memory sizes. In another approach, the message from the OEM can include executable code that can be used as DLL (Dynamically Loaded Library). The code is stored in a flash portion of system <b>10</b>, and is loaded by BIOS <b>22</b> at run-time. The “DLL” approach allows BIOS <b>22</b> to patch itself with the new executable code, and is better suited for adding large new functionalities such as adding hot-plug CPU (Central Processing Unit) support, or hot-plug memory support.

[0022] In embodiments where processing system <b>10</b> includes multiple processors, feature set <b>24</b> includes an MPS (Multiple Processor Specification) table <b>241</b> for storing features related to the multiple processors, e.g., number of processors, processing speed of each of the processors, and so forth. For example, assume that the message from the OEM specifies that only a few of the processors in system <b>10</b> will be authorized and enabled. In one scenario, BIOS <b>22</b> disables the un-authorized processors by a sequence of actions in an implementation-specific manner. The sequence of actions may include asserting the FLUSH# during a reset, asserting the STP_CLK#, omitting the processors from the MPS and/or ACPI (Advanced Configuration and Power management Interface) processor tables. Once system <b>10</b> has been fully rebooted, all the authorized processors will be enabled. The status of the enabled/disabled processors is then recorded in MPS table <b>241</b> of feature set <b>24</b>.

[0023] In certain scenarios, if any of the specified processors fail in the above multiple-processor embodiments, BIOS <b>22</b> can detect these failed processors and enable spare processors to ensure the correct number of processors being enabled whenever possible.

[0024] Other optional system features that can be controlled by the BIOS-based control mechanism include, e.g., amount of system memory, number of powered PCI slots, speed of processors, speed of specific PCI buses, as well as enabling serviceability features, embedded PCI devices such as SCSI (Small Computer System Interface), video, LAN (Local Area Network), peripheral ports such as parallel, USB (Universal Serial Bus) keyboard, mouse, hot-plug PCI, and hot-plug CPU or memory nodes. Even OS level application features can be enabled by the BIOS-based control mechanism in a substantially the same manner. Although some of these features can be enabled directly from system <b>10</b> without the feature packets from the OEM, some of the features are so complicated that direct enabling may be infeasible. These complicated features are generally implementation-specific so that a third party agent, e.g., a computer distributor, cannot practically enable the system features without detailed knowledge of the hardware. Therefore, the BIOS-based control mechanism for enabling optional system features, as described above, also has an advantage for simplifying configuration procedures for the parties that do not possess comprehensive knowledge of the hardware.

[0025] Other embodiments are within the scope of the following claims.