CN107924439B

CN107924439B - Apparatus, method, and computer program product for coordinating device boot security

Info

Publication number: CN107924439B
Application number: CN201580082636.8A
Authority: CN
Inventors: 姚颉文; V·J·齐默
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2015-09-24
Filing date: 2015-09-24
Publication date: 2022-01-14
Anticipated expiration: 2035-09-24
Also published as: WO2017049539A1; EP3353699A4; EP3353699A1; CN107924439A

Abstract

Various embodiments are generally directed to techniques for coordinating the formation of a chain of trust between components of a processing device. An apparatus may include a processor component including verification microcode to authenticate a verification routine based on a first security credential to create a chain of trust within a processing device including the verification microcode and the verification routine; a collection register to provide, when read, a hash value of one or more values written to the collection register since initialization of the processing device; and a verification component of the verification routine to determine a selected security level of the initialization and verify the firmware based on the second security credentials based on the selected security level to extend the trust chain to include the firmware and store an indication of a result of an attempted authentication of the firmware in a collection register.

Description

Apparatus, method, and computer program product for coordinating device boot security

Background

The initialization process for booting a processing device for use may be subject to different security requirements. Government and/or corporate entities may require higher levels of security to protect confidential information, including information about people (e.g., people records, customer information, etc.) and/or information about activities associated with these entities (e.g., intellectual property, aspects of an ongoing project, etc.). To accommodate such higher security levels, various mechanisms may be implemented during initialization to enforce the use of only trusted executable routines (e.g., firmware, operating systems, application routines, etc.).

However, individuals may not need and/or may not want to implement such higher security levels on their processing devices for their personal use. For example, an individual may wish to have the following flexibility: any of a variety of executable routines can be obtained and installed on such a processing device that may be disqualified from one or more of the executable routines for being deemed trusted.

Drawings

Fig. 1A and 1B each illustrate an example embodiment of a secure processing system.

FIG. 2 illustrates an example embodiment of provisioning security credentials to components of a processing device.

Fig. 3 illustrates an example embodiment of receiving an indication of a selected security level.

Fig. 4A and 4B together illustrate an example embodiment of an authentication verification routine.

FIG. 5 illustrates an example embodiment of selectively authenticating at least one firmware.

FIG. 6 illustrates an example embodiment of a collection register.

FIG. 7 illustrates an example embodiment of an operating system or application routine that analyzes a trust chain.

Fig. 8A, 8B, and 8C together illustrate a logic flow according to an embodiment.

Fig. 9 illustrates another logic flow in accordance with an embodiment.

Fig. 10 illustrates a processing architecture according to an embodiment.

Detailed Description

Various embodiments are generally directed to techniques for coordinating the formation of a chain of trust between components of a processing device to more easily accommodate changes to one of these components. At least during initialization of the processing device, the validation microcode incorporated into its processor components may attempt to authenticate validation routines stored within other storage devices of the processing device. After successfully authenticating the verification routine to form an initial portion of the trust chain, the processor component may execute the verification routine to retrieve an indication of a level of security to be implemented between the processor component and one or more executable routines in the processing device. The security level may be any one of a number of security levels, including but not limited to: the method may further include enforcing a requirement that the plurality of executable routines be verified to and include a relatively high security level of the firmware, forgoing a relatively low security level of the one or more authentication checks, and/or a medium security level between the high security level and the low security level, including attempting to authenticate the one or more executable routines while maintaining a secure record of the results. The security level may be allowed to be set by an operator of the processing device for any of a variety of reasons, including allowing the firmware in those executable routines to be replaced with another firmware that may not be authenticated. In this way, a relatively high security level may be selected in which the processing device is operated in an environment that requires increased resistance to malware (e.g., malicious programs such as viruses, worms, etc.). Optionally, in this way, a lower security level may be selected to allow individual operators more control over various aspects of the processing device in situations where such increased resistance to malware is deemed less important.

In some of these embodiments, one or more components of the processing device may be selected to conform to aspects of the IA-32 architecture promulgated by Intel corporation of Santa Clara, Calif. and/or aspects of the unified extensible firmware interface promulgated by the UEFI Forum of Bifton, Oreg. In such an embodiment, the processor component may be one of the Pentium (Pentium), Itanium (Itanium), or Core family of processor components of Intel corporation, the verification microcode may be incorporated into the processor component during manufacture by Intel corporation, the verification routine may be an Authentication Code Module (ACM) provided by Intel corporation, the firmware may be a basic input/output System (BIOS) provided by any of a variety of sources, and the operating system may be a version of Windows from Microsoft corporation of Redmond, Washington, or a version of Linux provided by a variety of sources.

More specifically, during manufacture of a processor component to be incorporated into a processing device, authentication microcode and at least one security credential may be incorporated into the processor component. The validation microcode may cause the processor component to, upon initialization within the processing device, retrieve a validation routine that may be stored within the processing device, and attempt to authenticate the validation routine as authentic using at least one security credential. Initialization of the processing device may be triggered by events such as power-up of the processing device, software-triggered and/or hardware-triggered resets, and the like. In some embodiments, the at least one security credential may be a cryptographic key, a digital signature intended for use in authenticating the verification routine (or a hash thereof). Other types of security credentials and/or other mechanisms may be used to authenticate the verification routine in other embodiments. If the verification microcode fails to authenticate the verification routine, the processor component may cease taking any further action to initialize the processing device and/or may take action to render the processing device inoperable as part of protecting the processing device.

However, if the verification microcode is able to authenticate the verification routine, the processor component may execute instructions of the verification routine to retrieve an indication of the level of security to be implemented during initialization. The indication may be retrieved as one or more bit values stored in a register and/or in a storage location at a particular address within a storage device of the processing device. In some embodiments, the security level may be selected by an operator of the processing device through a User Interface (UI) provided by the processor component, wherein the UI may allow the operator to use manually operable controls (e.g., a keyboard and/or a mouse) in order to select the security level. In other embodiments, the security level may be selected by an operator using a jumper carried by a circuit board of the processing device that may be moved to one of a plurality of positions that may each represent a different selectable security level.

In some embodiments, where a relatively high security level has been selected, the processor component may also execute instructions of a verification routine to attempt to authenticate the firmware as authentic using at least one other security credential. The at least one other security credential may be a digitally signed encryption key intended for authenticating the firmware (or a hash of the firmware) or another type of security credential in a different mechanism for authenticating the firmware. If the verification routine is unable to authenticate the firmware, the processor component may cease taking any further action to initialize the processing device and/or may take action to render the processing device inoperable as part of protecting the processing device.

However, if the verification routine is capable of authenticating the firmware, the processor component may store a value in the collection register that indicates successful authentication of the firmware. The collection register may combine all values written thereto since initialization of the processing device began. When read, the gather register may not provide any values written to it. Instead, the collection register may provide a hash value derived from a hash resulting from a combination of all values that have been written to the collection register since the last initialization of the processing device. Thus, during subsequent execution of instructions of the operating system or application routines by the processor component, the collection register may be read to retrieve the hash value, and the hash value may be checked to verify that the firmware is successfully authenticated as authentic, enabling the operating system and/or application routines to trust the firmware. Thus, such use of collection registers may provide verification that a chain of trust is formed in advance between the processor components, the verification microcode, the verification routine, and the firmware. The operating system and/or application routines may rely on verification of the formation of such a chain of trust to determine whether to initialize and/or make one or more features thereof available. Furthermore, the reliance of the operating system and/or application routines on such verification may be used to extend the trust chain to include the operating system and/or application routines.

Alternatively or additionally, where a relatively high security level has been selected but the verification routine is unable to authenticate the firmware, the processing component may further execute the verification routine to attempt to authenticate the replacement firmware rather than taking action to render the processing device inoperable. The replacement firmware may support a similar range of functionality as the firmware that cannot be authenticated, or may provide a more limited range of functionality to enable an operator of the processing device to perform actions to correct the lack of capability to authenticate the firmware.

In some embodiments, where a relatively low level of security has been selected, the processor component may avoid further executing instructions of the verification routine to attempt to authenticate the firmware. However, the processor component may store a value in the collection register indicating that no such authentication attempt was made. This may enable subsequent reading of the generation of a hash value from the collection register that indicates to the operating system and/or application routine that no attempt was made to verify the firmware. Thus, the resulting hash value may be used as an indication that a chain of trust is only formed between the processor component and the verification routine, but does not include the firmware so that it is not known whether the firmware is trusted or not. The operating system and/or application routines may rely on the indication that the chain of trust does not include firmware to determine whether to initialize and/or make one or more features thereof available.

In some embodiments, where a medium level of security between the low and high security levels has been selected, the processor component may attempt to authenticate the firmware and may store an indication of the outcome of the attempt in a collection register. The processor component may then proceed to retrieve at least a portion of the operating system and execute its instructions to initialize the operating system, regardless of the outcome of the attempt to authenticate the firmware. Again, the operating system and/or application routines may rely on hash values read from the collection registers, which may indicate successful or unsuccessful attempts to authenticate the firmware to determine whether to initialize and/or make one or more features thereof available.

In various embodiments, regardless of the security level selected and the firmware can be authenticated, the processor component may execute instructions of the firmware to attempt to authenticate the operating system. If the operating system can be authenticated, the processor component may store another value to the gather register indicating that the operating system can be authenticated. A hash value resulting from a hash of a combination of at least a value representing a successful authentication of the firmware and other values representing a successful authentication of the operating system may be read by the application routine and relied upon to determine whether to initialize or make available one or more features thereof. Thus, in this manner, the chain of trust may be extended to include an operating system in addition to the processor components, validation microcode, validation routines, and firmware.

With general reference to the symbols and terms used herein, portions of the detailed description that follows may be presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

Further, these operations are often referred to as terms such as adding or comparing, which are often associated with psychological operations performed by human operators. However, in any of the operations described herein that form part of one or more embodiments, such capability of a human operator is not necessary or desirable in most cases. Rather, these operations are machine operations. Useful machines for performing the operations of the various embodiments include general purpose digital computers selectively activated or configured by a computer program stored therein, written in accordance with the teachings herein, and/or including apparatus specially constructed for the required purposes. Various embodiments are also directed to an apparatus or system for performing these operations. These means may be specially constructed for the required purposes, or may comprise a general purpose computer. The required structure for a variety of these machines will appear from the description given.

Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the novel embodiments may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate description. The intention is to cover all modifications, equivalents, and alternatives falling within the scope of the claims.

