Security invasive and non-invasive real-time diagnostics across security boundaries

Abstract

Embodiments of the invention relate to security invasive and non-invasive real-time diagnostics across security boundaries. Systems and methods may include bus monitoring hardware logic (410), wherein the bus monitoring hardware logic may monitor signals (213) on one or more buses of a processing unit (210), such as a central processing unit (CPU). Security logic may associate the code portions with code isolation units, such as links, stacks, and regions. Gating logic in the bus monitoring hardware logic may then enable or disable a monitoring function for a read or write access request based on a link, stack, or region identity associated with a code segment making the read or write access request.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 524,945, filed on July 5, 2023, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present application relates generally to central processing unit (CPU) bus monitoring, and more particularly to enforcing access protection for CPU bus monitoring. Background Art

[0004] Bus monitor and diagnostic modules that monitor central processing unit (CPU) activity for events are used for debugging and diagnostics of real-time systems. From a safety and security perspective, various tasks or code execution segments from the CPU may have different access rights and privileges. This is typically managed by some form of memory management protection unit. However, currently there is no robust technology for enforcing access rights to bus monitor modules.

[0005] There is a need in the art for more robust access rights enforcement. Summary of the invention

[0006] In one example, a device includes: a central processing unit (CPU) having a first bus coupling the CPU to a memory, wherein the CPU is configured to generate a hardware signal identifying a code isolation associated with a code portion executed by the CPU; bus monitor hardware logic coupled to the first bus, wherein the bus monitor hardware logic includes a first register, further wherein the bus monitor hardware logic is configured to: receive a first write operation from an application running on the CPU, wherein the first write operation causes a first value to be written to the first register, the first value indicating ownership of the application; write a second value to the first register based on the hardware signal from the CPU, wherein the second value identifies a first code isolation of the application; receive a memory access request on the first bus and receive a code isolation identification from the CPU on the hardware signal; and determine whether to monitor the memory access request on the first bus based at least in part on whether the code isolation identification on the hardware signal corresponds to the second value.

[0007] In another example, a device includes: a plurality of bus monitor modules coupled to a plurality of buses, wherein a first bus monitor module of the plurality of bus monitor modules is configured to: store application ownership information in a first register; store code isolate ownership information in the first register, wherein the code isolate ownership information corresponds to a first code isolate associated with an application, wherein the code isolate ownership information is received externally from the first bus monitor module on a hardware signal; receive a memory access request from application code on a first bus of the plurality of buses; and adjust operation of the first bus monitor module based at least in part on whether the application code is associated with the first code isolate, as indicated by the code isolate ownership information stored in the first register.

[0008] In yet another example, a method includes: receiving a first write operation from an application running on a central processing unit (CPU), wherein the first write operation is configured to store application ownership information in a first register of bus monitor hardware logic; storing code isolation ownership information in the first register, including receiving the code isolation ownership information from the CPU on a hardware signal; receiving an access request from application code executing on the CPU; receiving information associating the access request with a first code isolation on the hardware signal; and allowing or denying monitoring of the access request based on whether the code isolation ownership information indicates the first code isolation. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Having thus generally described the invention, reference will now be made to the accompanying drawings, in which:

[0010] Figure 1 is an illustration of example code isolation according to various embodiments.

[0011] Figure 2 is a diagram of an example system for CPU bus monitoring in accordance with various embodiments.

[0012] Figure 3 is a diagram of an example implementation of a security control unit in accordance with various embodiments.

[0013] Figure 4 is a diagram of an example architecture including a CPU and bus monitoring hardware in accordance with various embodiments.

[0014] Figure 5 is a diagram of an example bus monitor module in accordance with various embodiments.

[0015] Figure 6 is an illustration of an example table of operational functionality of gating logic according to various embodiments.

[0016] Figure 7 is a diagram of an example table of semaphore registers used to indicate ownership status according to various embodiments.

[0017] Figure 8 is a diagram of an example architecture in accordance with various embodiments.

[0018] Fig. 9 is an illustration of an example method for enforcing access permissions during bus monitoring in accordance with various embodiments. DETAILED DESCRIPTION

[0019] The present disclosure is described with reference to the accompanying drawings. The figures are not drawn to scale, and the figures are provided only to illustrate the present disclosure. Several aspects of the present disclosure are described below with reference to the example applications used for illustration. It should be understood that numerous specific details, relationships and methods are set forth to provide an understanding of the present disclosure. The present disclosure is not limited by the description order of actions or events, because some actions can occur in different orders and / or simultaneously with other actions or events. In addition, all described actions or events are not required to implement the method according to the present disclosure.

[0020] Various embodiments provide systems and methods for enforcing access rights to debug probe hardware, such as a bus monitor module. In one example, a central processing unit (CPU) has a bus that couples the CPU to a memory. In practice, the CPU may have multiple buses, such as a data bus, a program counter bus, and an address bus. One or more of the buses may be coupled directly or indirectly to the memory. The CPU is also configured to generate a hardware signal that identifies a region associated with a portion of code executed by the CPU.

