System and method for generating secure partitioned regions in an open and secure processor environment

Abstract

The present disclosure relates to systems and methods of generating secure partitioned regions in an open and secure processor environment. Example implementations include a method of partitioning a memory device by detecting a boot state of a processing device comprising the non-transitory memory device, identifying a launch state of the processing device based on the boot state, and partitioning the memory device into at least one secure address region in accordance with a determination that the launch state satisfies an operating state condition. Example implementations also include a method of generating a secure partition associated with a non-transitory memory device by identifying target processing instructions restricted for execution at a secure subsystem of the processing device, assigning a secure address to the target processing instructions, associating the secure address with a secure address region of the non-transitory memory device of the processing device, and generating a secure partition table comprising the secure address.

Description

TECHNICAL FIELD

[0001] The present implementations relate generally to secure processing systems, and more particularly to generating secure partitioned regions in open and secure processor environments. BACKGROUND

[0002] Embedded and portable electronic systems are becoming increasingly complex and are facing greater security risks. In addition, the number of use cases and flexibility of embedded and portable computer systems is expanding. Increasingly, embedded and portable computer systems are required to store, access, and manage sensitive information in a variety of scenarios while also supporting open and flexible application operations. However, conventional systems can not effectively partition secure data, operations, and instructions from unauthorized access. Accordingly, there is a need for technical solutions for generating secure partitioned regions in open and secure processor environments. SUMMARY

[0003] Example implementations include a method of partitioning a memory device by detecting a boot state of a processing device including a non-transitory memory device, identifying a startup state of the processing device based on the boot state, and partitioning the memory device into at least one secure address region in accordance with a determination that the startup state satisfies an operational state condition.

[0004] Example implementations also include a method of generating a secure partition associated with a non-transitory memory device by identifying target processing instructions restricted for execution at a secure subsystem of a processing device, assigning a secure address to the target processing instructions, associating the secure address with a secure address region of a non-transitory memory device of the processing device, and generating a secure partition table including the secure address.

[0005] Example implementations also include a system having a bootloader configured to detect a boot state and identify a startup state based on the boot state, a partition register operably coupled to the bootloader and configured to partition a memory device into at least one secure address region in accordance with a determination that the startup state satisfies an operational state condition, and a system processor operably coupled to the bootloader and configured to write a partition address associated with the secure address region to the partition register in accordance with a determination that the startup state satisfies the operational state condition, and further configured to enter an operational state of the processing device in accordance with a determination that the startup state does not satisfy the operational state condition. BRIEF DESCRIPTION OF DRAWINGS

[0006] These and other aspects and features of the present implementations will become apparent to those ordinarily skilled in the art upon review of the following description of specific implementations in conjunction with the accompanying drawings, of which:

[0007] Figure 1 FIG. 1 illustrates one example system, according to an implementation.

[0008] Figure 2 FIG. 1 illustrates one example system, according to an implementation. Figure 1 FIG. 1 illustrates one example system, according to an implementation.

[0009] Figure 3 FIG. 1 illustrates one example system, according to an implementation.

[0010] Figure 4 FIG. 1 illustrates one example system, according to an implementation. DETAILED DESCRIPTION

[0011] The present implementations will now be described in detail with reference to the accompanying figures. Figure and examples are provided as illustrative examples of implementations and to enable those of ordinary skill in the art to practice the implementations and alternatives as apparent to those of ordinary skill in the art. It is to be understood that the following figures and examples are not intended to limit the scope of the present implementations to a single implementation, but rather are intended to be exemplary of the many possible implementations and alternatives. Furthermore, in some instances, certain elements of the present implementations can be implemented using known components or parts, and in such instances, only those portions of such known components or parts that are necessary for an understanding of the present implementations will be described, and detailed descriptions of other portions of such known components or parts will be omitted so as not to obscure the present implementations. Unless otherwise noted, those of ordinary skill in the art will recognize that an implementation described as being implemented in software should not be limited thereto, and that an implementation can be implemented in hardware, or a combination of software and hardware, and vice versa. In the present specification, unless otherwise indicated, implementations showing a single component should not be viewed as limiting; on the contrary, the present disclosure is intended to encompass other implementations including multiple components, and vice versa. Furthermore, unless specifically stated otherwise, applicant does not intend for any term in the specification or claims to be given a disjunctive or exclusive sense, nor does applicant intend for any term in the specification or claims to be given a commonly used special meaning. Furthermore, the present implementations encompass current and future known equivalents to the known components referred to herein by way of illustration.