Fig. 1A illustrates a block diagram of an embodiment of a secure processing system 1000 incorporating one or more credential devices 100, one or more remote storage devices 400, and/or a processing device 500. In the secure processing system 1000, one or more matching sets of security credentials may be provided by one or more credential devices 100 for use by one or more pairs of components of the processing device 500 to enable one or more portions of a chain of trust to be formed therebetween during initialization of the processing device 500. One or more executable routines for these components may be provided to the processing device 500 by one or more remote storage devices 400.

As depicted, at least one or more of the remote storage device 400 and the processing device 500 may exchange such executable routines through the network 999. Moreover, one or more of these exchanged executable routines may be exchanged in encrypted form to prevent reading and/or modification thereof. However, one or more of these devices may exchange other data completely unrelated to the initialization processing device 500 with each other and/or with other devices (not shown) via the network 999. In various embodiments, the network 999 may be a single network that may be limited to extending within a single building or other relatively limited area, a combination of connected networks that may extend a substantial distance, and/or may include the Internet. Thus, the network 999 may be based on any of a variety (or combination) of communication technologies through which signals may be exchanged, including but not limited to wired technologies that employ electrical and/or optical cables, and wireless technologies that employ infrared, radio frequency, or other forms of wireless transmission.

In various embodiments, the processing device 500 may contain a processor component 550, a storage device 560, a support component 570, a jumper 510, manually-operable controls 520, a display 580, and/or a network interface 590 that couples the processing device 500 to the network 999. The processor component 550 may include microcode to control various aspects of its operation, including validating the microcode 551. The support component 570 may provide various forms of hardware-implemented support logic to the processor component 550, such as a bus interface between the processor component 550 and one or more other components of the processing device 500. More specifically, as shown, support component 570 may contain a set register 575, and in some embodiments, set register 575 may provide processor component 550 with an indication of the current state of jumper 510 (if present). As also shown, the processor component 550 or the support component 570 may contain one or more collection registers 555a and/or 555 b.

Storage 560 may store an authentication routine 542, firmware 543, Operating System (OS)544, one or more application routines 545, and an event log 539. As shown, the storage device 560 can include a removable storage medium 569 (e.g., an optical disk, a solid state memory device, and/or a hard drive, etc. that is removable from the housing of the processing device 500) from which one or more of the

executable routines

542 and 545 can be copied to another portion of the storage device 560 that may not be based on a removable storage medium (e.g., a solid state memory and/or a hard drive incorporated into the housing of the processing device 500). Alternatively or additionally, one or more

executable routines

542, 545 may be retrieved from one or more remote storage devices 400 via the network 999 and the network interface 590. As also depicted, the verification routines 542 and/or firmware 543 may be stored in non-volatile storage 562 (e.g., one or more FLASH (FLASH) storage devices) based on storage technologies that allow their content to be overwritten, but retain such content during times when power is not applied. As will be explained in more detail, an operator of computing device 500 may leverage this capability to overwrite the contents of non-volatile storage device 562 to replace firmware 543 with replacement firmware (not shown) that, unlike firmware 543, may not be able to be authenticated, and such an operator may use removable storage media 569 and/or one or more remote storage devices 400 to achieve this replacement.

The validation microcode 551, validation routine 542, firmware 543, OS 544, and/or one or more application routines 545 may each comprise sequences of instructions that operate on the processor component 550 to implement logic to perform various functions. As will be explained in more detail, the processor component 550 may attempt to form a chain of trust between the processor component 550 and at least the validation microcode 551 and/or the validation routine 542 (using security credentials that may be provided by one or more credential devices 100) when it executes at least the validation microcode 551. More specifically, execution of the validation microcode 551 may cause the processor component 550 to attempt to authenticate the validation routine 542, and assuming such authentication is successful, execution of the validation routine 542 may cause the processor component 550 to attempt to authenticate the firmware 543. Further, in some embodiments, if authentication of firmware 543 is also successful, execution of firmware 543 can cause processor component to attempt to authenticate OS 544.

FIG. 1B shows a block diagram of an alternative embodiment of a secure processing system 1000 that includes an alternative embodiment of a processing device 500. As depicted, an alternative embodiment of the processing device 500 may include a security controller 600 that includes a processor component 650. The processor component 650 may operate as a controller processor in a controller processing environment within the security controller 600 that is separate from a main processing environment in which the processor component 550 may operate as a main processor component of the processing device 500. Such separation may render the controller processing environment of the processor component 650 inaccessible to malware (e.g., "malware") that may infiltrate the main processing environment of the processor component 550. This may enable the processor component 650 to perform various security-related functions, at least to the extent that such functions are not disturbed by malware present in the main processing environment.

Security controller 600 may also include collection registers 555a and/or 555b in place of either processor component 550 or support component 570 to do so, and/or may also include setting registers 575 in place of support component 570 to do so. As also shown, the processor component 650 may include validation microcode 551 to do so in place of the processor component 550. Thus, in the depicted alternative embodiment of the processing device 500, it may be the processor component 650 of the security controller 600 executing the validation microcode 551 instead of the processor component 550. In this manner, the verification routine 542 may be attempted to be authenticated by the processor component 650 as trustworthy from within the more secure controller processing environment to form an initial portion of the trust chain between the processor component 550, the verification microcode 551 and the verification routine 542.

Referring to fig. 1A and 1B, whether the

processor component

550 or 650 executes the validation microcode 551 to begin forming the chain of trust by attempting to authenticate the validation routine 542, such authentication may require the use of security credentials provided by one or more credential devices 100. Additionally, the security level to be implemented during initialization in order to form a chain of trust may be selected in advance through the use of jumper 510 or a user interface employing one or both of control 520 and display 580.

FIG. 2 depicts aspects of providing matching security credentials to enable attempts to form and extend a chain of trust between components of a processing device 500. As depicted, each of the validation microcode 551, validation routine 542, firmware 543, and OS 544 can be generated using a different authoring device 200. Each authoring device 200 may be a server or other form of computing device executing a compiler and/or other tools for generating executable routines to produce respective ones of these

executable routines

551, 542, 543, and/or 544.

As will be familiar to those developing components of processing devices, various hardware and software components of the processing device 500 may be provided for inclusion within the processing device 500 with little or no coordination between them by different entities (e.g., different corporate, educational and/or governmental entities), including such components as each of the processor components 550 and/or 650, and/or each of the

executable routines

551, 542, 543 and/or 544. Thus, different entities may own and operate different ones of the depicted authoring facility 200 to develop and generate different ones of the

executable routines

551, 542, 543, and/or 544, respectively. Again, as an example, the

processor component

550 or 650 and the validation microcode 551 and/or validation routines 542 may be provided by intel corporation of santa clara, california, while the firmware 543 may be provided by any of a variety of entities, and the OS may be provided by microsoft corporation of redmond, washington, or any of a variety of entities providing a version of Linux.

However, as will be familiar to those skilled in the art, while the mere assembly of components from different source entities into a processing device may be performed with little or no coordination between them, providing one component provided by one such source entity with the ability to authenticate another component provided by another such source entity does generally require at least some degree of coordination between the entities, at least to the extent that the sources (e.g., encryption keys, seed values, etc.) of the security credentials used in such authentication are consistent. As a result, and as depicted, the matching security credential sets may be provided to different authoring devices 200 associated with different ones of the generating

executable routines

551, 542, 543, and/or 544 to enable such authentication therebetween.

More specifically, and by way of illustration, to enable the validation microcode 551 to authenticate the validation routine 542, the matched

security credentials

512a and 512b may be provided to different authoring facilities 200 associated with generating each of the two

executable routines

551 and 542. In some embodiments, the security credential 512a provided to the authoring device 200 used in generating the verification microcode 551 may include an encryption key to be embedded within the verification microcode 551 (or otherwise included alongside the verification microcode 551). Accordingly, the security credentials 512b provided to the authoring device 200 for use in generating the validation routine 542 may include a matching encryption key by which the validation routine 542 (or a hash thereof) may be digitally signed when the validation routine 542 is generated to enable the validation routine 542 to be authenticated by the validation microcode 551 using the encryption key of the security credentials 512 a. Again, and as will be discussed in greater detail, successful authentication of the validation routine 542 by the validation microcode 541 may enable an initial portion of a chain of trust to be formed between the processor component 550, the validation microcode 551, and the validation routine 542.

Accordingly, and as another example, to enable the verification routine 542 to authenticate the firmware 543, the matched

security credentials

523a and 523b may be provided to different authoring devices 200 associated with generating each of the two

executable routines

542 and 534 b. In some embodiments, the security credentials 523a provided to the authoring device 200 used in generating the validation routine 542 may include an encryption key to be embedded within the validation routine 542 (or otherwise included alongside the validation routine 542). Accordingly, the security credential 523b provided to the authoring device 200 for use in generating the firmware 543 may include a matching encryption key by which the firmware 543 (or a hash thereof) may be digitally signed at the time of generation of the firmware 543 to enable authentication of the firmware 543 by the verification routine 542 using the encryption key of the security credential 523 a. As will be discussed in more detail, successful authentication of the firmware 543 by the verification routine 542 can enable the extension of the trust chain already existing in the processor component 550, the verification microcode 551, and the verification routine 542 to then include the firmware 543.

As further depicted, similarly matched

security credentials

534a and 534b may be provided to the authoring device 200 associated with generating firmware 543 and OS 544 to enable firmware 543 to authenticate OS 544. It should be noted that any of each of the matching security credential sets 512a and 512b, 523a and 523b, and 534a and 534b may be provided by different credential devices 100, which different credential devices 100 are owned and operated by different entities, or may be owned and operated by a single entity agreed upon by all of the entities providing the different

executable routines

551, 542, 543, and 544. Alternatively, a single credential device 100 owned and operated by a single entity generates and provides all of these security credentials. It should also be noted that although the above examples specifically discuss using a matching key as a security credential, any of a variety of other types of security credentials (e.g., hashes, hash values, certificates, seeds for random number generation, etc.) intended for use with any of a variety of types of authentication techniques may be used in various embodiments.