[0021] Continuing with the example, bus monitor hardware logic is coupled to the bus and can be used to monitor debug events, such as a given set of values ​​present on the bus. An example of bus monitor hardware logic may include an enhanced bus comparator (EBC) or other hardware logic that can generate monitor information from CPU bus signals. The bus monitor hardware logic may include a first register to store ownership information and access information of the bus hardware logic. The bus monitor hardware logic may be configured to receive a write operation from an application running on the CPU. The write operation causes a first value to be written to the first register to indicate ownership of the application. When the bus monitor logic is owned by the application, other applications may be prevented from utilizing or reading the bus monitor hardware logic. Other examples of ownership may include debugger ownership or no ownership.

[0022] The bus monitor hardware logic may also be configured to write the second value to the first register. In one example, the bus monitor hardware logic receives a hardware signal identifying a zone, and the bus monitor hardware logic may store the zone identifier as the second value in the first register. In this way, the bus monitor hardware logic may store the zone identifier based on a hardware signal output by the CPU rather than under the control of the application itself. The zone information may be used to permit other applications in the same zone as the owning application to utilize or read the bus monitor hardware logic, and may be used to restrict the bus monitor hardware logic to only analyze bus transfers associated with the same zone.

[0023] Subsequently, the bus monitor hardware logic may receive a memory access request on the first bus. The memory access request may include a read or write operation from the CPU to the memory. The bus monitor hardware logic may also receive information about a hardware signal that identifies a region associated with a portion of the executed application code. The bus monitor hardware logic may compare the region identifier from the hardware signal with a second value stored in the first register. The bus monitor hardware logic may determine whether to monitor the memory access request based at least in part on whether the region identifier on the hardware signal corresponds to the second value. For example, if the region identifier matches the second value, then the bus monitor hardware logic may monitor the memory access request. On the other hand, if the region identifier does not match the second value, then the bus monitor hardware logic may not monitor the memory access request.

[0024] Continuing with the example further, various embodiments allow for access rights to be enforced based on some segregation, such as by zone. For example, as the CPU executes code, the context may change. In one example, the context may change from a context associated with link 0 to one associated with link 7, to one associated with link 2, and so on. Various links may be associated with zones, and some zones may be associated with multiple links. In the above example, if the second value stored in the first register is zone 0, and if the zone identification on the hardware signal indicates something other than zone 0, then the particular code segment that issued the memory access request may not be monitored by the bus monitor hardware logic.

[0025] In another example, an application running on the CPU may release the bus monitor hardware logic from ownership. For example, the application may write an indication of no ownership as a first value to a first register. Subsequently, a debugger may assert ownership by writing debugger ownership as the first value to the first register. Ownership may change with use and during run time, development time, or at other appropriate times.

[0026] Various embodiments may provide advantages over existing solutions. For example, the embodiments described herein may allow isolation-based access rights. In the above example, a code segment corresponding to zone 0 would not be allowed to monitor the execution of another code segment corresponding to zone 1. Therefore, the code corresponding to zone 1 may remain safe from copying, tampering, or other misuse due to actions attributable to the code corresponding to zone 0. In other words, various embodiments may provide enhanced security for a computer system.

[0027] In addition, various embodiments may allow access permissions to be set for individual instances of bus monitor hardware logic. Some systems may include multiple instances of bus monitor hardware logic, for example, two, four, 16, or any suitable number. Each of the different instances of bus monitor hardware logic may independently own and may independently store zone identifications. In other words, the scope of the implementation may include a certain number of bus monitor hardware logic instances scaled as needed. Thus, various embodiments may provide enhanced security while allowing multiple zones to be monitored during overlapping times.

[0028] Of course, while the examples herein describe techniques for enforcing zone-based access permissions, the concepts herein may be applicable to other code isolations, such as links, stacks, etc.

[0029] Figure 1 is a diagram of example links, stacks, and zones according to various embodiments. In this example, there are seven links, Link 1 - Link 7. There are three stacks (SP), Stack 1 - Stack 3. There are also three zones (Z), Zone 1 - Zone 3.

[0030] Each of the links is a collection of address ranges. For example, there may be one or more memories, such as on-chip flash memory, that store machine code instructions and data for execution. Each link refers to an address range or multiple address ranges of machine code instructions and data. During execution, a link may be referred to as a context.

[0031] Stack is a concept in some programming languages ​​(such as C programming), and also refers to address range. In C programming and some other programming languages, stack is a data structure that follows the last-in-first-out (LIFO) principle. Stack is used to manage function calls, local variables and maintain program execution. For example, when a function is called, its local variables and return address are pushed onto the stack. When the function is completed, these values ​​are popped out of the stack. In another example, the stack is used to track the control flow between different parts of the execution program and the management program. In some examples, more than one program can share a given stack, and each stack can be associated with one or more links.

[0032] Zones are an isolation concept that was developed. For example, a processor may have access enforcement where some users can access some zones but not others, and user rights may be different for different users. Figure 1 , links 1-5 are all associated with stack 1. Stack 1 is associated with zone 1. Link 6 is associated with stack 2, which is associated with zone 2. Link 7 is associated with stack 3, which is associated with zone 3. The scope of an embodiment may include zone 3 that is configured for use only by the manufacturer of the device. Furthermore, the scope of an embodiment may include zone 2 that has some other lower security, such as being configured for use by the manufacturer and some trusted downstream business partners. Still further, the scope of an embodiment may include zone 1 that has even lower security, such as being open to various authorized third-party application programmers. In such embodiments, the authorized third-party application programmers will not be able to access zone 2 or zone 1.

