Integrated circuit with secure boot from a debug access port and method therefor

An integrated circuit (100) may receive a boot loader code (114) via a debug access port (105), wherein a boot logic is operative to block, upon a reset (123) of the programmable processor (103) from the debug access port (105), commands and to the programmable processor from the debug access port, while still allowing the reset (123) command and while allowing write access to memory (112) to receive the boot loader code image (114) written to memory (112). The boot logic also blocks commands to the memory subsystem (109) from the debug access port and turns off write access to memory (112) after allowing the boot loader code image (114) to be written. The boot logic validates the boot loader code image (114) by performing a security check and jumps to the boot loader code image (114) if it is valid, thereby allowing it to run on the programmable processor (103). The boot logic may be logic circuits, software or a combination thereof.

FIELD OF THE DISCLOSURE

The present disclosure is related to integrated circuit software generally, and more specifically to secure boot of integrated circuit processors.

BACKGROUND

Integrated circuits such as System On Chip (SOC) integrated circuits provide debugging ports such that the integrated circuit may be checked, that is, debugged by appropriate hardware and software connecting to the integrated circuit via debugging ports. For example, IEEE 1149.1, “Standard Test Access Port and Boundary Scan Architecture,” which is commonly referred to as the “JTAG” (Joint Test Action Group) standard, originally defined test access ports for printed circuit board testing but is now used extensively for integrated circuits. Debug ports such as those defined by the JTAG Standard may allow access to various sub-blocks of the integrated circuit such as memory, registers and flip flops of the device, all of which may store proprietary software or other confidential information.

Debug ports such as JTAG debug ports may also allow a user to load code onto an integrated circuit or various sub-blocks of the integrated circuit and run those code portions in order to implement various debugging functions. However, as would be understood by one of ordinary skill, these features may also enable hackers or other malicious users to run unauthorized code on the integrated circuit or to control various integrated circuit sub-blocks and thereby extract confidential and proprietary software or other information.

As would be understood by one of ordinary skill, software may be loaded into the integrated circuit via a debug port for the purposes of rebooting the integrated circuit. By booting the integrated circuit with a malicious code, a hacker may be able to gain access to various data stored on the integrated circuit, or stored in the platform on which the integrated circuit resides, that would not otherwise be accessible.

Therefore, it would be desirable to verify any code loaded into an integrated circuit or its sub-blocks via any debug ports. Particularly it would be desirable to verify any that may be used for booting the integrated circuit.

At the same time authorized debuggers should have the capability to install and run appropriate debugging software on the integrated circuit or any of its components as needed in order to run tests on the integrated circuit.

DETAILED DESCRIPTION

The embodiments disclosed include a method comprising receiving a programmable processor reset command from a debug access port of an integrated circuit; halting the programmable processor in response to the reset command while the reset command is asserted; blocking, by a boot logic upon the reset of the programmable processor, commands to the programmable processor from the debug access port, while still allowing the reset command to the programmable processor from the debug port; and allowing, by the boot logic, write access to memory by the debug access port to receive a boot loader code image written to the memory. The method may include blocking, by the boot logic upon the reset command, commands to a memory subsystem from the debug access port. The method may also include validating, by the boot logic, the boot loader code image as valid code by performing a security check on the boot loader code image; and jumping, by the boot logic, to the boot loader code image thereby allowing the boot loader code image to run on the programmable processor.

The described embodiments also include an integrated circuit with a debug access port; a programmable processor coupled to the debug access port where the programmable processor is operative to receive a reset command from the debug access port, and to transmit data to, and receive data from, the debug access port; and a boot logic, operative to block, upon a reset of the programmable processor corresponding to a reset command from the debug access port, commands and to the programmable processor from the debug access port, while still allowing the reset command to the programmable processor from the debug port; and while allowing write access to memory by the debug access port to receive a boot loader code image written to the memory. The integrated circuit may further include a memory system operatively coupled to the debug access port; and wherein the boot logic is further operative to block, upon reset of the programmable processor, commands to the memory subsystem from the debug access port.

