System and method for hardware-based register protection mechanism

This application claims the benefit of U.S. Provisional Patent Application Nos. 63/037,473 and 63/037,484, both were filed Jun. 10, 2020 and incorporated herein in their entireties by reference.

This application is related to co-pending U.S. Pat. No. 17,162,046, filed Jan. 29, 2021, which is incorporated herein in its entirety by reference.

Device security is becoming more and more important given the prevalence use and the personal nature of electronic devices. Any gap in security of an electronic device may expose the electronic device to a malicious attack. In some cases, the data and/or software (e.g., firmware) of the electronic device may be stored in internal control and state registers of the electronic device and may be accessed and updated by multiple agents of an external platform/device/system, e.g., ARM CPU cores, Power Management Controller (PMC) etc. In some cases, the internal control and state registers of the electronic device may be exposed to the external platform/device/system over one or more interfaces and thus providing an attack surface for an attacker to directly attack the electronic device or indirectly through an escalation of access privilege to the electronic device. For non-limiting examples, each of the interfaces through which the attack can be launched includes but is not limited to a Peripheral Component Interconnect Express (PCIe) interface for connecting high-speed components of the platform, and an Inter-Integrated Circuit (I2C) interface, which is a serial two-wire interface to connect low-speed devices such as microcontrollers, EEPROMs, A/D and D/A converters, I/O interfaces and other similar peripherals in the electronic device. If attacked, any micro-architecture-specific registers such as the state registers of the electronic device may cause a security issue, e.g., a Denial of Service (DOS) attack and/or leak of information of the electronic device, thus putting the electronic device in an unsafe operation or resulting in loss of intellectual properties (IPs).

Currently, register protection for the electronic device may be done by blocking read and/or write access by external devices to the internal state registers of the electronic device entirely so that the register states are not exposed externally. This may not always be feasible and may cause difficulty when it is necessary for an external device to access the registers (e.g., to update the firmware of the electronic device). In some embodiments, “shadow” registers may be created for the state registers that are vulnerable to attacks, wherein the shadow registers allows access based on the source of access. This approach, however, requires duplication of the state registers, which takes additional resources of the electronic device and may cause inconsistency issues with respect to the software or data maintained in the registers.

Aspects of the present disclosure are best understood from the following detailed description when read with the accompanying figures. It is noted that, in accordance with the standard practice in the industry, various features are not drawn to scale. In fact, the dimensions of the various features may be arbitrarily increased or reduced for clarity of discussion.

FIG. 1 depicts an example of a diagram of a hardware-based register protection mechanism according to one aspect of the present embodiments.

FIG. 2 depicts a flowchart of an example of a process to support hardware-based register protection according to one aspect of the present embodiments.

The following disclosure provides many different embodiments, or examples, for implementing different features of the subject matter. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.

Before various embodiments are described in greater detail, it should be understood that the embodiments are not limiting, as elements in such embodiments may vary. It should likewise be understood that a particular embodiment described and/or illustrated herein has elements which may be readily separated from the particular embodiment and optionally combined with any of several other embodiments or substituted for elements in any of several other embodiments described herein. It should also be understood that the terminology used herein is for the purpose of describing the certain concepts, and the terminology is not intended to be limiting. Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood in the art to which the embodiments pertain.

A new approach is proposed that contemplates systems and methods to support hardware-based protection for one or more registers of an electronic device. Under the approach, one or more sources (e.g., agents/components/processors) requesting access to the one or more registers are categorized into at least two sets—a set of internal sources that can be trusted and a set of external sources that are untrusted. The one or more registers are also classified into multiple sets—a set of internal registers that are allowed to be accessed by the internal resources only, a set of read-only external registers that can also be read by the external resources in addition to being accessed by the internal resources, and a set of read/write external registers that can be read and write accessed by both the internal and the external resources. In some embodiments, the source type and the register type can be represented by one or more source bits and one or more register classification bits, respectively. Each access request by a source to the one or more registers includes the source bits representing the source type. An arbiter is configured to accept the access request, and grant or deny read and/or write access/operation to the one or more registers by the requesting source based on the matching between the source bits in the access request and the register classification bits of the one or more registers to be accessed.

By classifying both the sources and the registers appropriately into different types respectively, the proposed hardware-based register protection mechanism ensures that only certain types of sources can have certain types of access/operation to the registers maintaining the data and/or software (e.g., firmware) of the electronic device while an untrusted source will be denied read and/or write access to the registers to prevent attacks. Furthermore, the proposed mechanism enables the same set of registers to be protected based on an extensible set of bits without having to duplicate the registers or maintain consistency among multiple set of shadow registers. The proposed mechanism still allows certain read access to the internal state registers of the electronic device when necessary without exposing all of the registers externally. Additionally, since the proposed mechanism is hardware enforced, the security of the data and/or software maintained in the registers cannot be easily compromised.