As further depicted, a copy of the validation microcode 551, along with the security credential 512a, may be provided to the

processor component

550 or 650 by the provisioning apparatus 300. The provisioning apparatus 300 may be incorporated into the operation of a manufacturing facility in which the processor assemblies 550 and/or 650 are manufactured. More specifically, a copy of the validation microcode 551 may be incorporated into the

processor component

550 or 650 along with the security credential 512a prior to incorporating the

processor component

550 or 650 into the processing device 500. As an example, the provisioning apparatus 300 may be electrically coupled to one or more pins carried on a package housing of a semiconductor die in which the

processor assembly

550 or 650 is contained to provide the authentication microcode 551 and the security credential 512a thereto prior to connecting the

processor assembly

550 or 650 to a circuit board of the processing apparatus 500.

As previously discussed, an operator of processing device 500 may attempt to replace firmware 543 with replacement firmware (not shown) that may not include

security credential

523b or 534a and/or may not be generated in any manner including a digital signature, a digital signature hash, or any other security feature generated using security credential 523 b. As a result, processor component 550 may not be able to authenticate such alternative firmware when executing validation routine 542, and processor component 550 may not be able to authenticate OS 544 when executing such alternative firmware. Thus, as a result of replacing firmware 543 with such replacement firmware, it may not be possible to form a chain of trust that extends beyond processor component 550, validation microcode 551, and validation routine 542.

FIG. 3 depicts aspects of receiving and storing an indication of a selected level of security to be implemented in generating a trust chain between at least a processor component 550, a validation microcode 551, and a validation routine 542. The setting register 575 may store a bit, byte, word, or other type of value that indicates a selected security level.

In some embodiments, by using the jumper 510, an operator of the processing device 500 may provide an indication of the selection of the security level. The jumper 510 may be a conductive component that may be manually positioned among a plurality of conductive pins carried by a circuit board of the processing device 500 to selectively short two of the pins to select from at least two settings. In some embodiments, a selection between a higher security level and a lower security level may be made by the presence or absence of jumper 510 at the location where the two pins are shorted. In other embodiments, the selection of the security level may be made based on which pair of pins of the plurality of pins is shorted. The indication of the selection of the security level made by such use of the jumper 510 may then be latched and stored by the setting register 575 for subsequent retrieval by the processor component 550. It should be noted, however, that although such use of the jumper 510 is specifically discussed and depicted as such, other manually operated mechanisms may be used, including but not limited to rotary selector switches (e.g., binary coded rotary selector switches), slide switches, two-column in-line position (DIP) switches, separable wire loops, pads on a circuit board that may be selectively electrically bridged with a plurality of wires, and the like.

In other embodiments, one or more of firmware 543, OS 544, and application routines 545 can include a configuration component 548 to provide a User Interface (UI) through which an operator of processing device 500 can select a security level. More particularly, the processor component 550 can be caused to execute the configuration component 548 in executing a portion of at least one of the firmware 543, the OS 544, and/or the application routines 545. In so doing, the processor component 550 may be caused to operate the display 580 to present a UI that may include a menu of different security levels selectable by an operator, and the processor component 550 may be caused to monitor manually operable controls 520 (e.g., a keyboard and/or a pointing device such as a mouse) for indications of their operation to provide indications of selection of security levels. Processor component 550 may then store the indication in setting register 575. It should be noted that the setting register 575 may be implemented with a non-volatile storage component capable of maintaining therein an indication of a selected security level despite an instance of the processing device 500 being powered down and/or disconnected from any external power source.

Returning to FIGS. 1A and 1B, the

processor component

550 or 650 may be initialized as a result of a power-up of the processing device 500 (e.g., due to the beginning of power supply to the processing device 500) and/or as a result of a reset of the processing device 500 triggered by hardware-based logic (e.g., the support component 570) or by software (e.g., one of the executable routines 542 and 545). In response to such initialization, the

processor component

550 or 650 may execute the validation microcode 551, which may cause the processor component 550 to retrieve and attempt to authenticate the validation routine 542 as authentic.

Together, fig. 4A and 4B illustrate aspects of such execution of the validation microcode 551 by either of the

processor components

550 or 650 to authenticate the validation routine 542. FIG. 4A illustrates aspects of authentication of a verification routine 542, and FIG. 4B illustrates aspects of an example of retrieving at least a portion of the verification routine 542. As shown in FIG. 4A, the validation microcode 551 may include one or both of a retrieval component 5511 and a validation component 5512. Thus, execution of the validation microcode 551 by the

processor component

550 or 650 may require execution of one or both of its components 5511 and 5512.

In some embodiments, an address at which the validation routine 542 is accessible within the storage 560 may be embedded (e.g., hard-coded) within the validation microcode 551, such that the processor component 550 or 650 (at least by default) attempts to access at least the validation routine 542 at that address. In such embodiments, the

processor component

550 or 650 may execute the instructions of the verification component 5512 to access at least a portion of the verification routine 542 where the security credential 512b may be found or where a signature, hash, or other security credential derived from the security credential 512b may be found. The verification component 5512 may then attempt to authenticate the retrieved security credential using the accompanying verification microcode 551 or the security credential 512a directly embedded therein.

In other embodiments, it may be desirable to access a trace (trail) of one or more pointers to the validation routine 542 within the storage 560 and then determine the address at which the validation routine 542 is stored within the storage 560. In such other embodiments, the

processor component

550 or 650 may execute instructions of the retrieval component 5511 to access a first such pointer within the storage 560 that may be embedded (e.g., hard-coded) at an address within the validation microcode 551. It may be that the first pointer is at the head of a trace of multiple pointers to the address of the validation routine 542, or that the first pointer directly indicates the address of the validation routine 542. Regardless of how many pointers make up such a trace, the retrieval component 5511 may provide the verification component 5512 with a direct address found at the end of the trace of the verification routine 542 to enable the verification component 5512 to attempt to authenticate the verification routine 542.

Fig. 4B depicts an example of such tracking in an embodiment in which one or more aspects of the processing device 500 are configured to conform to aspects of the IA-32 architecture promulgated by intel corporation of santa clara, california and/or aspects of the unified extensible firmware interface promulgated by the UEFI forum of bifenthon, oregon. In such embodiments, portions of storage 560 may be mapped to portions of addresses of a four gigabyte range, with security level data 541, validation routine 542, firmware 543, and table pointer 566 mapped to the upper end of the four gigabyte address range. Table pointer 566 may point to the starting address of table 5430, which may be embedded within a portion of firmware 543. Table 5430 may include a plurality of pointers, including at least one firmware pointer 5433 to a starting address of at least firmware 543, a verification routine pointer 5432 to a starting address of verification routine 542, and a security level pointer 5431 to a starting address of security level data 541.

In this example, the retrieval component 5511 may first access the table pointer 566, which may be embedded within the validation microcode 551 at an address having a four gigabyte address range. The retrieval component 5511 may then proceed to the starting address of the table 5430 pointed to by the table pointer 566. The retrieval component 5511 may then proceed to a verification routine pointer 5432, the verification routine pointer 5432 may be located at an offset within the table 5430 from the starting address of the table 5430, which table 5430 may also be embedded within the verification microcode 551. The retrieval component 5511 may then instruct the verification component 5512 to access the verification routine 542 at the starting address pointed to by the verification routine pointer 5432 to begin attempting to authenticate the verification routine 542.

Returning to FIG. 4A, if the verification routine 542 cannot be authenticated by the verification component 5512, in some embodiments, the

processor component

550 or 650 may be caused to refrain from performing any further operations to initialize the processing device 500 and/or may take actions to render the processing device 500 inoperable and/or to render data stored within the processing device 500 inaccessible. Alternatively or additionally,

processor component

550 or 650 can be caused to operate control 520 and/or display 580 to present an indication of the error condition to an operator of the processing device.

However, if the verification routine 542 is verifiable by the verification component 5512, the

processor component

550 or 650 can be caused to begin executing the verification routine 542. As already discussed, in the event of successful authentication of the validation routine 542, at least an initial portion of the chain of trust is formed between the processor component 550, the validation microcode 551 and the validation routine 542. In the example embodiment of FIG. 1A, executing the validation microcode 551 is the processor component 550, and the processor component 550 may simply transition from executing the validation microcode 551 to executing the validation routine 542. However, in the example embodiment of FIG. 1B, executing the validation microcode 551 is the processor component 650, and the processor component 650 may signal the processor component 550 to begin executing the validation routine 542.

Returning to fig. 1A and 1B, regardless of the exact manner in which the processor component 550 is caused to begin executing the authentication routine 542, the processor component may retrieve an indication of the security level that has been selected to be implemented during initialization of the processing device 500. Depending on the security level selected, processor component 550 may or may not attempt to authenticate firmware 543, and depending on the result of such attempted authentication (if attempted), processor component 550 may or may not execute firmware 543 (or substitute firmware, if any).

Fig. 5 depicts aspects of the verification routine 542 being executed by the processor component 550 to determine a selected security level and to selectively authenticate and/or initiate execution of at least the firmware 543. As shown, the verification routine 542 can include one or both of a verification component 5422 and a selection component 5423. Thus, execution of the verification routine 542 by the processor component 550 may require execution of one or both of the components 5422 and 5423 thereof.

The processor component 550 may execute instructions of the verification component 5422 to access from the setting registers 575 and retrieve from the setting registers 575 an indication of the level of security that has been selected to be implemented during initialization of the processing device 500. In some embodiments, the verification component 5422 may store a bit value, byte value, word value, or another bit width value in the collection register 555a that indicates the selected security level. As will be explained in greater detail, one or more of the OS 544 and/or the application routines 545 may at least subsequently read the collection register 555a to obtain a hash of all values written to the collection register 555a since initialization, including a value indicative of a selected security level written thereto by the verification component 5422.

Having selected a relatively high level of security, processor component 550 may further execute instructions of verification component 5422 to attempt to authenticate firmware 543 as authentic using security credential 523 a. More particularly, processor component 550 may execute instructions of verification component 5422 to access at least a portion of firmware 543 (which may discover security credential 523b or which may discover a signature, hash, or other security credential derived from security credential 523 b). Verification component 5422 may then attempt to authenticate firmware 543 by attempting to authenticate the retrieved security credentials using accompanying verification routine 542 or security credentials 523a embedded directly therein.