[0033] In other words, links can act as memory protection units for memory and peripherals. Stacks can accomplish hardware context separation. Zones can govern development time isolation, such as for debugging, firmware updates, security updates, etc. The number of links, stacks, and zones can vary from device to device, such as for Figure 1 The numbers of links, stacks, and zones are for illustrative purposes.

[0034] The information in the registers may be used to define the relationships between links, stacks, and zones. For example, a security control unit (e.g., as in Figure 2 ) may contain numerous registers with information used to define links, stacks, and regions.

[0035] Figure 2 2 is a diagram of an example system 200 according to various embodiments. System 200 may be implemented on one or more semiconductor dies. For example, CPU 210, security control unit 220, and memory 204 may be implemented as a system on a chip (SOC) or may be implemented using one or more separate dies in a semiconductor package. One example use case is an embedded system, such as an advanced microcontroller unit (MCU), which may be intended for use in automobiles, industrial machines, etc. However, the scope of the implementation is not limited to any particular use case, such as an embedded system or otherwise.

[0036] CPU 210 may be a general purpose CPU, a reduced instruction set computer (RISC), an application specific integrated circuit (ASIC), a graphics processing unit (GPU), or any other suitable processing unit. CPU 210 fetches instructions and data from memory 240 and then executes those instructions using a processing pipeline. The processing pipeline may include, for example, a fetch stage, a decode stage, a read stage, an execute stage, a write stage, etc. The processing pipeline is not limited to any particular implementation.

[0037] Security control unit 220 enforces access permissions for memory 240. For example, CPU 210 may send a read access request to security control unit 220 on bus 212. Security control unit 220 may determine whether the read or write access request complies with the access permissions and may then allow or deny the access request.

[0038] Memory 240 may be on-chip memory, off-chip memory, a group of different memory devices, or any suitable memory. In this example, memory 240 includes multiple memory regions that CPU 210 can read or write to via multiple read or write operations 221. Security control unit 220 may include a register array that stores information defining regions, stacks, and links and may facilitate access rights enforcement.

[0039] In one example, the CPU fetches instructions and data from memory 240, such as on-chip flash memory. Instructions and data are written to a specific address range, where the specific address range corresponds to, for example, the address range described above with respect to Figure 1 The security control unit 220 monitors the instruction bus (e.g., in bus 212) for extraction of instructions and / or data, parses the information in the extraction, and determines that the extraction corresponds to a specific link, stack, and zone. The security control unit 220 then passes the link identification, stack identification, and zone identification information back to the CPU 210 using hardware signal 211.

[0040] Continuing with the example, the CPU begins processing instructions and data according to its processing pipeline. The processing pipeline may include one or more read or write access requests on bus 212. CPU 210 may include link identification, stack identification, and region identification information in hardware signals on bus 212 and / or in hardware signal 213. For example, the CPU may pass link identification, stack identification, and region identification information during subsequent requests for system resources (e.g., requests for ownership of debug probe hardware). For the purpose of access permission enforcement, the security control unit 220 may then use the link identification, stack identification, and region identification in signal 213. For example, if a link (which may be referred to as a context during runtime) can access a specific memory area, the security control unit 220 may allow the access request; otherwise, the security control unit 220 may deny the access request. The read or write operation performed is illustrated by read write operation 221.

[0041] In this example, hardware signals 211, 213 and signals on bus 212 include one or more bits transmitted from one piece of hardware logic to another piece of hardware logic on one or more buses. The bits may be transmitted in parallel or serially, depending on the particular architecture. Thus, in some embodiments, the instructions for performing the operations described above may be performed without the use of firmware or software functions. Fig. 9 Communications and actions described.

[0042] System 200 may also include debug probe hardware, such as embedded real-time analysis and diagnostics module (ERAD) 230. ERAD 230 is an advanced bus monitor unit, and it may include a plurality of different hardware units that are each configured to monitor signals on the bus of CPU 210. For example, ERAD 230 may monitor a program bus and a data bus, a program counter bus, or any other suitable bus to detect the occurrence of a given value or value pattern, such as with respect to Figure 4 Explain in more detail. Figure 2 In the example of , ERAD 230 monitors the CPU bus and therefore has access to read and write requests as well as link, stack and region identification information. Figure 2 In the example of , the program bus and the data bus, program counter bus may be included in bus 212.

[0043] Figure 3 2 is a diagram of an example implementation of a security control unit 220 according to various embodiments. The security control unit 220 includes a configuration register and extraction zone decoder 302. The configuration register and extraction zone decoder 302 include a register array that stores information indicating the association between the zone and stack and the address, stack, and link. When the CPU 210 extracts instructions, the extraction can be monitored by the security control unit 220, and the information in the extraction can be used to determine the link identification, stack identification, and zone identification information using the configuration register and extraction zone decoder 302. The security control unit 220 can then transmit the link identification, stack identification, and zone identification information on the hardware signal 211.

[0044] In one example, the CPU 210 may transmit a memory access request (e.g., a read request or a write request) to the security control unit 220 on the bus 212. The memory access request on the bus 212 may include link identification, stack identification, and region identification information for the context being executed, or the link, stack, and region identification information may be determined by the security control unit 220 according to the nature of the memory access request (e.g., the target address). The security control unit 220 may then compare the link identification information with permission information (not illustrated), and then allow or deny read or write access based on direct access rights.