Note that firmware is mentioned below as a non-limiting example of data and/or software maintained in the registers. It is appreciated that the same or similar approach/mechanism is equally applicable to other types of data and/or resources maintained by the registers to strengthen their securities and protection.

FIG. 1 depicts an example of a diagram of a hardware-based register protection mechanism 100 . Although the diagrams depict components as functionally separate, such depiction is merely for illustrative purposes. It will be apparent that the components portrayed in this figure can be arbitrarily combined or divided into separate software, firmware and/or hardware components. Furthermore, it will also be apparent that such components, regardless of how they are combined or divided, can execute on the same host or multiple hosts, and wherein the multiple hosts can be connected by one or more networks.

In the example of FIG. 1 , the hardware-based register protection mechanism 100 includes at least one or more registers 102 s , an arbiter unit 104 , and one or more sources 106 s . Each of these components in the hardware-based register protection mechanism 100 is a dedicated hardware block/component or a software running on such hardware block/component. In some embodiments, one or more of these components are programmable by a user at a host (not shown) via software instructions for various operations. When the software instructions are executed, the one or more hardware components becomes a special purposed hardware component for practicing certain machine learning functions.

In the example of FIG. 1 , each of the one or more sources (or agents) 106 s is a hardware component or a software component running on a hardware. For a non-limiting example, one of the one or more sources 106 s can be a software component, e.g., a sideband firmware configured to make changes to and/or repair or update a firmware image of an electronic device. For another non-limiting example, one of the one or more sources 106 s can be a hardware component, e.g., a component of a processor/processing core such as an ARM core. In the example of FIG. 1 , the one or more registers 102 s are configured to store and maintain certain data including but not limited to one or more of status, information, and/or software (e.g., a firmware/firmware image) related to operations, security, and/or IP of an associated electronic device 108 , wherein the one or more sources 106 s are configured to request access to such data or software maintained in the one or more registers 102 s . Here, the electronic device can be but is not limited to a computing device, a communication device, and a storage device. In some embodiments, one or more of the registers 102 s , the arbiter 104 , and the sources 106 s reside within the electronic device 108 . In some embodiments, one or more of the registers 102 s , the arbiter 104 , and the sources 106 s reside outside of the electronic device 108 and communicate with the electronic device 108 and each other over one or more communication links and/or networks (not shown).

In some embodiments, the one or more sources 106 s are categorized into one or more of a plurality of source types including but not limited to internal sources 106 _ 1 and external sources 106 _ 2 . Here, an internal source 106 _ 1 is a source trusted by the electronic device 108 to securely access the one or more registers 102 s . For a non-limiting example, the internal source 106 _ 1 can be a trusted application processor within the electronic device 108 . For another non-limiting example, the internal source 106 _ 1 can be a secure test-port following an industrial standard, e.g., Joint Test Action Group (JTAG) for verifying designs and testing of the electronic device 108 . On the other hand, an external source 106 _ 2 is a source untrusted by the electronic device 108 to securely access the one or more registers 102 s . In some embodiments, an external source 106 _ 2 may attempt to initiate access to the one or more registers 102 s over an unsecured link or interface such as a PCIe interface or an I2C interface. In some embodiments, each of the one or more sources 106 s is assigned with one or more source bits to identify the type of the source 106 . In some embodiments, the source bits assigned to each source 106 are maintained within a hardware component (e.g., a bit register, a lock unit, or a storage unit) associated with the source 106 , wherein the hardware component cannot be modified by software to prevent hacking via malicious software. In some embodiments, the number of source bits can be adjusted dynamically (e.g., increased) at runtime to accommodate additional types of source categorization for allowable register read and/or write access requests.

In some embodiments, the one or more registers 102 s are also classified into one or more of a plurality of register types including but not limited to a set of internal registers 102 _ 1 , a set of read-only external registers 102 _ 2 , and a set of read/write external registers 102 _ 3 . Here, each of the internal registers 102 _ 1 allows read and write access by the internal sources 106 _ 1 only. None of the external sources 106 _ 2 is allowed to have read to write access (operation) to the internal registers 102 _ 1 . Like the internal registers 102 _ 1 , each of the read-only external registers 106 _ 2 allows read and write access by the internal sources 106 _ 1 . Additionally, each of the read-only external registers 106 _ 2 also allows read but not write access by the external sources 106 _ 2 . Each of the read/write external registers 106 _ 3 allows read and write access by both the internal sources 106 _ 1 and the external sources 106 _ 3 without restrictions. In some embodiments, each of the one or more registers 102 s is assigned with one or more register classification bits utilized to identify the type of the register 102 . In some embodiments, the one or more register classification bits assigned to each register 102 is maintained within a hardware component (e.g., a bit register, a lock unit, or a storage unit) associated with the register 102 , wherein the hardware component cannot be modified by software to prevent hacking via malicious software. In some embodiments, the number of register classification bits can be adjusted dynamically (e.g., increased) at runtime to accommodate additional types of register classification to accommodate allowable register read and write access requests.