[0012] In some implementations, the secure embedded processing system includes both a system region accessible to all processing requests and a secure system region accessible only to secure operations, objects, etc. In some implementations, access to the secure system memory region is restricted, enforced, etc. by hardware limiting or preventing direct addressing of secure memory addresses. To improve security and minimize the risk of penetration into the secure memory region, it is advantageous to generate the secure partition by defining the secure memory region to include all secure access operations, objects, etc. while excluding all other operations, objects, etc. that can be used to access the secure region through improper or accidental execution. It is further advantageous to generate the secure partition automatically in cooperation with the generation of processor instructions for both system and secure operations to accurately include all secure functionality in the secure memory region while accurately excluding all system functionality from the secure memory region.

[0013] Figure 1 An example system according to the present implementation is illustrated. As shown in the example in Figure 1 As shown in the example in FIG. 1, the example system 100 includes at least one of a local system 110 and a compiler system 120. In some implementations, the local system 110 includes a system processor 102, a bootloader 104, a secure subsystem 106, a system memory 108, a communication interface 114, a system partition register 112, and a system bus 116. In some implementations, the local system 110 includes an electronic circuit board, a printed circuit board, a conductive substrate, etc. In some implementations, the compiler system 120 includes a build controller 122 and a partition generator 124. In some implementations, the compiler system 120 includes a personal computer, a server computer, etc. operably coupled or operably couplable to the local system 110 through one or more wired, wireless, digital, network, etc. connections.

[0014] The system processor 102 is operable to execute one or more instructions associated with the local processing system 110. In some implementations, the system processor 102 is an electronic processor, integrated circuit, or the like, including one or more of digital logic, analog logic, digital sensors, analog sensors, communication buses, volatile memory, non-volatile memory, or the like. In some implementations, the system processor 102 includes, but is not limited to, at least one microcontroller unit (MCU), microprocessor unit (MPU), central processing unit (CPU), graphics processing unit (GPU), physics processing unit (PPU), embedded controller (EC), or the like. In some implementations, the system processor 102 includes a memory that is operable to store or be storing one or more instructions for operating the system processor 102 and operating components operably coupled with the system processor 102. In some implementations, the one or more instructions include at least one of firmware, software, hardware, operating system, embedded operating system, or the like. It should be appreciated that the system processor 102 or the local system 110 can generally include at least one communication bus controller to enable communication between the system processor 102 and other elements of the local system 110.

[0015] The boot loader 104 is operable to execute one or more instructions to operate, initialize, start, restart, shut down, hibernate, or the like, one or more of the local system 110, the system processor 102, the security subsystem 106, the system memory, and the communication interface 114. In some implementations, the boot firmware includes one or more electrical, electronic, and logic devices. In some implementations, the boot firmware includes one or more integrated circuits, transistors, transistor arrays, or the like. In some implementations, the boot firmware includes one or more boot instructions, boot loaders, or the like. In some implementations, the boot loader 104 includes, is coupled to, is couplable to, or the like, one or more hardware switches, jumper pins, jumpers, fuses, or the like, that are operable to set, select, determine, control, or the like, one or more boot states. In some implementations, the boot loader 104 is operable to detect one or more boot states based at least in part on the one or more hardware switches, jumper pins, jumpers, fuses, or the like.

[0016] The security subsystem 106 is operable to perform processing, storage, retrieval, etc. of one or more of the system processor 102, the bootloader 104, the system memory 108, the communication interface 114, the system partition register 112, and the compiler system 120 that is inaccessible to the other. In some implementations, the security subsystem 106 includes restrictions on access to one or more memory devices, memory locations, memory addresses, etc. In some implementations, the security subsystem 106 includes restrictions on access to one or more processing devices, processing functions, etc. In some implementations, the security subsystem 106 stores or is operable to store information received at the local system 110 by the communication interface 114. As one example, the security subsystem 106 can store passwords, financial information, encryption keys, user identification information, security tokens, etc. In some implementations, the security subsystem 106, or one or more components thereof, is controllably modifiable by at least one of the system partition register 112 and the compiler system 120. Thus, in some implementations, the security subsystem 106 can perform one or more functions that are inaccessible to any device or system external to the security subsystem 106.

[0017] The system memory 108 is operable to store data associated with the local system 110. In some implementations, the system memory 108 includes one or more hardware memory devices for storing binary data, digital data, etc. In some implementations, the system memory 108 includes one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc. In some implementations, the system memory 108 includes at least one of a non-volatile memory device, a solid state memory device, a flash memory device, and a NAND memory device. In some implementations, the system memory 108 includes one or more addressable memory regions disposed on one or more physical memory arrays. In some implementations, one or more addressable memory regions of the system memory 108 are controllably modifiable by at least one of the system partition register 112 and the compiler system 120. In some implementations, the physical memory array includes a NAND gate array disposed on a particular semiconductor device, integrated circuit device, printed circuit board device, etc.