The embodiments also include an integrated circuit comprising a debug access port; a memory system operatively coupled to the debug access port; a programmable processor coupled to the debug access port; the programmable processor operative to receive a reset command from the debug access port, and to transmit data to, and receive data from, the debug access port; and a boot logic, operative to block, upon a reset of the programmable processor corresponding to a reset command from the debug access port, commands to the programmable processor from the debug access port, while still allowing the reset command to the programmable processor from the debug port; and while allowing write access to memory by the debug access port to receive a boot loader code image written to the memory; block, upon reset of the programmable processor, commands to the memory subsystem from the debug access port; turn off the write access to the memory via the debug access port after allowing a boot loader code image to be written to the memory via the debug access port; validate that the boot loader code image is valid code by performing a security check on the boot loader code image; and jump to the boot loader code image thereby allowing the boot loader code image to run on the programmable processor.

Turning now to the drawings wherein like numerals represent like components,FIG. 1is a block diagram of an integrated circuit (IC)100which may be a System-on-Chip (SOC) integrated circuit in some embodiments. The IC100includes a programmable processor103which is coupled to the debug access port105by a data line through logic switch121and a reset line123. The programmable processor103may be any suitable type of processor, such as, but not limited to, a CPU, graphics processor core, or other suitable programmable processing circuitry. The debug access port105may be, for example, a JTAG debug access port. The debug access port105may be coupled to a debug host101via a physical connection125. The debug access port105is also coupled to a baseband interface port107. The baseband interface port107may be a primary access interface port of the IC100to the outside world. For example, a device129may be connected to the baseband interface port107by a connection141, where a logic switch127, allows or blocks bidirectional data flow between the baseband interface port107and the memory subsystem109. The device129, via the baseband interface port107, may, if allowed by logic switch127, access the programmable processor103and a memory subsystem109via a coupling117between the baseband interface port107, the programmable processor103and the memory subsystem109. The device129may be any suitable device that may communicate with the integrated circuit100, such as, but not limited to, another programmable processor, a baseband processor, etc.

The memory subsystem109may include, among other things, a memory controller110which is coupled to a random access memory RAM112and a boot ROM111. The term “boot ROM” as used herein may refer to the memory containing boot software, the boot software being a set of executable instructions for executing on, for example, the programmable processor103. However, as used herein, the term “boot ROM” also refers to the boot software being executed by the programmable processor103. Therefore, where the boot ROM is said to perform some action herein, this refers to the boot software executing on the CPU and causing the CPU to perform an operation, i.e., to perform some action attributed to the boot ROM.

Additionally, the various embodiments include boot logic circuits such as boot logic108. The boot logic108is operative to control logic switches for blocking or allowing access to various blocks or sub-blocks of the integrated circuit100. The boot logic108, is operatively coupled to the programmable processor103and may interact with software, firmware, other logic or combinations thereof. For example, the boot logic108may work in conjunction with the boot ROM111. Therefore, in accordance with the embodiments, a boot logic may include software, including the boot ROM111software, logic circuits or combinations of software and logic circuits to accomplish the various operations as will be described in further detail herein. Further, various portions of the boot logic may operate independently of other portions of the boot logic at various times of the operation. For example, upon reset of the programmable processor103, boot logic108may operate exclusively during the reset until a software component of the boot logic, for example from the boot ROM111, is able to resume function after the reset to the programmable processor103is de-asserted.

The RAM112, which may be a Static RAM (SRAM) in some embodiments, may contain a boot loader image114as shown inFIG. 3, for example, after such a boot loader image114has been downloaded. The boot loader image114is a boot loader code image which may extend the functionality of the boot ROM111.

The boot loader image114may be loaded into RAM112via a write command from the debug host101via the debug access port105, which allows write access131to the RAM112. It is to be understood that the write access131is for exemplary purposes only and for explaining the various embodiments disclosed herein. Therefore the write access131from the debug access port105may actually be implemented using the memory controller110of the memory subsystem109. However, for simplicity of illustration and simplicity of explanation the write access131is shown as a simple control line from the debug access port105directly to the RAM112inFIGS. 1,2and3.