[0045] Specifically, access protection logic 310 is hardware logic of security control unit 220. Access protection logic 310 can receive hardware signals on bus 212 and hardware signals 213, and then determine whether to allow access to a specific memory area. Access protection logic 310 can also be configured to enable or disable debug access based on link, stack and / or region information, such as Figure 6Explain in more detail.

[0046] Figure 4 4 is a diagram of an example architecture 400 including an example CPU 210 and an example ERAD 230 according to various embodiments. For ease of illustration, Figure 4 The security control unit 220 is omitted, but it should be understood that the architecture 400 does not exclude the security control unit 220 .

[0047] The ERAD 230 contains multiple bus monitor modules (also called enhanced bus comparators, EBCs) and multiple system event counters or SEC units. However, for ease of description, Figure 4 A single bus monitor module 410 and a single SEC unit 420 are shown.

[0048] The bus monitor module 410 may be configured to generate hardware breakpoints, hardware watchpoints, debug triggers, and other output events based on the information monitored on the CPU bus. For example, the bus monitor module may generate an event whenever a given value or value pattern is detected on the bus. The SEC unit 420 may be configured to analyze and summarize the system by counting system events or output events from the bus monitor module 410. The SEC unit 420 may be configured to send debug triggers to the CPU 210.

[0049] The bus monitor module 410 may be connected to the CPU 210 through a connection similar to a direct memory interface. The bus monitor module 410 may monitor the buses - the address bus, the data bus, and the program counter bus - connected between itself and the CPU 210. In the bus monitor module 410 itself, masks may be defined to perform greater than, less than, or equal to comparisons on bus data.

[0050] After the bus monitor module 410 has received and processed the information, the bus monitor module 410 may then perform actions, such as providing commands for debugging pauses or breaks. In the context of ERAD 230 being used as a debugger, the bus monitor module 410 may be used to generate breakpoints and watchpoints. Additionally, in application code, the bus monitor module 410 may be used to generate real-time operating system (RTOS) interrupts or event outputs that may be used by other bus monitor modules or SEC units.

[0051] The SEC unit 420 may be configured to receive input from the output of the bus monitor module 410 or external system events, such as peripheral interrupt expansion (PIE) interrupts, timer interrupts, and control law accelerator (CLA) task interrupts. The SEC unit 420 may be configured to function as a counter, thereby allowing benchmark and overview analysis.

[0052] In an example implementation of architecture 400, ERAD 230 is coupled to a bus that transmits hardware signals 213 that include link, stack, and zone identification information. This link, stack, and zone information can be used to selectively monitor only those specific bus values ​​that have a specified link, stack, or zone. For example, if bus monitor module 410 of ERAD 230 is owned by an application in a given zone, bus monitor module 410 can be limited to monitoring only those bus values ​​that match a specified pattern and are also associated with an application in the same zone. This prevents the owning application from monitoring the activities of a safer application.

[0053] In some examples, signal 213 may be a sideband strobe, but the scope of the embodiments is not limited to any particular format of hardware signals. ERAD 230 is also coupled to a program bus, a data bus, and a program counter bus. Bus monitor module 410 may receive information from any or all of those buses, may parse and store information from any of those buses, and may take various actions based on information from any or all of those buses.

[0054] In one example, the bus monitor module 410 may monitor the memory addresses of function calls that include read and write accesses. The bus monitor module 410 may be programmed to generate an interrupt when a read or write access points to a memory address range above a specific address range (e.g., 8000). For example, read and write accesses reaching an address range above the specific address range may indicate a stack overflow. Therefore, the bus monitor module 410 may be programmed to generate an interrupt to prevent additional failures due to stack overflow. Of course, this is only an example, and the bus monitor module 410 may be configured in any suitable manner.

[0055] In some examples, bus monitor module 410 may include hardware logic configured to receive signals on the bus from CPU 210. In addition, the hardware logic may be configured with registers into which setup information and control information may be stored, thereby changing the functionality of bus monitor module 410.

[0056] Additionally, as noted below, bus monitor module 410 may include hardware logic configured to enforce access permissions.

[0057] Figure 5 4 is an illustration of an example bus monitor module 410 in accordance with various embodiments. As noted above, ERAD 230 may include multiple bus monitor module instances, and bus monitor module 410 is exemplary of one such instance that may be repeated in ERAD 230.

[0058] The bus monitor module 410 includes an ownership register 505. In the example, the ownership register 505 includes three different fields 502-504 therein. Although the ownership register 505 is described as one register, it should be understood that the scope of the implementation may include one or more registers configured to perform the functions of the ownership register 505. Furthermore, it should be understood that in these examples when discussing registers, the registers may be implemented as one or more registers as desired.

[0059] In this example, field 502 is referred to as XX; field 503 may be referred to as ZZ; and field 504 may be referred to as S.