[0018] The system partition register 112 is operable to control, limit, etc. access to the system memory 108 by the system processor 102. In some implementations, the system partition register 112 includes one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc. In some implementations, the system partition register 112 includes at least one of a non-volatile memory device, a solid state memory device, a flash memory device, and a NAND memory device. In some implementations, the system partition register 112 includes one or more memory addresses associated with the system memory 108. In some implementations, the system partition register 112 controls the memory addresses of the system memory that are directly addressable by the system processor 102. In some implementations, the system partition register 112 defines a logical portion, subset, etc. of the system memory 108 that is available for direct addressing by the system processor 112. It should be appreciated that the system partition register 112 can be optionally included to explicitly define the memory addresses that are directly addressable by the system processor 112. Alternatively, it should be appreciated that in some implementations, the system processor 112 can directly address any memory addresses that are not explicitly associated with the secure subsystem 106.

[0019] In some implementations, the system partition register 112 defines one or more address ranges that identify or limit the memory addresses of the system memory 108 that are directly addressable by the system processor 102. In some implementations, the system partition register 112 includes one or more address pairs that define contiguous address ranges, blocks, etc. that are directly addressable by the system processor 102. As one example, the system partition register 112 can include a first address pair that includes a first address 0000F000 and a second address 00F00000 that define an address range that is directly addressable by the system processor 102 therebetween. In some implementations, the system partition register 112 includes multiple memory address pairs that identify non-contiguous memory blocks. As one example, in addition to the first address pair, the system partition register 112 can include a second address pair that includes a third address 00F01000 and a fourth address 00F0F000 that define an address range that is directly addressable by the system processor 102 therebetween. In some implementations, the system processor 102 is limited, prevented, etc. from directly addressing any memory addresses outside of any address ranges stored by the system partition register 112. In some implementations, the system memory 102 is a logical subset of a physical memory array and is defined by the memory addresses stored by the system partition register 112.

[0020] The communication interface 114 is operable to communicatively couple the local system 110 to the compiler system 120. In some implementations, the communication interface 114 includes one or more wired interface devices, channels, etc. In some implementations, the communication interface includes, is operably coupled to, or is operably couplable to, an I2C, UART, or similar communication interface of one or more external devices, systems, etc. The system bus 116 is operable to communicate one or more instructions, signals, conditions, states, etc. between the system processor 102, the bootloader 104, the system memory 108, the system partition registers 112, the communication interface 114, and the compiler system 120. In some implementations, the system bus 116 includes one or more digital, analog, etc. communication channels, lines, traces, etc.

[0021] The build controller 122 is operable to generate one or more machine-readable instructions executable by the system processor 102 and the security subsystem 106. In some implementations, the build controller includes at least one of an integrated development environment (IDE), a compiler, a linker, and an assembler of high-level instructions associated with at least one of the system processor 102 and the security subsystem 106. In some implementations, the high-level instructions include computer programming code written in at least one computer programming language. As one example, the high-level instructions can be written using C++, etc. In some implementations, the build controller 122 is operable to generate one or more machine-readable instructions executable by the system processor 102 or the security subsystem 106. In some implementations, the build controller 122 generates a single set of instructions including all instructions executable by the system processor 102 or the security subsystem 106. In some implementations, the set of instructions includes one or more identifiers of one or more operations, functions, headers, objects, classes, data, etc. As one example, the single set of instructions can include an ELF file. As another example, the ELF file can include one or more header sections describing one or more functions, headers, objects, classes, data, etc.

[0022] The partition generator 124 is operable to generate at least one partition table that identifies one or more memory locations that are directly addressable by one or more of the system processor 102 and the secure subsystem 106. In some implementations, the partition generator 124 is operable to generate a system memory region of the system memory 108 that is directly addressable by the system processor 102. In some implementations, the partition generator 124 is operable to generate a secure memory region of the secure subsystem 106 that is not directly addressable by the system processor 102. In some implementations, the partition generator 124 is operable to generate a secure access memory region of the secure subsystem that is directly addressable by the system processor 102. In some implementations, the partition generator 124 generates one partition table that defines access controls, restrictions, etc. to the system memory region, the secure memory region, and the secure access memory region. Alternatively, in some implementations, the partition generator 124 generates multiple partition tables, each defining access controls, restrictions, etc. to one or more of the system memory region, the secure memory region, and the secure access memory region. As one example, the partition generator 124 can generate a system partition table that defines the system memory region, and can generate a secure partition table that defines the secure memory region and the secure access memory region.

[0023] Figure 2 FIGURE 1 illustrates an example system according to Figure 1 FIGURE 2 illustrates an example secure subsystem of the example system of FIGURE 1. As Figure 2 illustrated by way of example in FIGURE 1, the example secure subsystem 200 includes a secure memory 202, a secure processor 204, and a secure partition register 206. In some implementations, the secure subsystem 106 includes the secure subsystem 200.