In accordance with the embodiments, a boot logic, including the boot logic108and the boot ROM111, has control of data exchange between various sub-blocks of the integrated circuit100during booting procedures. For example, the boot logic108of the embodiments will control access from the debug access port105to baseband interface port107, programmable processor103and RAM112using, for example, logic switches119,121,127and133, respectively. Note that control by the boot logic108may effect other software or hardware logic in the various embodiments and may be accomplished in various manners. For example, logic switches119,121,127and133may be software controls or logic circuits in the various embodiments. Therefore, for simplicity of illustration and explanation the boot logic108control functionality is illustrated by way of logic switches119,121,127and133. Thus, for example, the boot logic108may use control signal135to control the position of logic switches119,121,127and133thereby allowing or disallowing access between various sub-blocks of the integrated circuit100.

For example, the boot logic108may apply the control signal135to cause logic switch119to open thereby restricting the debug access port105from access to the baseband interface port107and thus also prevent the debug access port105from accessing the memory subsystem109. The boot logic108may prevent access, via the baseband interface port107, to memory by any external device, such as device129, by controlling logic switch127to block access to the memory subsystem109via the baseband interface port107. The boot logic108and/or the boot ROM111of the embodiments may also prevent the debug access port105from having write access131to the RAM112by opening, for example logic switch133. Therefore the control signal135may represent a control bus within integrated circuit100wherein the boot logic108may send access grant or access restriction commands to the appropriate logic circuits and/or software and/or firmware modules to grant access or prevent access to any sub-block of the integrated circuit by debug access port105. As a further example, the boot logic108may cause logic switch121to open thereby preventing the debug access port105from accessing the programmable processor103. However, in the various embodiments the debug access port105will be allowed to send a reset123signal to the programmable processor103to cause the programmable processor105to reset/reboot.

In accordance with an embodiment, a debug host101may be connected to the debug access port105via the physical connection125. The debug host101may send, through the debug access port105, a reset signal123to the programmable processor103causing the programmable processor103to enter a reset state or otherwise stop operation while the reset123is applied. The debug host101may then, via the write access131, write a code image113into the RAM112as shown inFIG. 2.FIG. 2illustrates the function of the various embodiments in response to the programmable processor103receiving the reset signal123from the debug access port105. In response to the reset signal123to programmable processor103, the boot logic108will, via control signal135, open logic switches119,121and127, thereby preventing the debug access port105, or any device129, from accessing the memory subsystem109and the programmable processor103respectively. However, the logic switch133will remain closed to allow write access131to the RAM112so that the debug access port105may provide the code image113to the RAM112. Although write access131is allowed, read access to the RAM112will be blocked.

After the reset signal123is asserted from the debug access port105to the programmable processor103, the logic switches119,121,127and133, and boot logic108may not be in the desired state, that is, the state as illustrated byFIG. 2, wherein logic switch133is closed to allow write access131. Therefore, subsequent to the reset123being asserted to the programmable processor103from the debug access port105, a boot logic108reset may occur, thereby resetting the boot logic108and placing the logic switches into the state illustrated byFIG. 2wherein logic switch133is closed to enable write access131to RAM112from the debug access port105. The boot logic108reset may be achieved in some embodiments by, for example, a chip level reset that resets logic of the integrated circuit100. In this case, the chip level reset would occur while the reset123remains asserted to the programmable processor103from the debug access port105. After the chip level reset, which resets boot logic108, the image113may be written to RAM112via write access131, through the closed logic switch133as shown inFIG. 2. In an alternative embodiment, the boot logic108may be reset by a reset controller of the integrated circuit100, where the reset controller provides reset signals to a plurality of logic within the integrated circuit100, including programmable processor103. In another alternative embodiment, the boot logic108may have a dedicated reset logic residing on the integrated circuit100, and that resets the boot logic108in response to the programmable processor103receiving a reset123from the debug access port105.

In one exemplary embodiment wherein the debug access port105is a JTAG debug port, the JTAG system will write a mailbox location to the RAM112to indicate to the boot ROM111that the JTAG has loaded a code image into the RAM. The mailbox location in some embodiments may include a range of address locations used for the purpose of writing by the JTAG debug port. The debug host101may then de-assert, that is, remove the reset signal123to the programmable processor103in which case the boot ROM111will run. As shown inFIG. 3the boot ROM111will then, in conjunction with boot logic108and control signal135, cause the logic switch133to open thereby preventing the debug access port105any further write access131to the RAM112. However, in the various embodiments the debug host101will still be allowed to provide the reset signal123to the programmable processor103.