[0060] Field 502 may be referred to as a master ownership value, indicating a master ownership mode. In this example, ownership indicates exclusive use, at least until ownership is released. In one example, a value of 00 indicates no owner, a value of 01 indicates ownership by an application, and a value of 10 may indicate ownership by a debugger. When field 502 indicates no owner, an application code or a debugger may claim ownership of the bus monitor module 410. When field 502 shows ownership by a debugger, the application code is not allowed to use the bus monitor module 410 unless and until the debugger releases ownership of the bus monitor module 410. When field 502 shows ownership by an application, the debugger cannot use the bus monitor module 410 until and unless the application code releases ownership. Additionally, in this example, when field 502 shows ownership by an application, the gating logic 510 performs a region-based check to enforce access permissions, which may include preventing other applications from accessing the bus monitor module 410 and / or preventing the bus monitor module 410 from monitoring requests associated with other applications. Of course, ERAD 230 may include multiple bus monitor module instances, each of which may reflect different ownership information.

[0061] Field 503 may be referred to as the zone identifier of the current owner. Figure 1 The zones are described in more detail. In some examples, one or more of the zones may be associated with a debugger, and one or more zones may be associated with one or more applications. In other words, in some embodiments, only applications may have different contexts. However, in some embodiments, field 503 may be used for gating only when field 502 indicates ownership of an application.

[0062] Some embodiments may include links that are configured in the architecture to have special privileges and may be referred to as "secure root links" or SROOT links. For example, one of the links may be designated as having special access privileges greater than any other link. Field 504 may indicate SROOT link ownership. In one example, when field 504 stores a specific numeric value indicating a SROOT link, gating logic 510 may allow all accesses to be monitored without filtering. Thus, if code executed from the SROOT link takes ownership of bus monitor module 410, bus monitor module 410 may be allowed to monitor all bus activity.

[0063] During operation, gating logic 510 may parse information in hardware signal 213 to determine link, stack, and region identification information. Gating logic 510 may compare the information with ownership information in register 505 and then enable or disable monitoring function 520 based on the comparison.

[0064] Figure 6 is an illustration of an example table 600 according to various embodiments. Example table 600 illustrates the operational functionality of gating logic 510 in one specific example. It should be understood that different embodiments may use different values ​​in different ways to achieve similar results, and thus the scope of the embodiments is not limited to the values ​​and actions of example table 600.

[0065] According to table 600, a value of 00 indicates no ownership and is also the reset value. When field 502 stores a value of 00, an application or debugger may write to field 502 to assert ownership on bus monitor module 410. During debugger ownership, any entity that reads field 502 may see debugger ownership, and the debugger may write to field 502 only if the current value is 00 or 01. Similarly, during application ownership, any entity that reads field 502 may see application ownership, and the application may write to field 502 only if the current value is 00 or 10.

[0066] Field 503 is the region ID, and in this example, the field is only used when field 502 shows ownership of an application. Gating logic 510 may populate field 503 based on information in signal 213. For example, during ownership assertion, signal 213 indicates link, stack, and region identification information for the code segment making the ownership assertion. The code segment may belong to a specific application, operating system, etc. In the example where an application writes to field 502 to assert ownership, gating logic 510 populates field 503 with the region identification from signal 213. This action may be performed without the involvement of an operating system executing on CPU 210 or an application executing on CPU 210.

[0067] In brief, table 600 indicates that when the bus monitor module 410 is in the no-owner state, the registers are not writable without first claiming ownership. When the block is owned by the debugger, the debugger itself may program the registers of the bus monitor module 410 without security concerns. When the block is owned by the application, only accesses originating from the corresponding region that owns the bus monitor module 410 may write to the ownership registers 505 of the bus monitor module 410.

[0068] However, the gating logic 510 can be programmed so that the bus monitor module security is based on the granularity of zones other than the SROOT link. For example, if the bus monitor module 410 is owned by the SROOT link, then the gating logic 510 can allow monitoring. Furthermore, in this example, a valid access can generate a trigger regardless of which zone performs the access, e.g., if the bus monitor module 410 is owned by the SROOT link, then any matching access from a particular zone will generate a trigger.

[0069] In one example, bus monitor module 410 is not owned, so field 502 stores 00 and field 503 stores 0000. The debugger then attempts to assert ownership on bus monitor module 410. The debugger may write 01 to field 502 because writes are permitted when the existing value in field 502 is 00. The write operation to field 502 is successful, and field 503 remains at 0000. Logic on bus monitor module 410 (e.g., logic 510, or perhaps software logic, not shown) reads back the value in field 502 to confirm that field 502 stores 01 as a value. In other words, ownership is confirmed. The debugger may then configure and begin using bus monitor module 410.

[0070] During debugger ownership, if an application attempts to write to field 502, the gating logic 510 may prevent the write access. In one example, when the debugger owns bus monitor module 410, bus monitor module 410 (i.e., monitoring function 520 is enabled) will only monitor those accesses whose corresponding regions are enabled for debugging. If code is being executed from a region that is not enabled for debugging, the operation of bus monitor module 410 will be shut down by gating logic 510 (i.e., monitoring function 520 is disabled).

[0071] The monitor function 520 of the debugger may include, for example, a comparator operation. When a value appears across the CPU bus, the comparator operation may then store the value to the register 530 based on the result of the comparator operation. For example, an address range for a read or write operation may be compared to a setting or limit, and then the monitor function 520 may store the value to the register 530 based on the comparison. The data stored in the register 530 may be used to generate an interrupt or other event, as may be configured in the monitor function 520.