If the firmware 543 cannot be authenticated by the verification component 5422, in some embodiments, the processor component 550 may be caused to refrain from performing any further operations to initialize the processing device 500 and/or may take actions to render the processing device 500 inoperable and/or to render data stored within the processing device 500 inaccessible. Alternatively or additionally,

processor component

550 or 650 can be caused to operate control 520 and/or display 580 to present an indication of the error condition to an operator of the processing device. However, if the verification routine 5422 is able to authenticate the firmware 543, the processor component 550 may continue to execute instructions of the firmware 543 to continue initialization of the processing device 500. In some embodiments, processor component 550 may also store a value in collection register 555b that provides an indication that firmware 543 was successfully authenticated.

Such a relatively high level of security may be selected by an operator of the processing device 500 (where it is deemed important that the processing device 500 be highly secure against penetration and compromise by malware). The requirement that the verification routine 542 be authenticated before it is executed and then verify the high security level of the firmware 543 before it is executed is used to ensure that: if a chain of trust cannot be formed that extends from the processor component 550, through the validation microcode 551 and validation routine 542, and reaches the firmware 543, the processing device 500 will not begin execution of the OS 544 (e.g., "boot" the OS 544). Further, such storage of an indication of the selected security level in collection register 555a and an indication of successful authentication of firmware 543 in collection register 555b may enable OS 544 to verify that a high security level is selected and that firmware 543 is successfully authenticated by verification routine 542. Rather, the OS 544 may be able to determine that a chain of trust has been successfully formed under the requirements of a higher level of security, such that the OS 544 may be considered to operate in a relatively high security environment, such that the OS 544 may allow itself to be executed and/or may allow more of its features to be used. Alternatively or additionally, one or more application routines 545 may similarly access one or both of

collection registers

555a and 555b to make similar determinations as to whether it is allowed to perform and/or whether it is allowed to use more of its features.

Each of the collection registers 555a and 555b that the OS 544 and/or one or more application routines 545 may thus rely on may combine all values written thereto since the last time initialization of the processing device 500 began. When read, each collection register 555a-b may not directly provide any value written thereto. Instead, each of collection registers 555a-b may provide a hash value derived from a hash resulting from a combination of all values that have been written to processing device 500 since it was last initialized. Fig. 6 depicts in more detail aspects of the functionality of an example of each

collection register

555a and 555 b. Each of

collection registers

555a and 555b may be implemented with hardware-based gates or transistor-level logic. As previously described, the collection registers 555a and 555b may be implemented as part of the support component 570.

As depicted, each of

collection registers

555a and 555b may include a concatenation component 5551 and a hash component 5552. Cascaded assembly 5551 may store each value written to a respective one of collection registers 555a-b (in such a manner that the bits making up each such value are cascaded such that the combined bit width of the values increases with each new value). For example, if each value written to one of the gather

registers

555a or 555b has an eight-bit width of one byte, the combination of values formed from the cascaded component 5551 writing to the value of one of the gather

registers

555a or 555b is simply one byte increased in bit width as each value is so written.

The hash component 5552 of each of the collection registers 555a and 555b may take a hash of the concatenated combination of values created by the concatenation component 5551 to be provided as an output each time a respective one of the collection registers 555a or 555b is read. Therefore, neither

collection register

555a or 555b outputs any value written therein when it is read. Instead, each of the collection registers 555a and 555b, when read, outputs the hash value generated by its corresponding hash component 5552. This may help prevent malware from discovering which values have been written to either of

collection registers

555a or 555b by verification routine 542 and/or other executable routines within processing device 500. Further, in some embodiments, the output hash value may have the same bit width as the concatenated combination of all values written to the corresponding one of

collection registers

555a or 555 b.

As a result of these actions of components 5551 and 5552, obtaining a particular hash value output from one of

collection registers

555a or 555b may require that a particular combination of values be written to one of

collection registers

555a or 555b and in a particular order. Thus, any attempt by malware (causing one or the other of

collection registers

555a or 555b to output a particular hash value that erroneously indicates a secure operating environment within processing device 500) may fail because there is no way for the malware to retrieve what value has previously been written to either of

collection registers

555a or 555 b. Further, in the case of writing each value to either one of the collection registers 555a or 555b, the bit width of the hash value provided by either one is increased, which may render output operations of hash values resulting in a specific bit width impossible if the bit width has been reached or exceeded by the hash value that has currently been output.

Returning to FIG. 5, in some embodiments, OS 544 and/or one or more application routines 545 may retrieve the hash values output by each collection register 555a-b and compare these hash values to known hash values indicating a selection of a relatively high security level and a successful authentication of firmware 543 as part of determining whether any is true. In other embodiments, one or both of the hash values retrieved from collection registers 555a-b may be compared to a hash derived from a value stored elsewhere that also indicates the selected security level and/or whether authentication of firmware 543 was successful. Fig. 7 depicts aspects of an example of such a comparison in more detail.

In particular, FIG. 7 describes aspects of the collection register 555a and the event log 539 storing values indicative of a selected security level and comparing hashes subsequently taken by the OS 544 or the application routine 545. During execution of the verification routine 542, its verification component 5422 may provide the same value to whichever of the firmware 543 or the replacement firmware 543a is executed indicating the security level selected when it is stored in the collection register 555 a. Firmware 543, or alternatively one of firmware 543a, may then generate event log 539 as a mechanism to transfer various pieces of information related to the initialization of processing device 500 to OS 544, and may include the same value therein that indicates the level of security. Subsequently, the OS 544 and/or one or more application routines 545 may retrieve the value from the event log 539 and may read the hash value from the collection register 555 a. The OS 544 and/or one or more application routines 545 may then take a hash value from the event log 539 using the same hash algorithm used by the collection register 555a, and may then compare the hash value to the hash value read from the collection register 555 a. If the two hash values match, the OS 544 and/or one or more application routines 545 may treat the value retrieved from the event log 539 as a true indication of the selected security level.

Returning to fig. 5, in the event that a relatively high level of security is selected but the verification component 5422 is unable to authenticate the firmware 543, instead of ceasing further initialization of the processing device 500, the processing component 550 may execute instructions of the selection component 5423 to determine whether alternate firmware 543a is present, and if so, the processing component 550 may further execute instructions of the verification component 5422 to attempt to authenticate such alternate firmware 543 a. In some embodiments, the replacement firmware 543a may be a "rollback" form of firmware that may be used in a manner in which the firmware 543 cannot be authenticated because it has been altered or replaced, whether due to a failure or to malicious action by malware. As such a fallback form of firmware, the functionality of the replacement firmware 543a may be more limited, such that the replacement firmware 543a may cause more to be done than if an action were taken to correct the authentication failure that caused the firmware 543. Additionally, and as has been discussed previously, an operator of the processing device 500 may attempt to replace the firmware 543 with a new version of firmware 543, which new version of firmware 543 may be more desirable to the operator for any of a variety of reasons. However, the operator may have ignored the option of changing the security level to accommodate situations where the new version of firmware 543 may not be authenticated. Thus, after a failure to authenticate a new version of firmware 543, using replacement firmware 543a as such a rollback may result in a message being presented on display 580 such that the new version of replacement firmware 543 fails to authenticate, thereby alerting an operator to change security levels.

Having selected a relatively low level of security, processor component 550 may refrain from further executing instructions of verification component 5422 to attempt to authenticate firmware 543 as authentic using security credential 523 a. In some embodiments, processor component 550 may also store a value in collection register 555b that provides an indication that no attempt is made to authenticate firmware 543. In this manner, an indication may be provided to the OS 544 and/or one or more application routines 545 by both

collection registers

555a and 555 b: a relatively low security level is selected and no attempt is made to extend the chain of trust beyond the processor component 550, the validation microcode 551 and the validation routine 542. Thus, firmware 543 may or may not be trusted. The OS 544 and/or one or more application routines 545 may then determine whether each will allow it to be executed and/or whether each will allow more or less features of each to be used.

In the event that the security level is selected to be an intermediate level between the lower security level and the higher security level, processor component 550 may further execute instructions of verification component 5422 to attempt to authenticate firmware 543 as authentic using security credential 523 a. Processor component 550 may then store a value in collection register 555b that provides an indication of the result of the attempt to authenticate firmware 543, regardless of whether the attempt was successful. In this manner, an indication that a mid-level security level has been selected may be provided to the OS 544 and/or one or more application routines 545 by collection register 555a, wherein an attempt is made to authenticate the firmware 543 in an attempt to extend the trust chain beyond the processor component 550, validation microcode 551, and validation routine 542. Also, in this manner, an indication of whether the attempt to authenticate firmware 543 was successful may be provided to OS 544 and/or one or more application routines 545 through collection registers 555 b. The OS 544 and/or one or more application routines 545 may then determine whether each will allow itself to be executed and/or whether each will allow more or less features of each to be used.

An operator of the processing device 500 may select such a medium level or relatively low security level if: where flexibility in replacing one of the components, such as firmware 543, is considered more important than making the processing device 500 so highly secure against penetration and harm by malware. The lack of a requirement to authenticate firmware 543 prior to execution of firmware 543 at each of the low and medium security levels serves to ensure that an operator may replace firmware 543 with another firmware that may have one or more desired features that do not exist within firmware 543 but may not yet take advantage of the security credentials that enable such another firmware to be authenticated. It is contemplated that such an operator of processing device 500 may also choose to forgo the use of any form of OS 544 and/or any form of application routine 545 that is required to form a chain of trust that includes firmware 543. Alternatively or additionally, it is contemplated that such an operator may also choose to accept functional limitations that may be automatically imposed in the form of an OS 544 and/or in the form of one or more application routines 545 in response to firmware 543 not being included in the trust chain.