[0024] The secure memory 202 is operable to store data associated with the secure subsystem 200. In some implementations, the secure subsystem 200 restricts or prevents access to at least a portion of the secure memory 202 from the local processing system 110. In some implementations, the secure subsystem 200 restricts or prevents direct addressing of at least a portion of the secure memory 202 from the local processing system 110. In some implementations, the secure memory 202 includes one or more firmware memory devices to store binary data, digital data, and the like. In some implementations, the secure memory 202 includes one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, and the like. In some implementations, the secure memory 202 includes at least one of a non-volatile memory device, a solid state memory device, a flash memory device, and a NAND memory device. In some implementations, the secure memory 202 includes one or more addressable memory regions disposed on one or more physical memory arrays. In some implementations, one or more addressable memory regions of the system memory 108 are controllably modifiable by at least one of the secure partition register 206 and the compiler system 120. In some implementations, the secure memory 202 includes a logical secure access region that is directly addressable from the local processing region. In some implementations, the secure memory 202 is a resizable logical portion, partition, region, and the like, of the system memory 108. In some implementations, the physical memory array includes a NAND gate array disposed on a particular semiconductor device, integrated circuit device, printed circuit board device, and the like.

[0025] The secure processor 204 is operable to execute one or more instructions associated with the secure subsystem 200. In some implementations, the secure processor 204 restricts or prevents access to at least a portion of the secure memory 202 from the local processing system 110. In some implementations, the secure processor 204 restricts or prevents direct addressing of at least a portion of the secure memory 202 from the local processing system 110. In some implementations, the secure processor 204 is operable to perform one or more processing operations associated with restricting or preventing access to the secure subsystem 200. In some implementations, the secure processor is operably coupled to the system bus 114. In some implementations, the secure processor 204 includes one or more devices in compliance with the system processor 102.

[0026] The secure partition register 206 is operable to control, limit, etc. access to the secure memory 202 by one or more of the system processor 102 and the local processing system 110. In some implementations, the secure partition register 206 includes one or more electrical components, electronic components, programmable electronic components, reprogrammable electronic components, integrated circuits, semiconductor devices, flip-flops, arithmetic units, etc. In some implementations, the secure partition register 206 includes at least one of a non-volatile memory device, a solid state memory device, a flash memory device, and a NAND memory device. In some implementations, the secure partition register 206 includes one or more memory addresses associated with the secure memory 202. In some implementations, the secure partition register 206 controls memory addresses of the secure memory 202 that are directly addressable by the system processor 102 as a secure access region of the secure memory 202. In some implementations, the secure partition register 206 defines a logical portion, subset, etc. of the secure memory 202 that is usable for direct addressing by the secure processor 204. It should be understood that the secure partition register 206 can be optionally included to explicitly define memory addresses that are directly addressable by the secure processor 204. Alternatively, it should be understood that in some implementations, the secure processor 204 can directly address any memory addresses that are explicitly associated with the secure subsystem 106 through the system partition register 112.

[0027] In some implementations, the secure partition registers 206 define one or more address ranges that identify or limit the memory addresses of the secure memory 202 that the system processor 102 can directly address. In some implementations, the secure partition registers 206 include one or more address pairs that define contiguous address ranges, blocks, etc. that are directly addressable by the system processor 102. As one example, the secure partition registers 206 can include a first address pair that includes a first address 00001000 and a second address 0000FFFF that define an address range that is directly addressable by the system processor 102 therebetween. In some implementations, the system secure partition registers 206 include multiple memory address pairs that identify non-contiguous memory blocks. As one example, in addition to the first address pair, the secure partition registers 206 can include a second address pair that includes a third address 1000000 and a fourth address F0000000 that define an address range that is directly addressable by the system processor 102 therebetween. In some implementations, the system processor 102 is restricted, prevented, etc. from directly addressing any memory address within any address range stored by the secure partition registers 206. In some implementations, the system processor 102 is permitted to directly address any memory address within any address range stored by the secure partition registers 206 and associated with a secure access memory region. In some implementations, the secure memory 202 is a logical subset of a physical memory array and is defined by the memory addresses stored by the secure partition registers 206.

[0028] Figure 3 An example method of partitioning a non-transitory memory device into secure system address regions according to the present implementation is illustrated. In some implementations, the example system 100 performs the method 300 according to the present implementation. In some implementations, the method 300 begins at step 310.

[0029] At step 310, the example system enters a power-on state. In some implementations, at least one of the system processor 102 and the bootloader 104 enter the power-on state. In some implementations, the power-on state includes firmware booting, power-on self-test, register clearing, etc. In some implementations, the power-on state is controlled by one or more hardware device settings including, but not limited to, a hardware switch, a jumper, etc. In some implementations, the example system enters the power-on state based on the application of power through a power-on signal, a hardware switch that delivers power to the local processing system 110, etc. The method 300 then continues to step 312.