[0072] Once the debugger has completed its work, it can deassert ownership by writing 00 to field 502. When the write is successful, field 502 stores 00, and field 503 continues to store 0000.

[0073] Continuing with the example, the application attempts to assert ownership on the bus monitor module 410. In this example, the application's actions are performed by the portion of the code corresponding to the context (or link) associated with the zone. For the purposes of this example, the zone is zone 2. The application writes 10 to field 502, and the write operation is valid because the existing value in field 502 is 00. Once the write operation to field 502 is successful, the gating logic 510 populates field 503 with the zone ID information from signal 213. For example, zone 2 may correspond to the value 0010 in field 503. Again, the logic inside the bus monitor module 410 may populate field 503 based on the information in the hardware signal 213 without interference or influence from the code running on the CPU 210. The logic in the bus monitor module 410 reads back the value stored in field 502 and confirms ownership. The application code from zone 2 now configures and begins using the bus monitor module 410. As noted above, the application code may configure the monitoring function 520 and cause the monitoring function to perform monitoring on the bus signals from the CPU.

[0074] During the application ownership, if application code from another zone (e.g., zone 3) attempts to write to field 502, the gating logic 510 blocks the access as invalid. Additionally, during the application ownership, if a debugger attempts to write to field 502, the gating logic 510 will also block the access. Once the application code corresponding to zone 2 has completed its work, the application code can release ownership by writing the value 00 to field 502. Once the write operation is successful, field 502 stores 00, and the gating logic 510 automatically resets the value in field 503 to 0000. The bus monitor module 410 is then in the default mode, unowned, and waits for the assertion of ownership by the application code or debugger.

[0075] Figure 7is a diagram of an example table 700 according to various embodiments. Various embodiments employ a semaphore register to indicate ownership status. In this way, a code portion running on a CPU and belonging to an application can identify or reconfirm whether a particular bus monitor module belongs to a region corresponding to the code portion. Therefore, field 504 can be used for a semaphore register. For a debugger read operation, in embodiments where the region information is irrelevant during debugger ownership, field 504 can always return a value of 0. However, in embodiments where the region information is not irrelevant during debugger ownership, a debugger read can be performed similarly to an application read. As an example of an application read operation of field 504, if the access region ID matches, then the operation returns 1, and if the access region ID does not match, then the operation returns 0. In one example, gating logic 510 can read the region ID information from hardware signal 213 and compare the region ID information with field 503, and then fill field 504 based on the comparison.

[0076] Figure 8 is a diagram of an example architecture 800 according to various embodiments. In architecture 800, ERAD 230 is illustrated as including a plurality of bus comparator units 0...N, which correspond to examples of EBC units, such as bus monitor module 410.

[0077] In the example of architecture 800, ERAD 230 is coupled to a CPU bus (e.g., a data bus, an address bus, a program counter bus) and a bus carrying hardware signals 213 (e.g., a sideband signal). Each of the bus comparator units may include gating logic 510, ownership register 505, monitoring function 520, and register 530, such as described above with respect to Figure 5 In addition, some embodiments, such as in architecture 800, may perform writes on behalf of a debugger via the secure control unit 220. Specifically, when read and write operations are performed on behalf of a debugger, read and write operations to the ownership register 505 may be performed by the SSU 220. In other words, the SSU 220 may be configured to perform read operations and write operations as needed and on behalf of other entities, such as a debugger.

[0078] Fig. 9 9 is a diagram of an example method 900 for enforcing access permissions during bus monitoring according to various embodiments. The actions of method 900 may be performed by bus monitor hardware logic, such as bus monitor module 410. In one example, the hardware logic is implemented using aggregation of logic gates into one or more logic cells, where these logic cells communicate with the bus to receive hardware signals and transmit hardware signals. In this example, such actions may not require intervention by software or firmware.

[0079] At action 902, the bus monitor hardware logic receives a first write operation from an application running on the CPU. For example, the first write operation may include an attempt to establish ownership, such as by writing a value to an ownership register. For example, Figure 5-7 In the example of , the application can establish ownership by writing 10 to field 502.

[0080] At action 904, the bus monitor hardware logic may then store the region ownership information in a first register. In one example, the bus monitor hardware logic may receive the region identification information in a hardware signal (e.g., hardware signal 213). Figure 5-7 In the example of FIG. 5 , the bus monitor hardware logic may then populate field 503 with the region identification information.

[0081] At action 906, the bus monitor hardware logic receives an access request from the application code executing on the CPU. For example, the access request may be directed to memory, and the bus monitor hardware logic may non-intrusively parse the information in the access request. Figure 4 In an example of , access requests may be transmitted on one or more of a program bus, a data bus, or a program counter bus. However, the scope of the embodiments is not limited to any particular bus.

[0082] At act 908, the bus monitor hardware logic may receive information on a hardware signal associating the access request with the first region. Figure 2 In the example of , hardware signal 213 carries link, stack, and region identification information with the access request, thereby identifying the code segment making the access request. Continuing with this example, the bus monitor hardware logic can parse the information on hardware signal 213, which specifically identifies the region associated with the code portion of the access request making action 906.