In some embodiments, aspects of one or more of a low security level, a medium security level, and/or a high security level may be defined within security level data 541. As an example, it may be specified within security level data 541 that: whether to attempt authentication of firmware 543a when a relatively low security level is selected, and/or whether to attempt authentication of replacement firmware 543a when a relatively high security level is selected. Referring briefly back to fig. 4B, in some embodiments, the security level data 541 can be stored within the storage 560 at an address specified by the security level pointer 5431, and the authentication component 5422 (or another component of the authentication routine 542) can access the security level pointer 5431 as part of accessing the security level data 541.

In various embodiments, the processor component 550 may comprise any of a variety of commercially available processors. Further, one or more of these processor components may include multiple processors, a multi-threaded processor, a multi-core processor (whether multiple cores coexist on the same or separate dies), and/or some other kind of multi-processor architecture in which multiple physically separate processors are connected to some extent.

In various embodiments, storage 560 may be based on any of a variety of information storage technologies, possibly including volatile technologies requiring the uninterrupted provision of power, and possibly including technologies requiring the use of machine-readable storage media that may or may not be removable. Thus, each of these storage devices may comprise any of a variety (or combination) of types of storage devices, including, but not limited to, read-only memory (ROM), random-access memory (RAM), Dynamic RAM (DRAM), double-data-rate DRAM (DDR-DRAM), synchronous DRAM (sdram), static RAM (sram), programmable ROM (prom), erasable programmable ROM (eprom), electrically erasable programmable ROM (eeprom), flash memory, polymer memory (e.g., ferroelectric polymer memory), ovonic memory, phase-change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, one or more individual ferromagnetic disk drives, or a plurality of storage devices organized into one or more arrays (e.g., a redundant array of independent disk arrays or a plurality of ferromagnetic disk drives organized into a RAID array). It should be noted that although each of these storage devices is described as a single block, one or more of these may include multiple storage devices, which may be based on different storage technologies. Thus, for example, one or more of each of these depicted storage devices may represent a combination of an optical drive or flash card reader (where programs and/or data may be stored and transferred on some form of machine-readable storage medium), a ferromagnetic disk drive that stores programs and/or data locally for a relatively long period of time, and one or more volatile solid-state memory devices (e.g., SRAM or DRAM) that are capable of relatively fast access to programs and/or data. It should also be noted that each of these memory devices may be made up of multiple memory components that are based on the same memory technology, but are maintained separately due to specialized uses (e.g., some DRAM devices are used as main memory devices while other DRAM devices are used as different frame buffers of a graphics controller).

In various embodiments, as described above, at least a portion of the network interface 590 may employ any of a variety of signaling techniques to enable these devices to be coupled to other devices. Each of these interfaces includes circuitry that provides at least some of the necessary functionality to achieve this coupling. However, each of these interfaces may also be implemented, at least in part, by a sequence of instructions executed by a corresponding processor component (e.g., implementing a protocol stack or other features). Where electrical and/or optical cabling is employed, these interfaces may employ signaling and/or protocols that conform to any of a variety of industry standards, including but not limited to RS-232C, RS-422, USB, Ethernet (IEEE-802.3), or IEEE-1394. Where wireless signaling is desired, these interfaces may employ signaling and/or protocols that conform to any of a variety of industry standards, including, but not limited to, IEEE 802.11a, 802.11b, 802.11g, 802.16, 802.20 (commonly referred to as "mobile broadband wireless access"); bluetooth; ZigBee; or cellular radiotelephone services such as GSM band-pass packet radio service (GSM/GPRS), CDMA/1xRTT, enhanced data rates for Global evolution (EDGE), evolution data Only/optimized (EV-DO), data and Voice evolution (EV-DV), High Speed Downlink Packet Access (HSDPA), High Speed Uplink Packet Access (HSUPA), 4G LTE, and the like.

Fig. 8A-8C illustrate an embodiment of a logic flow 2100. The logic flow 2100 may be representative of some or all of the operations executed by one or more embodiments described herein. More specifically, the logic flow 2100 may illustrate operations performed by one or both of the

processor components

550 and 560 in performing one or more of the authentication microcode 551, the authentication routine 542, and the firmware 543, and/or operations performed by other components of the processing device 500. In particular, the logic flow 2100 focuses on operations to initialize the processing device 500 for use.

At 2110, a main processor component or a controller processor component of the processing device (e.g., one of the

processor components

550 or 650 of the processing device 500) may execute verification microcode (e.g., verification microcode 551) incorporated into the processor component to attempt to authenticate a verification routine (e.g., verification routine 542) for authenticating the firmware. If the verification routine cannot be authenticated at 2112, the main processor component or controller processor component executing the verification microcode may cease any further operations of the initialization processing device at 2114. Further, the processor component may operate a display and/or another component of the processing device to provide an indication of an error in initialization of the processing device.

However, if the verification routine can be authenticated at 2112, the main processor component may execute the verification routine at 2120 to retrieve an indication of the selected security level. As has been discussed, an indication of the selected security level may have been provided to the processing device in advance, either by setting a jumper (or other similar component) or by operating a manually operable control such as a keyboard and/or mouse as part of the user interface of the configuration component executed by the main processor component. Again, the provided indication of the selected security level may then be stored in a settings register (e.g., settings register 575) and/or at a location in a storage device (e.g., storage device 560) from which the main processor component may retrieve it.

At 2122, the main processor component may store a value indicative of the selected security level within a first gather register (e.g., gather register 555 a). As described above, such a collection register may cascade multiple values written thereto, and may provide a hash of the concatenated combination of values in response to being read, thereby denying malware access to any direct indication of any value written to the collection register. As also discussed, such hash values may later be retrieved from the collection register by an OS or application routine (e.g., one of OS 544 or application routine 545) and compared to one or more hash values to determine, for example, what security level was selected.

At 2130, if the selected security level is a relatively low security level, at 2132 the main processor component may store a value in a second collection register indicating that no authentication was attempted with the firmware stored within the processing device (e.g., firmware 543). Also, at 2134, the main processor component may refrain from authenticating the firmware and may begin executing the firmware to continue initialization of the processing device.

However, if the selected security level is not a relatively low security level at 2130, but is a medium security level at 2140, the main processor component may execute a verification routine to attempt to authenticate the firmware at 2142. At 2144, the main processor component may store a value in a second collection register indicating a result of the attempt to authenticate the firmware, and may begin executing the firmware to continue initialization of the processing device regardless of the result of the attempt to authenticate the firmware.

However, if the selected security level is not a relatively low security level at 2130 and is not a medium security level at 2140, the main processor component may execute a verification routine to attempt to authenticate the firmware at 2150. At 2160, if the firmware cannot be authenticated, the main processor component may cease any further operations of the initialization processing device at 2162. Further, the main processor component may operate a display and/or another component of the processing device to provide an indication of an error in initialization of the processing device. However, if the firmware can be authenticated at 2160, then at 2164 the main processor component may store a value in the second gather register indicating successful authentication of the firmware, and the main processor component may begin executing the firmware to continue initialization of the processing device.

Fig. 9 illustrates an embodiment of a logic flow 2200. The logic flow 2200 may be representative of some or all of the operations executed by one or more embodiments described herein. More particularly, the logic flow 2200 may illustrate operations performed by the processor component 550 in executing one or more of the authentication routine 542, the firmware 543, and the replacement firmware 543a, and/or operations performed by other components of the processing device 500. In particular, the logic flow 2200 focuses on operations to initialize the processing device 500 for use.

At 2210, a processor component of a processing device (e.g., processor component 550 of processing device 500) may execute a verification routine to attempt to authenticate firmware stored within the processing device (e.g., verification routine 542 is executed to verify firmware 543). If the firmware can be authenticated 2220, then at 2222, the processor component may store a value indicating successful authentication of the firmware in a collection register (e.g., collection register 555b), and the processor component may begin executing the firmware to continue initialization of the processing device.

However, if the firmware is not authenticated 2220, then at 2230, the processor component may execute a verification routine to attempt to authenticate a replacement firmware (e.g., replacement firmware 543a) stored within the processing device. If the replacement firmware can be authenticated at 2240, the processor component may store a value indicating successful authentication of the replacement firmware in a collection register at 2242, and the processor component may begin executing the replacement firmware to continue initialization of the processing device.

However, if the firmware cannot be authenticated at 2240, then at 2250 the processor component may cease any further operations to initialize the processing device. Further, the processor component may operate a display and/or another component of the processing device to provide an indication of an error in initialization of the processing device.

Fig. 10 illustrates an embodiment of an exemplary processing architecture 3000 suitable for implementing various embodiments as previously described. More specifically, the processing architecture 3000 (or variants thereof) may be implemented as part of one or more of the

devices

100, 400, or 800. It should be noted that components of the processing architecture 3000 are given reference numerals, wherein the last two numerals correspond to the last two numerals of the reference numerals previously depicted and described as part of at least some of the components of the

devices

100, 400, and 800. This is done as an aid to the relevant components of each component.

The processing architecture 3000 includes various elements typically employed in digital processing, including, but not limited to, one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and the like. As used in this application, the terms "system" and "component" are intended to refer to an entity, either hardware, a combination of hardware and software, or software in execution, of a device in which digital processing is performed, examples of which are provided by the depicted exemplary processing architecture. For example, a component may be, but is not limited to being, a process running on a processor component, the processor component itself, a storage device (e.g., a hard disk drive, a plurality of storage drives in an array, etc.), which may employ an optical and/or magnetic storage medium, a software object, a sequence of executable instructions, a thread of execution, a program, and/or the entire device (e.g., the entire computer). By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one device and/or distributed between two or more devices. Further, the components may be communicatively coupled to each other by various types of communication media through coordinated operations. Coordination may involve one-way or two-way exchange of information. For example, a component may communicate information in the form of signals communicated over the communications media. The information may be implemented as signals assigned to one or more signal lines. A message (including a command, status, address, or data message) may be one of such signals, or may be multiple of such signals, and may be transmitted serially or substantially in parallel over any of a variety of connections and/or interfaces.

As depicted, in implementing the processing architecture 3000, the device includes at least a processor component 950, a storage device 960, an interface 990 to other devices, and a coupling 959. As will be explained, according to aspects of a device implementing the processing architecture 3000, including its intended use and/or conditions of use, such a device may further include additional components, such as, but not limited to, a display interface 985.