[0030] At step 312, the example system detects a physical boot state. In some implementations, the boot loader 104 detects the physical boot state. In some implementations, the physical boot state is set by a particular configuration of a hardware switch, a jumper pin, a jumper connection, and the like. In some implementations, the particular configuration is set prior to a power on state. In some implementations, the boot loader 104 detects the physical boot state by detecting a switch state associated with the boot state. The method 300 then continues to step 314. At step 314, the example system identifies a launch state based at least in part on the physical boot state. In some implementations, the boot loader 104 identifies the launch state. In some implementations, the boot loader 104 identifies the launch state by detecting whether a boot jumper pin is open. The method 300 then continues to step 320.

[0031] At step 320, the example system determines whether the identified launch state corresponds to an operational state. In some implementations, an open boot jumper pin configuration is associated with a partition management state, and a closed boot jumper pin configuration is associated with an operational state. In some implementations, the example system is locked into an immutable partition table by soldering, or the like, the boot jumper pin closed, preventing further entry into the partition management state. As one example, a developer can download a partition table associated with a particular security application, and can solder a closed boot jumper pin to prevent any tampering with the partition table and its security restrictions on direct addressing of various secure memory addresses. In accordance with a determination that the identified launch state corresponds to the operational state, the method 300 continues to step 360. Alternatively, in accordance with a determination that the identified launch state does not correspond to the operational state, the method 300 continues to step 330.

[0032] At step 330, the example system opens a physical communication channel to the compiler system. In some implementations, the communication interface 114 opens the physical communication channel to the compiler system 120. In some implementations, the communication interface 114 opens the physical communication channel to the compiler system 120 through a wired connection, including but not limited to an I2C connection, a UART connection, and the like. It should be appreciated that in some implementations, the communication interface can alternatively open a wireless communication channel to the compiler system. The method 300 then continues to step 332.

[0033] At step 332, the example system validates at least one of the communication channel and the compiler system. In some implementations, at least one of the system processor 102 and the security subsystem 106 validates at least one identifier associated with at least one of the communication channel between the local system 110 and the compiler system 120, the compiler system 120, the application user, etc. In some implementations, at least one of the system processor 102 and the security subsystem 106 validates at least one security protocol, protection, restriction, etc. associated with at least one of the communication channel between the local system 110 and the compiler system 120, the compiler system 120, the application user, etc. In some implementations, the identifier includes an access token, a validation key, a public key, etc. In some implementations, the security protocol, protection, restriction, etc. includes an encryption key, an encryption validation process, etc. It should be appreciated that in some implementations, the example system optionally validates the communication channel or the compiler system. The method 300 then continues to step 340.

[0034] At step 340, the example system obtains one or more secure partition addresses from the compiler system over the communication channel. In some implementations, the local system 110 obtains at least one partition table from the compiler system 120 over the communication interface 114. In some implementations, the partition table includes one or more addresses that define a system memory region of the system memory 108. In some implementations, the partition table includes one or more addresses that define a secure memory region of the secure memory 202. In some implementations, the partition table includes one or more addresses that define a secure access memory region of the secure memory 202. The method 300 then continues to step 342. At step 342, the example system compares the one or more secure partition addresses from the compiler system to one or more secure partition addresses at the local system. In some implementations, at least one of the system processor 102, the bootloader 104, and the security subsystem 106 compares the secure partition addresses from the compiler system 120 to the secure partition addresses at one or more of the system partition registers 112 and the secure partition registers 206. It should be appreciated that the example system optionally compares the secure partition addresses if no secure partition addresses are stored on the system partition registers 112 and the secure partition registers 206. It should be further appreciated that the example system optionally compares the secure partition addresses if one or more of the local processing system 110 and the compiler system 120 force an update, refresh, overwrite, etc. of one or more of the system partition registers 112 and the secure partition registers 206. The method 300 then continues to step 350.

[0035] At step 350, the example system determines whether the one or more partition addresses from the compiler system correspond to one or more partition addresses at the local system. In some implementations, at least one of the system processor 102, the bootloader 104, and the security subsystem 106 determines whether any of the secure partition addresses from the compiler system 120 are different from any pre-existing secure partition addresses at the local system 110. In some implementations, at least one of the system processor 102, the bootloader 104, and the security subsystem 106 also optionally determines whether any of the system partition addresses from the compiler system 120 are different from any pre-existing system partition addresses at the local system 110. In some implementations, at least one of the system processor 102, the bootloader 104, and the security subsystem 106 also optionally determines whether any of the secure access partition addresses from the compiler system 120 are different from any pre-existing secure access partition addresses at the local system 110.