[0083] At action 910, the bus monitor hardware logic may then allow or deny monitoring of the access request based on whether the region ownership information indicates the first region. For example, the region ownership information of action 904 is stored to a first register, and the bus monitor hardware logic may then compare the information from action 908 with the region ownership information stored at action 904. In the event of a match, the bus monitor hardware logic may then allow monitoring. In the event of a mismatch, the bus monitor hardware logic may then deny monitoring.

[0084] In instances where monitoring is allowed or denied, Figure 5The gating logic 510 is illustrated to perform a comparison and then enable or disable monitoring functionality 520. The monitoring functionality may include any appropriate functionality, such as comparator functionality and register write functionality based on information on the CPU bus. The gating logic 510 may perform a comparison and then enable or disable monitoring functionality 520 based on ownership information in register 505 and information transmitted on a hardware signal (e.g., hardware signal 213). The gating logic 510 may perform these actions without being affected by the portion of code running on the CPU. In other words, the gating logic 510 may allow or deny monitoring in a manner that may not be affected by the application itself. Various embodiments may provide benefits to a computer system by increasing security in at least some cases, including shielding the monitoring functionality from influence or control by the application.

[0085] The scope of the implementation plan is not limited to Figure 5 . In practice, some embodiments may add, omit, rearrange, or modify one or more of the actions. In one example, method 900 may include actions performed by a CPU. For example, the CPU may receive link, stack, and zone identification information from a security control unit and then transmit the link, stack, and zone identification information with each access request. The CPU may also execute a code portion, and the code portion may include functionality to write ownership to ownership register 505 as needed.

[0086] In addition, various embodiments may include actions for the debugger to establish ownership. For example, after the application relinquishes ownership of the bus monitor hardware logic, the debugger may attempt to establish ownership of the bus monitor hardware logic. The debugger may then configure the bus monitor hardware logic and relinquish ownership once the work is complete.

[0087] Additionally, while method 900 is discussed with respect to one instance of bus monitor hardware logic, some architectures may include multiple instances of bus monitor hardware logic, e.g. Figure 8 , where ERAD 230 includes N instances of a bus comparator unit. Each of those instances of the bus monitor hardware logic can operate independently and simultaneously.

[0088] Additionally, a specific instance of the bus monitor hardware logic may repeat the actions of method 900. For example, the CPU may execute code portions corresponding to different links and regions, and may switch between code portions, such as when a context makes a function call to another context. Ownership of an instance of the bus monitor hardware logic may or may not change as the code portion being executed changes. However, as code portions are executed, some of those code portions may establish and relinquish ownership of a specific instance of the bus monitor hardware logic, thereby causing method 900 to be executed.

[0089] Furthermore, assuming monitoring is enabled at action 910, the bus monitor hardware logic may perform monitoring. The monitoring may include comparing information on the CPU bus to settings and then writing the results to one or more registers (e.g., register 530). The monitoring may or may not result in an action being taken, such as generating an interrupt or event.

[0090] While the above examples are particularly directed to regulating monitoring based on zone ownership, the scope of the embodiments may include regulating monitoring based on any type of code isolation. For example, in addition to or in lieu of populating field 503 with a zone identity, ownership register 505 may also include fields to be populated with a link identity and / or a stack identity. Gating logic 510 may then enable or disable monitoring functionality 520 based on the link, stack, and / or zone information in signal 213. In other words, while gating logic 510 may enable or disable based on zone-level granularity, the granularity may be adapted for links and / or stacks as needed.

[0091] The term "semiconductor die" is used herein. A semiconductor device may be a discrete semiconductor device such as a bipolar transistor, several discrete devices such as a pair of power FET switches fabricated together on a single semiconductor die, or a semiconductor die may be an integrated circuit having multiple semiconductor devices, such as multiple capacitors in an A / D converter. Semiconductor devices may include passive devices such as resistors, inductors, filters, sensors, or active devices such as transistors. A semiconductor device may be an integrated circuit having hundreds or thousands of transistors coupled to form a functional circuit, such as a microprocessor or memory device. A semiconductor device may also be referred to herein as a semiconductor device or an integrated circuit (IC) die.

[0092] The term "semiconductor package" is used herein. A semiconductor package has at least one semiconductor die electrically coupled to a terminal, and has a package body that protects and covers the semiconductor die. In some arrangements, multiple semiconductor die may be packaged together. For example, a power metal oxide semiconductor (MOS) field effect transistor (FET) semiconductor device and a second semiconductor device (e.g., a gate driver die or a controller die) may be packaged together to form a single packaged electronic device. Additional components such as passive components (e.g., capacitors, resistors, and inductors or coils) may be included in the packaged electronic device. The semiconductor die is mounted with a package substrate that provides conductive leads. A portion of the conductive leads forms a terminal for the packaged device. In a wire-bonded integrated circuit package, bonding wires couple the conductive leads of the package substrate to bonding pads on the semiconductor die. The semiconductor die may be mounted to a package substrate, wherein the device side surface is facing away from the substrate and the back side surface faces the die pad of the package substrate and is mounted to the die pad. The semiconductor package may have a package body formed by a thermosetting epoxy molding compound in a molding process or by using an epoxy, plastic, or resin that is liquid at room temperature and subsequently cured. The package body may provide a hermetic package for a packaged device. The package body may be formed in a mold using an encapsulation process, however, a portion of the leads of the package substrate are not covered during encapsulation, and these exposed lead portions form terminals for the semiconductor package. The semiconductor package may also be referred to as an "integrated circuit package", "microelectronic device package", or "semiconductor device package".