The couplings 959 include one or more buses, point-to-point interconnects, transceivers, buffers, cross-point switches, and/or other conductors and/or logic that communicatively couple at least the processor component 950 to the storage 960. Coupling 959 may further couple the processor component 950 to one or more of the interface 990, the audio subsystem 970, and the display interface 985 (depending on which of these and/or other components are also present). With the processor component 950 so coupled through coupling 959, the processor component 950 is capable of performing the various tasks described in detail above for any one(s) of the above devices to implement the processing architecture 3000. Coupling 959 may be implemented using any of a variety of techniques or combinations of techniques by which signals are optically and/or electrically transmitted. Further, at least a portion of the coupling 959 can employ timing and/or protocols compliant with any of a variety of industry standards, including, but not limited to, Accelerated Graphics Port (AGP), CardBus, extended industry Standard architecture (E-ISA), Micro Channel Architecture (MCA), NuBus, peripheral component interconnect (extension) (PCI-X), PCI Express (PCI-E), Personal Computer Memory Card International Association (PCMCIA) bus, HyperTransport^TMQuickPath, etc.

As previously described, processor component 950 (which may correspond to processor component 450) may comprise any of a variety of commercially available processors, implemented using any of a variety of technologies and utilizing one or more cores physically combined together in any of a variety of ways.

As previously discussed, storage 960 (which may correspond to storage 460) may be comprised of one or more different storage based on any of a wide variety or combination of technologies. More specifically, as shown, the storage devices 960 may include one or more of volatile storage 961 (e.g., solid state storage based on one or more forms of RAM technology), non-volatile storage 962 (e.g., solid state, ferromagnetic, or other storage devices that do not require a constant supply of power to hold their contents), and removable media storage 963 (e.g., removable disk or solid state memory card storage devices through which information may be transferred between devices). This depiction of storage devices 960, which may include a number of different types of storage devices, recognizes that more than one type of storage device is commonly used in devices, with one type providing relatively fast read and write capabilities, enabling faster data manipulation by processor component 950 (but possibly using "volatile" technology that continually requires power), and another type providing relatively high density non-volatile storage (but possibly providing relatively slow read and write capabilities).

In view of the often different characteristics of different memory devices employing different technologies, it is common to couple these different memory devices to other parts of the device through different memory controllers coupled to their different memory devices through different interfaces. For example, where volatile storage 961 is present and based on RAM technology, volatile storage 961 may be communicatively coupled to coupling 959 through storage controller 965a, storage controller 965a providing an appropriate interface to volatile storage 961, the volatile storage 961 may use row and column addressing, and storage controller 965a may perform row refresh and/or other maintenance tasks to help preserve information stored within volatile storage 961. As another example, where non-volatile storage 962 is present and includes one or more ferromagnetic and/or solid-state disk drives, non-volatile storage 962 may be communicatively coupled to coupling 959 through storage controller 965b, storage controller 965b providing an appropriate interface to non-volatile storage 962, which non-volatile storage 962 may employ addressing of blocks and/or columns and sectors of information. As yet another example, where a removable media storage device 963 is present and includes one or more optical and/or solid state disk drives that employ one or more machine-readable storage media 969, the removable media storage device 963 may be communicatively coupled to a coupling 959 through a storage controller 965c, providing a suitable interface to the removable media storage device 963, the removable media storage device 963 possibly employing addressing of blocks of information, and where the storage controller 965c may coordinate read, erase, and write operations in a manner specific to extending the life of the machine-readable storage media 969.

One or the other of the volatile storage 961 or the non-volatile storage 962 may include an article of manufacture in the form of a machine-readable storage medium on which routines including sequences of instructions executable by the processor component 950 may be stored, depending on the technology on which each is based. By way of example, where the non-volatile storage 962 includes ferromagnetic-based disk drives (e.g., so-called "hard drives"), each such disk drive typically employs one or more rotating disks upon which a coating of magnetically responsive particles is deposited magnetically oriented in various patterns in a manner similar to storage media such as floppy disks to store information such as sequences of instructions. As another example, non-volatile storage 962 may be comprised of a library of solid-state storage devices that store information such as sequences of instructions in a manner similar to compact flash cards. Again, it is common to use different types of storage devices in the device at different times to store executable routines and/or data. Thus, a routine comprising a sequence of instructions to be executed by the processor component 950 may be initially stored on the machine-readable storage medium 969, and the removable media storage 963 may be subsequently used to copy the routine to the non-volatile storage 962 for long term storage, without requiring the continued presence of the machine-readable storage medium 969 and/or the volatile storage 961, to enable faster access by the processor component 950 when the routine is executed.

As previously discussed, interface 990 (which may correspond to interface 490) may employ any of a variety of signaling techniques corresponding to any of a variety of communication techniques that may be used to communicatively couple a device to one or more other devices. Also, one or both of various forms of wired or wireless signaling may be employed to enable the processor component 950 to interact with input/output devices (e.g., the depicted example keyboard 920 or printer 925) and/or other devices, perhaps through a network (e.g., the network 999) or an interconnected set of networks. In recognizing the often widely disparate nature of the various types of signaling and/or protocols that any one device must often support, the interface 990 is depicted as including a plurality of

different interface controllers

995a, 995b and 995 c. The interface controller 995a may employ any of a variety of types of wired digital serial interfaces or radio frequency wireless interfaces to receive serially transmitted messages from a user input device, such as the depicted keyboard 920. The interface controller 995b may employ any of a variety of cable-based or wireless signaling, timing and/or protocols to access other devices through the depicted network 999 (which may be a network of one or more links, a smaller network, or perhaps the internet). More specifically, the interface controller 995b may contain one or more Radio Frequency (RF) transceivers and/or may be coupled to one or more antennas 991 (which may be incorporated into a portion of the interface 990) to exchange RF wireless signals with the antenna(s) of one or more other devices as part of the depicted wireless communication over the network 999. The interface 995c may employ any of a variety of conductive cabling enabling the use of serial or parallel signal transmission to transfer data to the depicted printer 925. Other examples of devices that may be communicatively coupled through one or more interface controllers of interface 990 include, but are not limited to, a microphone for monitoring a person's voice to accept commands and/or data issued by those persons via voice or other sounds they may issue, a remote control, a stylus, a card reader, a fingerprint reader, virtual reality interactive gloves, a tablet, a joystick, other keyboards, a retinal scanner, touch input components of a touch screen, a trackball, various sensors, a camera or array of cameras that monitor the movement of a person to accept commands and/or data issued by those persons via gestures and/or facial expressions, a laser printer, an inkjet printer, a mechanical robot, a milling machine, and so forth.

In the case where a device is communicatively coupled to (or may actually contain) a display (e.g., the depicted example display 980), such a device implementing the processing architecture 3000 may also include a display interface 985. While more generalized interface types may be utilized in a manner communicatively coupled to a display, the somewhat specialized additional processing often required in visually displaying various forms of content on the display, as well as the somewhat specialized nature of the cable-based interface used, often makes it desirable to provide a unique display interface. Wired and/or wireless signaling techniques that may be used by the display interface 985 in communicative coupling of the display 980 may utilize signaling and/or protocols compliant with any of a variety of industry standards, including, but not limited to, any of a variety of analog video interfaces, Digital Video Interface (DVI), DisplayPort, and so forth.

More generally, the various elements of the devices described and depicted herein may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processor components, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, Application Specific Integrated Circuits (ASIC), Programmable Logic Devices (PLD), Digital Signal Processors (DSP), Field Programmable Gate Array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, programs, software interfaces, Application Program Interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. However, determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

Some embodiments may be described using the expression "one embodiment" or "an embodiment" along with their derivatives. The terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment. Furthermore, some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and/or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. The term "coupled," however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. Furthermore, aspects or elements from different embodiments may be combined.

It is emphasized that the abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "in which," respectively. Furthermore, the terms "first," "second," "third," and the like are used merely as labels, and are not intended to impose numerical requirements on their objects.

What has been described above includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and/or methodologies, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. The detailed disclosure now turns to providing examples with respect to further embodiments. The examples provided below are not intended to be limiting.

In example 1, an apparatus comprising: a first processor component comprising verification microcode to attempt to authenticate a verification routine based on a first security credential in response to initialization of the processing device to create a trust chain within the processing device comprising at least the verification microcode and the verification routine; a first gather register to provide, when read, a first hash value of the one or more values written to the first gather register since initialization; and a verification component of the verification routine to determine a selected security level of the initialization and attempt to verify the first firmware based on the second security credentials based on the selected security level to extend the chain of trust to include the first firmware and store an indication of an attempted authentication result of the first firmware in a first collection register.

In example 2, which includes the subject matter of example 1, the first processor component may include a first security credential embedded within the verification microcode, the first security credential may include a key, the verification routine may include a digital signature generated with another key associated with the key, and the verification microcode may include a retrieval component to retrieve the verification routine and the verification microcode to attempt to match the key with the digital signature to attempt to authenticate the verification routine.

In example 3, which includes the subject matter of any of examples 1-2, the second security credential may include a key embedded within the verification routine, the first firmware may include a digital signature generated with another key associated with the key, and a verification component of the verification routine may attempt to match the key with the digital signature to attempt to authenticate the first firmware.

In example 4, which includes the subject matter of any of examples 1-3, the first processor component may refrain from performing further initialization of the processing device in response to a failure of the authentication verification routine.

In example 5, which includes the subject matter of any of examples 1-4, the first processor component may refrain from performing further initialization of the processing device in response to the selected security level comprising a relatively high security level and in response to the authentication first firmware failing.

In example 6, which includes the subject matter of any of examples 1-5, the apparatus may include a selection component of a verification routine to identify the second firmware based on the selected security level, and the verification component may attempt to authenticate the second firmware based on the second security credentials based on the selected security level to extend the chain of trust to include the second firmware and store an indication of a result of the attempted authentication of the second firmware in the first collection register.

In example 7, which includes the subject matter of any of examples 1-6, the first processor component may store an indication of a result of the attempted authentication of the first firmware in the first collection register regardless of the result, and may attempt to initialize an operating system within the processing device in response to a selected security level, including the intermediate security level.