[0036] According to a determination that the one or more secure partition addresses from the compiler system correspond to one or more secure partition addresses at the local system, the method 300 continues to step 360. In some implementations, if all of the partition addresses from the compiler system 120 match all of the pre-existing partition addresses at the local system 110, the method 300 continues to step 360. Alternatively, according to a determination that the one or more secure partition addresses from the compiler system do not correspond to one or more secure partition addresses at the local system 110, the method 300 continues to step 352. In some implementations, if any of the partition addresses from the compiler system 120 do not match any of the pre-existing partition addresses at the local system 110, the method 300 continues to step 352. In some implementations, any additional partition addresses received from the compiler system 120 result in a determination that the addresses do not correspond. In some implementations, any partition addresses that are not included in the partition addresses received from the compiler system 120 that pre-exist at the local system 110 result in a determination that the addresses do not correspond.

[0037] At step 352, the example system writes one or more partition addresses to one or more partition registers at the local system and the security subsystem of the local system. In some implementations, at least one of the system processor 102 and the bootloader 104 writes the system partition address to the system partition register 112. In some implementations, at least one of the security subsystem 106 and the bootloader 104 writes the secure partition address to the secure partition register 206. In some implementations, at least one of the security subsystem 106 and the bootloader 104 writes the secure access partition address to the secure partition register 206. The method 352 then continues to step 360. At step 360, the example system enters an operational state. In some implementations, the local system 110 enters an operational state that allows execution of application instructions stored on the system memory 108. In some implementations, the local system 110 receives the application instructions while receiving the partition table through the communication interface 114. In some implementations, the local system 110 enters the operational state directly. Alternatively, in some implementations, the local system enters the operational state after returning to the powered-on state, another intervening state, or a combination thereof. In some implementations, the method 300 ends at step 360.

[0038] Figure 4 FIG. 4 illustrates another example method of partitioning a non-transitory memory device into secure system address regions, according to the present implementation. In some implementations, the example system 100 performs the method 400 according to the present implementation. In some implementations, the method 400 begins at step 410.

[0039] At step 410, the example system obtains one or more compiled processor instructions. In some implementations, at least one of the build controller 122 and the partition generator 124 obtains the compiled processor instructions. In some implementations, the build controller 122 obtains the compiled processor instructions by generating the compiled processor instructions based on high-level code instructions. Alternatively, in some implementations, the partition generator 124 obtains the compiled processor instructions by receiving the compiled processor instructions generated by a compiler device or system that is different from the build controller 122. The method 400 then continues to step 420.

[0040] At step 420, the example system identifies one or more secure processor instructions based at least in part on the compiled processor instructions. In some implementations, the partition generator 124 identifies secure processor instructions. In some implementations, the partition generator 124 directly identifies compiled instructions that request access to one or more of the secure memory 202, secure objects, secure operations, etc. In some implementations, step 420 includes at least one of steps 422 and 424. At step 422, the example system identifies one or more secure processor operations. In some implementations, the partition generator 124 parses, traverses, reads, etc. the set of compiled processor instructions that identify one or more compiled processor operations. In some implementations, the set of compiled processor instructions includes an ELF file and identifies compiled function headers therein as the compiled processor operations. At step 424, the example system identifies one or more secure instructions associated with the identified secure processor operations. In some implementations, the example system associates, groups, collects, etc. one or more instructions associated with each compiled processor operation. As one example, the partition generator 124 can identify a compiled function based on an ELF file header and can associate a plurality of compiled instructions associated with the function header and one or more of its corresponding function bodies. In some implementations, the partition generator 124 identifies secure compiled processor instructions based on an association of a function header or function body that requests access to one or more of the secure memory 202, secure objects, secure operations, etc. In some implementations, the partition generator 124 identifies secure access compiled processor instructions based on an association of a function header or function body that requests access to one or more of the secure access objects, secure access operations, etc. The method 400 then continues to step 430.

[0041] At step 430, the example system assigns one or more secure addresses to one or more corresponding compiled processor instructions. In some implementations, the partition generator 124 assigns secure addresses associated with the secure memory 202. In some implementations, the partition generator 124 assigns secure addresses to compiled processor instructions associated with secure devices, data, functions, etc. of the secure subsystem 106. The method 400 then continues to step 440.

[0042] At step 440, the example system identifies one or more system processor instructions. In some implementations, the partition generator 124 identifies system processor instructions. In some implementations, the partition generator 124 directly identifies compiled instructions that operate independently or separately from one or more of the secure memory 202, secure objects, secure operations, etc. In some implementations, the example system identifies system processor instructions corresponding to identifying secure compiled processor instructions. Alternatively, in some implementations, the example system identifies system processor instructions as any instructions that are not identified as secure processor instructions. The method 400 then continues to step 450.