In some embodiments, each of the one or more sources 106 s is configured to access a set of the one or more registers 102 s for a read or write operation on the data and/or software associated with the electronic device 108 by generating and transmitting a read or write access request. In some embodiments, the access request includes one or more of the type of the access request (to perform a read or write operation), one or more of the registers 102 s to be accessed as well as the source bits representing the type of the source 106 transmitting the access request. In some embodiments, the access request is transmitted by the source 106 via an internal register bus of the electronic device 108 if the source is an internal source 106 _ 1 . In some embodiments, the access request is transmitted by the source 106 via an external interface to the electronic device 108 , e.g., a PCIe interface or an I2C interface, if the source is an external source 106 _ 2 .

In some embodiments, the access request transmitted by the source 106 is accepted by an arbiter 104 configured to process the access requests to the one or more registers 102 s . In some embodiments, the arbiter 104 is associated with a single or a subset of the one or more registers 102 s , wherein more than one arbiter 104 can be utilized to covers all of the registers 102 s . In some embodiments, the arbiter 104 is an independent component external to the subset of the one or more registers 102 s . In some embodiments, the arbiter 104 is at the destination or an internal component of the one or more registers 102 s that are associated with the arbiter 104 . Once the access request is accepted, the arbiter 104 is configured to identify the type of the source 106 making the access request by decoding the source bit(s) transmitted with the access request, and the one or more registers 102 s the source 106 attempts to access. The arbiter 104 is then configured to retrieve and decode the register classification bits of the identified register 102 s and to compare or match the type of the source 102 making the access request with the types of the one or more registers 106 s the source 102 attempts to access. Based on the outcome of the comparison between the types of the source 102 and the registers 106 s , the arbiter 104 is configured to grant or deny the source 106 read and/or write access to the one or more registers. Specifically, if a read access request is granted, e.g., when the source 106 is an internal source 106 _ 1 and/or the registers 102 are read-only external registers 106 _ 2 or the read/write external registers 106 _ 3 , the source 106 is allowed to proceed to read data and/or software from the one or more registers 106 s . If a write access request is granted by the arbiter 104 , e.g., when the source 106 is an internal source 106 _ 1 and/or the registers 102 are the read/write external registers 102 _ 3 , the source 106 is allowed to proceed to write data and/or software to the one or more registers 102 s . On the other hand, if a read access request is denied, e.g., when the source 106 is an external source 106 _ 2 and/or the registers 102 are internal registers 102 _ 1 , a failed-read (e.g., Os) signal is sent back to the source 106 . If a write access request is denied, e.g., when the source 106 is an external source 106 _ 2 and/or the registers 102 are internal registers 102 _ 1 or read-only external registers 106 _ 2 , the write access request is dropped and a failed-write signal is sent back to the source 106 .

FIG. 2 depicts a flowchart 200 of an example of a process to support hardware-based register protection. Although the figure depicts functional steps in a particular order for purposes of illustration, the processes are not limited to any particular order or arrangement of steps. One skilled in the relevant art will appreciate that the various steps portrayed in this figure could be omitted, rearranged, combined and/or adapted in various ways.

In the example of FIG. 2 , the flowchart 200 starts at block 202 , where certain data associated with an electronic device is maintained via one or more registers, wherein each of the one or more registers is classified into one of a plurality of register types. The flowchart 200 continues to block 204 , where an access request for read or write access to the certain data maintained in the one or more registers is generated and transmitted by a source, wherein the source is categorized into one of a plurality of source types, wherein the source type of the source is transmitted with the access request. The flowchart 200 continues to block 206 , where the access request is accepted and the one or more registers to be accessed for a read or write operation are identified. The flowchart 200 continues to block 208 , where the register types of the one or more registers to be accessed are identified. The flowchart 200 continues to block 210 , where the source type of the source requesting access to the one or more registers is compared with the register types of the one or more registers. The flowchart 200 ends at block 212 , where whether to grant or deny read or write access to the one or more registers by the source is determined based on the comparison between the source type of the source requesting access and the register types of the one or more registers to be accessed.

The foregoing description of various embodiments of the claimed subject matter has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the claimed subject matter to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. Embodiments were chosen and described in order to best describe the principles of the invention and its practical application, thereby enabling others skilled in the relevant art to understand the claimed subject matter, the various embodiments and the various modifications that are suited to the particular use contemplated.