In example 8, which includes the subject matter of any of examples 1-7, the first processor component may refrain from attempting to authenticate the first firmware, and may store in the first collection register an indication that the first firmware was not attempted to be authenticated in response to the selected security level comprising a relatively low security level.

In example 9, which includes the subject matter of any of examples 1-8, the apparatus may include an operating system to read a first hash value from a first collection register to obtain an indication of a range of the trust chain, and determine whether to allow use of a feature of the operating system based on the first hash value.

In example 10, which includes the subject matter of any of examples 1-9, the apparatus may include a second collection register to provide, when read, a hashed second hash value taken from one or more values written to the second collection register since initialization, and the verification component of the verification routine may store a value indicative of the selected security level in the second collection register.

In example 11, which includes the subject matter of any of examples 1-10, at least one of the first gather register or the second gather register may be incorporated into at least one of the first processor component and the support component to couple the first processor component to the bus.

In example 12, which includes the subject matter of any of examples 1-11, the apparatus may include an operating system to read a first hash value from a first collection register and a second hash value from a second collection register to obtain an indication of a range of the trust chain, and determine whether to allow initialization of the operating system within the processing device based on the first and second hash values.

In example 13, which includes the subject matter of any of examples 1-12, the verification component may provide a value indicative of the selected security level to the first firmware, the first firmware may generate an event log including the value and provide the event log to the operating system, and the operating system may derive a third hash value from the value in the event log and compare the second and third hash values to determine whether initialization of the operating system within the processing device is allowed.

In example 14, which includes the subject matter of any of examples 1-13, the apparatus may include a jumper operable to select at least one location of the selected security level, and a setting register accessible by the first processor component to provide, when read, an indication of the selected security level selected via the jumper.

In example 15, which includes the subject matter of any of examples 1-14, the apparatus may include: a setting register accessible by the first processor component to provide an indication of the selected security level when read, and a configuration component to operate at least one of the display or the manually operable controller to enable selection of the selected security level and to store the indication of the selected security level in the setting register.

In example 16, which includes the subject matter of any of examples 1-15, the first processor component may execute a verification routine to cause the verification component to authenticate the first firmware to extend the chain of trust to include the first firmware, and the verification microcode may create the chain of trust to include the first processor component.

In example 17, which includes the subject matter of any of examples 1-16, the apparatus may include a second processor component to execute the verification routine to cause the verification component to verify the first firmware to extend the trust chain to include the first firmware, and to verify that the microcode may create the trust chain to include the second processor component.

In example 18, an apparatus comprising: a first processor component comprising verification microcode to, in response to initialization of the processing device, attempt to authenticate a verification routine based on the first security credentials to create a trust chain within the processing device comprising at least the verification microcode and the verification routine; a verification component of the verification routine determining a selected security level of the initialization and, based on the selected security level, attempting to authenticate the first firmware based on the second security credentials to extend the chain of trust to include the first firmware and storing an indication of a result of the attempted authentication of the first firmware in a first collection register that, when read, provides a first hash value of the one or more values written to the first collection register since initialization; and a selection component of the verification routine to identify a second firmware based on the selected security level and in response to a failure to authenticate the first firmware, the verification component to attempt to authenticate the second firmware based on the second security credentials based on the selected security level to extend the chain of trust to include the second firmware, and to store an indication of a result of the attempted authentication of the second firmware in the first collection register.

In example 19, which includes the subject matter of example 18, the first processor component may include a first security credential embedded within the verification microcode, the first security credential may include a key, the verification routine may include a digital signature generated with another key associated with the key, and verifying the microcode may include a retrieval component to retrieve the verification routine, and the verification microcode may attempt to match the key with the digital signature to attempt to authenticate the verification routine.

In example 20, which includes the subject matter of any of examples 18-19, the second security credential may include a key embedded within a verification routine, the first firmware may include a digital signature that may be generated using another key associated with the key, and a verification component of the verification routine may attempt to match the key with the digital signature to attempt to authenticate the first firmware.

In example 21, which includes the subject matter of any of examples 18-20, the first processor component may refrain from performing further initialization of the processing device in response to a failure of the authentication verification routine.

In example 22, which includes the subject matter of any of examples 18-21, the first processor component may refrain from attempting to authenticate any of the first firmware or the second firmware, and may store in the first collection register an indication to not attempt to authenticate the first firmware or the second firmware in response to the selected security level comprising a relatively low security level.

In example 23, which includes the subject matter of any of examples 18-22, the apparatus may include an operating system to read the first hash value from the first collection register to obtain an indication of a range of the trust chain, and determine whether to allow use of a feature of the operating system based on the first hash value.

In example 24, which includes the subject matter of any of examples 18-23, the apparatus may include a second collection register to, when read, provide a hashed second hash value taken from one or more values written to the second collection register since initialization, and the verification component of the verification routine may store a value indicative of the selected security level in the second collection register.

In example 25, which includes the subject matter of any of examples 18-24, the apparatus may include an operating system to read a first hash value from a first collection register and a second hash value from a second collection register to obtain an indication of a range of the trust chain, and determine whether to allow initialization of the operating system within the processing device based on the first and second hash values.

In example 26, which includes the subject matter of any of examples 18-25, the verification component may provide the first firmware with a value indicative of the selected security level, the first firmware may generate an event log including the value and provide the event log to the operating system, and the operating system may derive a third hash value from the value in the event log and compare the second and third hash values to determine whether the operating system is allowed to be initialized with the processing device.

In example 27, which includes the subject matter of any of examples 18-26, the first processor component may execute a verification routine to cause the verification component to authenticate the first firmware to extend the chain of trust to include the first firmware, and the verification microcode may create the chain of trust to include the first processor component.

In example 28, which includes the subject matter of any of examples 18-27, the apparatus may include a second processor component to execute the verification routine to cause the verification component to authenticate the first firmware to extend the trust chain to include the first firmware, and to verify that the microcode may create the trust chain to include the second processor component.

In example 29, a computer-implemented method includes: in response to initialization of the processing device, executing, within the first processor component, the validation microcode to attempt to authenticate the validation routine based on the first security credentials to create, within the processing device, a trust chain including at least the validation microcode and the validation routine; in response to successful authentication of the verification routine, executing the verification routine to determine a selected security level for initialization; and in response to successful authentication and based on the selected security level, executing a verification routine to attempt to authenticate the first firmware based on the second security credentials to extend the chain of trust to include the first firmware and to store an indication of the attempted authentication of the first firmware in a first collection register that, when read, provides a first hash value of the one or more values written to the first collection register since initialization.

In example 30, which includes the subject matter of example 29, the first processor component may include a first security credential embedded within the authentication microcode; the first security credential may include a key, and the verification routine may include a digital signature generated using another key associated with the key; and the method may include retrieving the verification routine from a storage device of the processing device and attempting to match the key with the digital signature to attempt to authenticate the verification routine.

In example 31, which includes the subject matter of any of examples 29-30, the second security credential may include a key embedded in the authentication routine; the first firmware may include a digital signature generated with another key associated with the key; and the method may include attempting to match the key to the digital signature to attempt to authenticate the first firmware.

In example 32, which includes the subject matter of any of examples 29-31, the method may include: in response to a failure of the authentication verification routine, further initialization of the processing device is prevented from being performed.

In example 33, which includes the subject matter of any of examples 29-32, the method may include: in response to the selected security level comprising a relatively high security level, and in response to a failure to authenticate the first firmware, refraining from performing further initialization of the processing device.

In example 34, which includes the subject matter of any of examples 29-33, the method may include: executing a verification routine based on the selected security level to identify the second firmware; attempting to authenticate the second firmware based on the second security credentials to extend the trust chain to include the second firmware; and storing an indication of the result of the attempted authentication of the second firmware in the first gather register.

In example 35, which includes the subject matter of any of examples 29-34, the method may include, in response to a selected security level comprising a mid-level security level, executing a verification routine to store an indication of a result of the attempted authentication of the first firmware in the first collection register regardless of the result; and attempts to initialize the operating system within the processing device.

In example 36, which includes the subject matter of any of examples 29-35, the method may include: in response to the selected security level comprising a relatively low security level, an attempt to authenticate the first firmware is avoided, and a verification routine is executed to store in the first collection register an indication that no attempt to authenticate the first firmware is made.

In example 37, which includes the subject matter of any of examples 29-36, the method may include: reading the first hash value from the first gather register to obtain an indication of a range of the trust chain; and determining whether to allow use of the feature of the operating system based on the first hash value.

In example 38, which includes the subject matter of any of examples 29-37, the method may include performing a verification routine to store a value indicative of the selected security level in a second collection register, and the second collection register, when read, may provide a hashed second hash value taken from one or more values written to the second collection register since initialization.

In example 39, which includes the subject matter of any of examples 29-38, the method may include: reading the first hash value from the first collection register and the second hash value from the second collection register to obtain an indication of a range of the chain of trust; and determining whether to allow initialization of an operating system within the processing device based on the first hash value and the second hash value.

In example 40, which includes the subject matter of any of examples 29-39, the method may include executing a verification routine to provide a value to the first firmware indicating the selected security level; executing the first firmware to generate an event log comprising the value and provide the event log to an operating system; deriving a third hash value from the values in the event log; comparing the second hash value and the third hash value; and determining whether to allow initialization of an operating system within the processing device based on the comparison.

In example 41, which includes the subject matter of any of examples 29-40, the verification microcode may create a chain of trust that includes the first processor component, and the method may include executing a verification routine within the first processor component to cause authentication of the first firmware.

In example 42, which includes the subject matter of any of examples 29-41, the verification microcode may create a chain of trust to include a second processor component of the processing device, and the method may include executing a verification routine within the second processor component to cause authentication of the first firmware.

In example 43, at least one tangible machine-readable storage medium comprises instructions that, when executed by a processing device, may cause the processing device to execute, in response to initialization, verification microcode within a first processor component to attempt to authenticate a verification routine based on a first security credential to create a trust chain within the processing device including at least the verification microcode and the verification routine; in response to successful authentication of the verification routine, executing the verification routine to determine a selected security level for initialization; and in response to successful authentication and based on the selected security level, executing a verification routine to attempt to authenticate the first firmware based on the second security credentials to extend the trust chain to include the first firmware and to store an indication of attempted authentication of the first firmware in a first collection register that, when read, provides a first hash value of the one or more values written to the first collection register since initialization.