[0043] At step 450, the example system assigns one or more system addresses to one or more corresponding system processor instructions. In some implementations, the partition generator 124 assigns system addresses associated with the system memory 108. In some implementations, the partition generator 124 assigns secure addresses to compiled processor instructions that independently or separately access devices, data, functions, etc. of the secure subsystem 106. Alternatively, in some implementations, the example system assigns system addresses to any system processor instructions that are not identified as secure processor instructions. The method 400 then continues to step 460.

[0044] At step 460, the example system generates one or more secure address pairs based at least in part on one or more secure addresses. In some implementations, the partition generator 124 generates one or more secure address pairs that include all secure addresses. In some implementations, the partition generator 124 minimizes the number of memory addresses associated with the secure memory 202 by generating address pairs that include only all secure addresses. In some implementations, the partition generator 124 generates one or more secure access address pairs that include all secure access addresses. In some implementations, the partition generator 124 minimizes the number of memory addresses associated with the secure memory 202 by generating address pairs that include only all secure access addresses. The method 400 then continues to step 462. At step 462, the example system generates one or more system address pairs based at least in part on one or more system addresses. In some implementations, the example system generates system address pairs corresponding to generating secure address pairs. Alternatively, in some implementations, the example system generates system address pairs that include all addresses except for all secure address pairs and secure access address pairs. Thus, in some implementations, the system address pairs include all memory addresses that are not associated with secure addresses or secure access addresses. The method 400 then continues to step 470.

[0045] At step 470, the example system generates a partition table based at least in part on one or more of the secure address pairs and the system address pairs. In some implementations, the partition generator 124 generates one or more partition tables that include one or more of the system address pairs, the secure address pairs, and the secure access address pairs. The method 400 then continues to step 472. At step 472, the example system transmits the partition table to the local system. In some implementations, one or more of the partition generator 124 and the compiler system 120 transmit the partition table to the local system 110 via the communication interface 114. In some implementations, the method 400 ends at step 472.

[0046] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are illustrative of architectures for elements that can have many other architectures that achieve the same functionality. In general, the architecture of an element is independent of its implementation. In some embodiments, the herein described subject matter can be implemented with one or more computer systems. In some embodiments, the herein described subject matter can be implemented with one or more hardware- based systems. In some embodiments, the herein described subject matter can be implemented with one or more software-based systems. In some embodiments, the herein described subject matter can be implemented with one or more virtual systems. In some embodiments, the herein described subject matter can be implemented with one or more hybrid systems. In some embodiments, the herein described subject matter can be implemented with one or more distributed systems. In some embodiments, the herein described subject matter can be implemented with one or more centralized systems. In some embodiments, the herein described subject matter can be implemented with one or more peer-to-peer systems. In some embodiments, the herein described subject matter can be implemented with one or more mobile systems. In some embodiments, the herein described subject matter can be implemented with one or more cloud-based systems. In some embodiments, the herein described subject matter can be implemented with one or more systems that include any of the above, and / or any combination thereof.

[0047] With respect to the use of singular and / or plural terminologies herein, a skilled artisan can translate from the plural to the singular and / or from the singular to the plural, depending on the context and / or application. For the sake of clarity, various singular / plural permutations can be expressly set forth herein.

[0048] Those skilled in the art will appreciate that, in general, the terminology used herein, and especially in the appended claims (e.g., in the body of the appended claims), should not be limited to describe the preferred embodiment(s) herein. Rather, the terminology used herein is intended to describe all possible embodiments(s) which can be claimed under the scope of the claims. For example, unless otherwise indicated, the terms “including”, “includes” and / or “include” are used inclusively and not exclusively. In other words, the terms “including”, “includes” and / or “include” are used to indicate that the underlying claimable subject matter can include, but is not limited to, the recited elements.

[0049] Although the drawings and description can illustrate particular orders of performing methods steps, the order of steps can differ from those described and illustrated without departing from the scope of the disclosure. Also, unless explicitly stated otherwise, steps can be performed concurrently, or in different order than described and illustrated. For example, this can be the case when one or more steps are performed in parallel or when one or more steps are performed in different orders. All such variations and modifications are within the scope of the disclosure. Likewise, software implementations of the described methods could be accomplished with standard programming techniques with rule based logic and other logic to accomplish various connection steps, processing steps, comparison steps, and decision steps.

[0050] Those skilled in the art will further appreciate that, where any number of claims is intended to be invoked, such intent will be expressly recited in the claims section of the specification, and no intent will be inferred absent express recitation. For example, the following appended claims can contain introductory phrases such as “at least one” and “one or more” to introduce claim recitations. However, even when such introductory phrases are used, the use of such phrases in the claims should not be interpreted as implying that the inventive subject matter is limited to a specific number of recited claims (e.g., “at least one” and / or “one or more” should typically be interpreted to mean that any single recited claim can be used alone or in combination with any of the other recited claims); this applies equally to the use of definite articles (e.g., “the”) in the claims. Additionally, even if a specific number of claims is intended to be invoked, the use of introductory phrases such as “at least one” and “one or more” in the claims should not be interpreted as limiting the inventive subject matter to a specific number of recited claims (e.g., “at least one” and / or “one or more” should typically be interpreted to mean that any single recited claim can be used alone or in combination with any of the other recited claims); this applies equally to the use of definite articles (e.g., “the”) in the claims.