[0093] Although various examples of the present disclosure have been described above, it should be understood that the examples are presented only by way of example and not limitation. Without departing from the spirit or scope of the present disclosure, the disclosed examples may be subjected to numerous changes according to the disclosure herein. Within the scope of the claims, modifications may be made in the described embodiments, and other embodiments are possible. Therefore, the breadth and scope of the present invention should not be limited by any one of the examples described above. In fact, the scope of the present disclosure should be defined according to the attached claims and their equivalents.

Claims

1. A device comprising: a central processing unit, CPU, having a first bus coupling the CPU to a memory, wherein the CPU is configured to generate a hardware signal identifying a code isolation associated with a code portion executed by the CPU; a bus monitor hardware logic coupled to the first bus, wherein the bus monitor hardware logic comprises a first register, further wherein the bus monitor hardware logic is configured to: receiving a first write operation from an application running on the CPU, wherein the first write operation causes a first value associating the bus monitor hardware logic with the application to be written to the first register; writing a second value to the first register based on the hardware signal from the CPU, wherein the second value identifies a first code isolate of the application; receiving a memory access request on the first bus and receiving a code isolation flag from the CPU; as well as Whether to monitor the memory access request on the first bus is determined based at least in part on whether the code isolation identification corresponds to the second value.

2. The apparatus of claim 1, wherein the bus monitor hardware logic comprises an enhanced bus comparator.

3. The device of claim 1, wherein the bus monitor hardware logic is configured to write the second value to the first register without intervention of the application or operating system running on the CPU.

4. The apparatus of claim 1 , wherein the bus monitor hardware logic is further configured to: The first write operation is accepted based on whether the first register stores information indicating no ownership.

5. The apparatus of claim 1 , wherein the bus monitor hardware logic is further configured to: A second write operation is received from the application, wherein the second write operation is configured to replace the first value with an indication of no ownership.

6. The apparatus of claim 5, wherein the bus monitor hardware logic is further configured to: A third write operation is received from a debugger, wherein the third write operation causes a third value to overwrite the indication of no ownership in the first register, wherein the third value indicates ownership by the debugger.

7. The apparatus of claim 1 , wherein the bus monitor hardware logic is further configured to: As part of monitoring the memory access request on the first bus, reading or writing to a second register of the bus monitor hardware logic is enabled based on information in the hardware signal.

8. The apparatus of claim 1, wherein the first bus comprises at least one of a data bus, an address bus, or a program counter bus.

9. The apparatus of claim 1 , wherein the bus monitor hardware logic is further configured to: monitoring the memory access request on the first bus; and An interrupt is generated based on monitoring the memory access request.

10. The apparatus of claim 1, wherein the first code isolate comprises a region associated with a context in which the memory access request was generated. The apparatus of claim 10 , wherein the region is associated with a stack, and wherein the context is associated with the stack.

12. A device comprising: A plurality of bus monitor modules coupled to a plurality of buses, wherein a first bus monitor module of the plurality of bus monitor modules is configured to: storing application ownership information in a first register; storing code isolate ownership information in the first register, wherein the code isolate ownership information corresponds to a first code isolate associated with an application; receiving a memory access request from application code on a first bus of the plurality of buses; as well as Operation of the first bus monitor module is adjusted based at least in part on whether the application code is associated with the first code isolate, as indicated by the code isolate ownership information stored in the first register.

13. The apparatus of claim 12, wherein the first bus monitor module is further configured to: An identifier of the first code isolate is received concurrently with receiving the memory access request.

14. The apparatus of claim 13, wherein the first bus monitor module is further configured to: comparing the identifier of the first code isolate with the code isolate ownership information stored in the first register; and In response to determining that the identifier of the first code isolate matches the code isolate ownership information stored in the first register, enabling the first bus monitor module to monitor the memory access request.

15. The apparatus of claim 12, wherein the bus monitor module is further configured to: receiving a second code-isolated identifier concurrently with receiving the memory access request; comparing the identifier of the second code isolate with the code isolate ownership information stored in the first register; and In response to determining that the identifier of the second code isolate does not match the code isolate ownership information stored in the first register, monitoring functionality of the first bus monitor module is disabled.

16. A method comprising: receiving a first write operation from an application running on a central processing unit (CPU), wherein the first write operation is configured to store application ownership information in a first register of a bus monitor hardware logic; storing code isolation ownership information in the first register; receiving an access request from application code executing on the CPU; receiving information associating the access request with a first code isolation; as well as Monitoring of the access request is allowed or denied based on whether the code isolation ownership information indicates the first code isolation.

17. The method according to claim 16, comprising: Monitoring of the access request is denied based on the code isolation ownership information indicating otherwise than the first code isolation.

18. The method according to claim 16, comprising: Monitoring of the access request is permitted based on the code isolation ownership information indicating the first code isolation.

19. The method of claim 16, wherein the first code isolate comprises a region associated with a context in which the access request was generated.

20. The method of claim 19, wherein the region is associated with a stack, and wherein the context is associated with the stack.

Images