In example 44, which includes the subject matter of example 43, the first processor component may include a first security credential embedded within the verification microcode, the first security credential may include a key, the verification routine may include a digital signature generated with another key associated with the key, and the processing device may be caused to retrieve the verification routine from a storage device of the processing device and attempt to match the key to the digital signature to attempt to authenticate the verification routine.

In example 45, which includes the subject matter of any of examples 43-44, the second security credential may include a key embedded within the verification routine, the first firmware may include a digital signature generated with another key associated with the key, and the processing device may be caused to attempt to match the key with the digital signature to attempt to authenticate the first firmware.

In example 46, which includes the subject matter of any of examples 43-45, in response to a failure of the authentication verification routine, the processing device may be caused to refrain from performing further initialization of the processing device.

In example 47, which includes the subject matter of any of examples 43-46, in response to the selected security level comprising a relatively high security level and in response to a failure to authenticate the first firmware, the processing device may be caused to refrain from performing further initialization of the processing device.

In example 48, which includes the subject matter of any of examples 43-47, based on the selected security level, the processing device may be caused to identify the second firmware; attempting to authenticate the second firmware based on the second security credentials to extend the trust chain to include the second firmware; and storing an indication of the result of the attempted authentication of the second firmware in the first gather register.

In example 49, which includes the subject matter of any of examples 43-48, in response to a selected security level comprising a mid-level security level, the processing device may be caused to execute a verification routine to store an indication of a result of the attempted authentication of the first firmware in the first collection register, regardless of the result, and to attempt to initialize an operating system within the processing device.

In example 50, which includes the subject matter of any of examples 43-49, in response to the selected security level comprising a relatively low security level, the processing device may be caused to refrain from attempting to authenticate the first firmware and execute a verification routine to store in the first collection register an indication that no attempt was made to authenticate the first firmware.

In example 51, which includes the subject matter of any of examples 43-50, the processing device may be caused to read the first hash value from the first collection register to obtain an indication of a range of the trust chain, and determine whether to allow use of the feature of the operating system based on the first hash value.

In example 52, which includes the subject matter of any of examples 43-51, the processing device may be caused to execute a verification routine to store a value indicative of the selected security level in a second collection register, and the second collection register, when read, may provide a hashed second hash value taken from one or more values written to the second collection register since initialization.

In example 53, which includes the subject matter of any of examples 43-52, the processing device may be caused to read a first hash value from a first collection register and a second hash value from a second collection register to obtain an indication of a range of the trust chain, and determine whether to allow initialization of an operating system within the processing device based on the first hash value and the second hash value.

In example 54, which includes the subject matter of any of examples 43-53, the processing device may be caused to execute a verification routine to provide a value to the first firmware indicating the selected security level; executing the first firmware to generate an event log comprising the value and provide the event log to an operating system; deriving a third hash value from the values in the event log; comparing the second hash value and the third hash value; it is determined whether initialization of an operating system within the processing device is allowed based on the comparison.

In example 55, which includes the subject matter of any of examples 43-54, the verification microcode may create a chain of trust to include the first processor component, and may cause the processing device to execute a verification routine within the first processor component to cause authentication of the first firmware.

In example 56, which includes the subject matter of any of examples 43-55, the verification microcode creates a trust chain to include a second processor component of the processing device, and may cause the processing device to execute a verification routine within the second processor component to cause authentication of the first firmware.

In example 57, the at least one tangible machine-readable storage medium may include instructions that, when executed by the processor component, cause the processor component to perform any of the above.

In example 58, the apparatus may include means for performing any of the above.

Claims

1. An apparatus for secure initialization, comprising:

a first processor component comprising validation microcode to attempt to authenticate a validation routine based on first security credentials in response to initialization of a processing device to create a trust chain within the processing device, the trust chain including at least the validation microcode and the validation routine;

a first gather register to provide, when read, a first hash value of one or more values written to the first gather register since the initialization; and

a verification component of the verification routine to determine a selected security level of the initialization and, based on the selected security level, attempt to authenticate the first firmware based on second security credentials to extend the chain of trust to include the first firmware and store an indication of a result of the attempted authentication of the first firmware in the first collection register,

wherein the selected security levels include a relatively low security level, a medium security level, and a relatively high security level.

2. The apparatus of claim 1, the first processor component comprising the first security credential embedded within the verification microcode, the first security credential comprising a key, the verification routine comprising a digital signature generated with another key associated with a key, and the verification microcode comprising a retrieval component to retrieve the verification routine and the verification microcode to attempt to match the key with the digital signature to attempt to authenticate the verification routine.

3. The apparatus of claim 1, the first processor component to refrain from performing further initialization of the processing device in response to a failure to authenticate the verification routine.

4. The apparatus of claim 3, the first processor component to store an indication of a result of the attempted authentication of the first firmware in the first collection register regardless of the result, and to attempt to initialize an operating system within the processing device in response to a selected security level comprising the intermediate security level.

5. The apparatus of claim 1, comprising: a second collection register to provide, when read, a hashed second hash value taken from one or more values written to the second collection register since the initialization, and the verification component of the verification routine to store a value indicative of the selected security level in the second collection register.

6. The apparatus of claim 5, comprising an operating system to read the first hash value from the first collection register and the second hash value from the second collection register to obtain an indication of a range of the trust chain, and to determine whether to allow initialization of the operating system within the processing device based on the first hash value and the second hash value.

7. The apparatus of claim 6, the verification component to provide the value indicating the selected security level to the first firmware, the first firmware to generate an event log including the value and to provide the event log to an operating system, and the operating system to derive a third hash value from the value in the event log and to compare the second hash value and the third hash value to determine whether initialization of the operating system within the processing device is allowed.

8. The apparatus of claim 1, comprising:

a jumper operable to at least one position to select a selected security level; and

a set register accessible by the first processor component to provide, when read, an indication of the selected security level as selected via the jumper.

9. The apparatus of claim 1, comprising a second processor component to execute the verification routine to cause the verification component to authenticate the first firmware to extend the chain of trust to include the first firmware, and the verification microcode to create the chain of trust to include the second processor component.

10. An apparatus for secure initialization, comprising:

a verification component of the verification routine to determine a selected security level of the initialization and, based on the selected security level, attempt to authenticate the first firmware based on second security credentials to extend the chain of trust to include the first firmware and to store an indication of a result of the attempted authentication of the first firmware in a first collection register that, when read, provides a first hash value of one or more values written to the first collection register since the initialization; and

a selection component of the verification routine to identify second firmware based on the selected security level and in response to a failure to authenticate the first firmware, the verification component to attempt to authenticate the second firmware based on the second security credentials based on the selected security level to extend the chain of trust to include the second firmware and to store an indication of a result of the attempted authentication of the second firmware in the first collection register,

11. The apparatus of claim 10, the second security credential comprising a key embedded within the verification routine, the first firmware comprising a digital signature generated with another key associated with the key, and the verification component of the verification routine attempting to match the key with the digital signature to attempt to authenticate the first firmware.

12. The apparatus of claim 10, the first processor component to refrain from performing further initialization of the processing device in response to a failure to authenticate the verification routine.

13. The apparatus of claim 12, the first processor component refrains from attempting to authenticate either the first firmware or the second firmware, and stores in the first gather register an indication of: not attempting to authenticate either the first firmware or the second firmware in response to the selected security level comprising the relatively low security level.

14. The apparatus of claim 10, comprising an operating system to read the first hash value from the first collection register to obtain an indication of a range of the chain of trust and determine whether to allow use of a feature of the operating system based on the first hash value.

15. The apparatus of claim 10, the first processor component to execute the verification routine to cause the verification component to authenticate the first firmware to extend the chain of trust to include the first firmware, and the verification microcode to create the chain of trust to include the first processor component.

16. A computer-implemented method for secure initialization, comprising:

in response to initialization of a processing device, executing, within a first processor component, verification microcode to attempt to authenticate a verification routine based on first security credentials to create a trust chain within the processing device, the trust chain including at least the verification microcode and the verification routine;

in response to successful authentication of the verification routine, executing the verification routine to determine the initialized selected security level; and

in response to the successful authentication and based on the selected security level, executing the verification routine to attempt to authenticate first firmware based on second security credentials to extend the chain of trust to include the first firmware and to store an indication of the attempted authentication of the first firmware in a first collection register that, when read, provides a first hash value of one or more values written to the first collection register since the initialization,

17. The computer-implemented method of claim 16, the second security credential comprising a key embedded within the verification routine, the first firmware comprising a digital signature generated with another key associated with the key, and the method comprising attempting to match the key with the digital signature to attempt to authenticate the first firmware.

18. The computer-implemented method of claim 16, comprising refraining from performing further initialization of the processing device in response to a failure to authenticate the verification routine.

19. The computer-implemented method of claim 18, comprising refraining from performing further initialization of the processing device in response to a selected security level comprising the relatively high security level and in response to a failure to authenticate the first firmware.

20. The computer-implemented method of claim 18, comprising executing the verification routine based on the selected security level to:

identifying a second firmware;

attempting to authenticate the second firmware based on the second security credentials to extend the trust chain to include the second firmware; and

storing, in the first gather register, an indication of a result of the attempted authentication of the second firmware.

21. The computer-implemented method of claim 18, comprising executing the verification routine, in response to a selected security level comprising the intermediate security level, for:

regardless of the result, storing an indication of the result of the attempted authentication of the first firmware in the first gather register; and

an attempt is made to initialize an operating system within the processing device.

22. The computer-implemented method of claim 16, comprising:

reading the first hash value from the first collection register to obtain an indication of a range of the trust chain; and

determining whether to allow use of a feature of an operating system based on the first hash value.

23. The computer-implemented method of claim 16, comprising executing the verification routine to store a value indicative of the selected security level in a second collection register that, when read, provides a hashed second hash value taken from one or more values written to the second collection register since the initialization.

24. The computer-implemented method of claim 16, the verification microcode creating the trust chain to include the first processor component, and the method comprising executing the verification routine within the first processor component to cause authentication of the first firmware.

25. An apparatus for protection initialization, comprising means for performing the method of any of claims 16-24.