[0051] Further, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended to encompass A alone, B alone, C alone, as well as any combination of A, B, and / or C. For example, a phrase such as "at least one of A, B, or C" is intended to cover the

[0052] Further, unless otherwise noted, the use of the word "about" or "approximately" or "substantially" or "generally" or the like in connection with a term such as "x" is meant to encompass a range of values of + / - 10% of x.

[0053] The foregoing description of exemplary implementations has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the precise form disclosed, and modifications and variations are possible in light of the above teachings or from practice of the implementations disclosed. The scope of the disclosure is intended to be defined by the claims appended hereto and equivalents thereof.

Claims

1. A method of partitioning a non-transitory memory device, the method comprising: detecting a boot state of a processing device comprising a non-transitory memory device; identifying a launch state of the processing device based on the boot state; determining, from the launch state, that an operating state condition is satisfied; and partitioning the memory device into at least one secure address region in accordance with the determination that the launch state satisfies the operating state condition.

2. The method of claim 1, wherein partitioning the memory device further comprises: writing a first partition address to a partition register of the processing device associated with the secure address region.

3. The method of claim 2, wherein the first partition address is associated with processing instructions restricted to execution at a secure subsystem of the processing device.

4. The method of claim 2, further comprising: obtaining the first partition address at the processing device from an external device in accordance with the determination that the launch state satisfies the operating state condition.

5. The method of claim 4, wherein obtaining the first partition address comprises: obtaining the first partition address from a compiler system.

6. The method of claim 5, further comprising: authenticating a communication from the compiler system to the processing device, the communication comprising a first partition address.

7. The method of claim 2, wherein writing the first partition address further comprises: writing the first partition address to the partition register of the processing device in accordance with a determination that the first partition address satisfies an address condition.

8. The method of claim 7, wherein the determination that the first partition address satisfies the address condition comprises: a determination that the first partition address does not match a second partition address at the partition register.

9. The method of claim 1, further comprising: entering an operating state of the processing device in accordance with a determination that the launch state does not satisfy the operating state condition.

10. A method of generating a secure partition associated with a non-transitory memory device, the method comprising: identifying a target processing instruction restricted to execution at a secure subsystem of a processing device; assigning a secure address to the target processing instruction; associating the secure address with a secure address region of a non-transitory memory device of the processing device; generating a secure partition table comprising the secure address; and transmitting the secure address associated with the secure address region to the processing device.

11. The method of claim 10, wherein identifying the target processing instruction comprises: identifying the target processing instruction from a plurality of compiled processing instructions.

12. The method of claim 10, wherein identifying the target processing instruction comprises: identifying a compiled secure processing operation associated with the target processing instruction.

13. The method of claim 12, wherein the secure address comprises a first plurality of addresses associated with the compiled secure processing operation.

14. The method of claim 13, wherein the first plurality of addresses define a secure address range associated with the compiled secure processing operation.

15. The method of claim 13, wherein the plurality of addresses comprises: a first secure operation address defining a lowest address in the secure address range, and a second secure operation address defining a highest address in the secure address range.

16. The method of claim 10, further comprising: identifying a system processing instruction restricted to execution at a system processor of the processing device; assigning a system address to the system processing instruction; associating the system address with a system address region of a non-transitory memory device of the processing device; and generating a system partition table including the system address.

17. The method of claim 16, wherein identifying the system processing instructions further comprises: identifying a compiled system processing operation associated with the system processing instruction.

18. The method of claim 17, wherein the system address comprises a second plurality of addresses associated with the compiled system processing operation.

19. The method of claim 18, wherein the second plurality of addresses define a secure address range associated with the compiled secure processing operation.

20. A system comprising: a bootloader configured to detect a boot state and identify a launch state based on the boot state; a partition register operatively coupled to the bootloader and configured to partition a memory device into at least one secure address region according to a determination that the launch state satisfies an operating state condition; and a system processor operatively coupled to the bootloader, configured to obtain one or more addresses of a non-transitory memory device corresponding to at least one secure address region from an external device according to a determination that the launch state satisfies an operating state condition, write a partition address associated with the secure address region to the partition register according to the determination that the launch state satisfies the operating state condition, and further configured to enter an operating state of a processing device according to a determination that the launch state does not satisfy the operating state condition.

Images