The boot ROM111will now proceed to check the mailbox location which corresponds to a known location in the RAM112to look for the loaded code image113. Checking the mailbox location in some embodiments may include checking a range of addresses, or range of memory locations, for a mailbox command. The mailbox command may include a numerical value that indicates that the JTAG debug port has written code to memory. In response to locating the mailbox command, the boot ROM111may search for the code header information. If the boot ROM111locates the code image113at the location specified in the mailbox, the boot ROM111may, in some embodiments, clear the mailbox memory location to ensure that it is not mistakenly used as a valid JTAG boot message during any subsequent programmable processor resets.

The boot ROM111will then proceed to use a security mechanism to verify that the code image113loaded into RAM112is valid code, that is, code authorized to be installed on the integrated circuit100via the debug access port105. For example, the boot ROM111may perform a signature check upon the code image113or otherwise check a hash of the code image113. Any appropriate security and validation method may be used to validate the code image113for the various embodiments. In some embodiments, the boot ROM111will first perform the security check on a header information, and, if the header information passes, will use the header information to complete a check on the code image.

If the code image113is determined to be invalid by the security mechanism the boot ROM111may continue to try to load code from another source based on, for example, bootstraps. The bootstraps may direct the boot ROM111to any suitable location to locate boot loader software such as for example the device129. The bootstraps may direct the boot ROM111to UART, USB, NAND devices, or any other suitable port or device for locating boot loader code. However, if the code image113is verified, then the boot ROM111will parse the header of the code image113to determine what action to take next.

For example, in some embodiments the header information of the code image113may include a location and size of a boot loader code within the image113, a destination in memory to where the code should be copied, or any other suitable information associated with the code image113. After the boot ROM111parses the header, the boot ROM111may proceed to take the specified action such as for example copying code to a correct memory location. For example, the image113may include a boot loader code image114. The boot ROM111may load the boot loader code image114into RAM112as shown inFIG. 3, and prepare to jump to the boot loader code114.

FIG. 4illustrates a boot ROM procedure in accordance with the various embodiments. The first portion ofFIG. 4, shown as block400, represents procedures run by the boot ROM111. After the programmable processor is reset the boot ROM runs in401and, in403, determines the source of a first boot loader code image such as may be included in code image113shown inFIG. 2. In405a first boot loader code image, such as boot loader code image114, is loaded into memory. In407a security mechanism determines whether the first boot loader code image is valid. If the security test fails in block407, then a boot failure may occur as shown in411in which case an error code may be marked and the system may be halted. In some embodiments, after the boot failure, a baseband processor will be notified, via a set of secured registers for example, and will enter into a loop. However, if the security mechanism determines that the first boot loader code is valid in407, then the boot ROM111may jump to the first boot loader code image as shown in409.

Block410inFIG. 4illustrates operation of the boot loader code. Therefore in413, the first boot loader code image runs and, in some embodiments, may retrieve a second code image which may include a second boot loader code image. In415the boot loader code image may now apply a security mechanism to determine the source of the boot loader code image and whether the code is valid. The first boot loader code may also load the second boot loader code image as shown in417. If the security check shows that the second boot loader code image is valid in419, then the second boot loader code may be jumped to in421, completing the first boot loader procedure410and running the second boot loader code in423.

The first boot loader code as shown in block410may be generic code, that is, independent of any specific platform of the integrated circuit100. However, the second boot loader image as shown in block423may be platform dependent code. Further, the second boot loader code may not be an actual boot loader code but may be any suitable code as would be understood by one of ordinary skill. Further, after the boot ROM111jumps to the boot loader code114, the boot loader code114is free to either allow access by the debug access port105or block access by the debug port105. The boot loader image114may perform additional initiation of various blocks of the integrated circuit100and/or may load additional trusted secure software in some embodiments.

FIG. 5illustrates operation of an embodiment wherein the debug access port105is a JTAG debug access port. In501the JTAG port holds the programmable processor in a reset condition through the integrated circuit JTAG debug port. In503the JTAG loads a code image into the RAM. In505the JTAG writes a mailbox location in RAM to indicate to the boot ROM that it has loaded code to the RAM. In507the JTAG de-asserts the programmable processor reset and in509the boot ROM111runs, turning off the JTAG write access to the RAM112but leaving the JTAG the ability to reset the programmable processor.

FIG. 6illustrates operation of the boot ROM111in accordance with an embodiment. In601the boot logic108detects that the debug port has reset the programmable processor and blocks the debug port from any data access to the programmable processor and from any access to the memory system. In603the boot logic108allows the debug port reset access to the programmable processor and also allows the debug port write access to the RAM112. In605the boot logic108allows a RAM code image113to be written from the debug port. When the programmable processor103reset is de-asserted as shown in607, the boot ROM111code will be able to run on the programmable processor103, and will immediately disable the debug port105write access131as shown in609. For example, this may be accomplished in conjunction with the boot logic108, causing logic switch133to open and thereby block write access131. This action prevents any possible unauthorized modification of the code image in RAM112prior to the code image being run by the programmable processor103.

FIG. 7illustrates additional details of operation in accordance with the embodiments. In701the boot ROM111is already running and in703checks the RAM112mailbox location written by, for example, a JTAG debug operation where the mailbox location indicates a boot loader code image address in memory. In705the boot ROM111then checks the indicated address location for the boot loader code. If the image is missing, the boot ROM111will continue with a boot strapping operation as in715, and, in717, will check a next source such as, but not limited to, NOR or NAND device ports, UART ports, or other external devices as determined by the boot strapping in715. However, if the boot loader code image is present, then in707the boot ROM111may clear the mailbox address location to ensure that the message contained there will not be mistaken for a valid boot message on a subsequent programmable processor reset.

In709the boot ROM111uses a security mechanism to determine whether the boot loader code image is valid. If the boot loader code image fails the security test, the boot ROM111may proceed with boot strapping in715, and in717check the next source for a valid image in accordance with the boot strapping indication of715. However, if the boot loader code image is valid in709, then in711the boot ROM111will parse the header of the code image to determine, for example, location, size of the code within the image or a destination address in memory to where the code should be copied in some embodiments. In713the boot ROM111is ready to jump to the boot loader code.

FIG. 8illustrates an additional embodiment continuing from the embodiment shown inFIG. 7. For example, in801the boot ROM111may, in preparation to jump to the boot loader code, write information to shared memory and/or registers for use by the boot loader code. Subsequently in803the boot ROM111may jump to the boot loader code image wherein the boot loader code image runs as shown in805. In807, the boot loader code image may allow access or block access to the debug port105, such as a JTAG debug port. In809the boot loader code may perform additional initiation of blocks on the integrated circuit100and/or load additional trusted secured software which may be obtained from and external source, such as for example, the device129.

Therefore, various applications of the herein disclosed embodiments will become apparent to one of ordinary skill. For example, the embodiments herein disclosed may be useful for initial debugging procedures or debugging procedures after a specific platform has been used for the integrated circuit100, wherein the software or operating system has failed to run because of problems with the operating system or software. Further, the embodiments herein disclosed may be useful for prefabricated phones that are prefabricated with no software but need to have trusted code installed from, for example, a flash memory. Also, as would be understood by one of ordinary skill, once the boot loader image is loaded from the debug port, such as for example, a JTAG debug port, the boot loader code image may provide access to the debug port via authentication certificates such that a debug host such as, for example, debug host101, may perform further operations via the debug access port.

The security mechanisms employed by the boot ROM111in order to validate the boot loader code image loaded through the debug access port may include, for example, private/public key pair validation or other encryption and validation techniques as would be understood by one of ordinary skill. For example, the boot loader code may check a signature of the boot loader code image wherein the signature is a hash of the code image, the hash being encrypted by, for example, a private key, where the public key may be stored by the boot ROM111.

The above detailed description and the examples described therein have been presented for the purposes of illustration and description only and not by limitation. For example, the operations described may be done in any suitable manner. The method steps may be done in any suitable order still providing the described operation end results. It is therefore contemplated that the present embodiments cover any and all modifications, variations or equivalents that fall within the spirit and scope of the basic underlying principles disclosed above and claimed herein.