Identifying source of function calls and inheriting access rights

Abstract

The invention relates to identifying a source of a function call and inheriting access rights. The systems and methods provide inherited access rights, facilitating read and write access of the invoked context. The hardware logic may enforce access rights in the system. When code associated with a first (C1) context is executed at the CPU, the CPU generates a first hardware signal identifying the first context. Because the first context calls the second context, the CPU may then switch from the first context to the second context (C3). The CPU may then generate a second hardware signal identifying the invoked (first) context, and then the first hardware signal identifies the invoked (second) context. The hardware logic that enforces access rights may then determine that a second context is being invoked, and the second context includes direct access rights or inherited access rights associated with invoking the (first) context.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 532,092, filed on August 11, 2023, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present application generally relates to read operations and write operations to memory, and more particularly to enforcing access permissions to memory based on contextual identities. Background Art

[0004] Embedded code can be divided into different contexts, where each context may have different access rights to memory areas. For example, the code can be divided into a first context for the main application, a second context for the communication protocol stack, and a third context for library functions that can be called by multiple contexts throughout the application.

[0005] The access rights may allow a first context to access a first memory area but not a second memory area, and may allow a second context to access a second memory area but not the first memory area. In one example, if a third context is allowed to access both the first memory area and the second memory area, then a situation may be established where the access rights may be bypassed. For example, a first context may be able to call a third context to read or write to a second memory area.

[0006] This area requires more robust enforcement of access rights. Summary of the invention

[0007] In one embodiment, an apparatus includes: a processor core; hardware logic coupled to the processor core; a memory coupled to the hardware logic and having a plurality of memory regions; and a first register configured to identify direct access permissions to a first memory region of the memory, and a second register configured to identify inherited access permissions to the first memory region; wherein the hardware logic is configured to: receive a memory access request from the processor core, wherein the memory access request corresponds to the first memory region; receive an identifier of a first context associated with the memory access request from the processor core; determine whether the identifier of the first context matches information in a second register; receive a hardware signal from the processor core, the hardware signal including an identifier of a second context; in response to determining that the identifier of the first context corresponds to the information in the second register, determine whether the identifier of the second context corresponds to the information in the first register; and based on determining whether the identifier of the second context corresponds to the information in the first register, allow the memory access request to proceed.

[0008] In another embodiment, a method is performed by hardware logic, and the method includes: receiving a memory access request from a processing unit, wherein the memory access request is directed to a first memory region; receiving a first hardware signal that identifies a first context associated with the memory access request; determining whether the first context has inherited access rights to the first memory region; receiving an identifier of a calling context from a second hardware signal from the processing unit; determining whether the calling context has direct access rights to the first memory region based at least in part on the first context having inherited access rights; and determining whether to allow or deny the memory access request based at least in part on whether the calling context has direct access rights to the first memory region.

[0009] In another embodiment, a device includes: a first register configured to indicate direct access rights with respect to multiple contexts and multiple memory regions; a second register configured to indicate inherited access rights with respect to the multiple memory regions; hardware logic configured to enforce access to the multiple memory regions, wherein the hardware logic is further configured to: receive an access request to a first memory region among the multiple memory regions and an identifier of a first context associated with the access request; determine whether the first context has inherited access rights to the first memory region, including checking the identifier of the first context against information in the second register; in response to determining that the first context has inherited access rights to the first memory region, determine whether an identifier of a second context received from a processor core via a hardware signal has direct access rights to the first memory region; and determine whether to allow or deny the access request based at least in part on whether the identifier of the second context has direct access rights to the first memory region. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0011] Figure 1 is an illustration of example links, stacks, and partitions according to various embodiments.

[0012] Figure 2 is an illustration of an example system in accordance with various embodiments.

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

[0014] Figure 4 is an illustration of example access permissions in accordance with various embodiments.

[0015] Figure 5is an illustration of an example method for enforcing access permissions in accordance with various embodiments.

[0016] Figure 6 is an illustration of an example method for using CLINK registers and RLINK registers according to various embodiments. DETAILED DESCRIPTION

[0017] The present disclosure is described with reference to the accompanying drawings. The drawings are not drawn to scale, and they are provided only for illustrating the present disclosure. Several aspects of the present disclosure are described below with reference to example applications for illustration. It should be understood that many specific details, relationships and methods are listed in order to provide an understanding of the present disclosure. The present disclosure is not limited by the shown order of actions or events, because certain actions can occur in different orders and / or occur simultaneously with other actions or events. In addition, not all actions or events shown are necessary for implementing the method according to the present disclosure.

[0018] Various embodiments provide systems and methods for identifying the source of a function call and inheriting access rights. In some embodiments, such systems and methods can provide more robust access rights enforcement.

[0019] In one example, a first context (C1) may include application code, a second context (C2) may include something other than the main application code, such as a communication stack code, and a third context (C3) may include common code to be accessed by one or both of C1 or C2. Furthermore, in this example, C1 has access rights to a first memory region (M1) but not to a second memory region (M2), and context C2 has access rights to M2 but not to M1.

[0020] Continuing with the example, the hardware logic may be configured to enforce access to memory regions M1 and M2 based on context identities, including inherited access rights. A first context C1 may use a common piece of code in context C3 to perform memory access to M1, such as a read operation or a write operation. However, context C3 may not have direct access rights to read or write to M1. The processor core may execute instructions corresponding to C1 and then switch contexts to execute code corresponding to C3 as part of a function call from C1 to C3. In doing so, the processor core may provide a first hardware signal indicating that C3 is executing and may provide a second hardware signal indicating that C1 is the calling context. For example, the processor core may save the identity of C1 to a register, where the register corresponds to the second hardware signal.

[0021] Continuing with the example further, the hardware logic may include access protection logic that compares the identity of C3 from the first hardware signal to the direct access rights. The access protection logic may then determine that C3 does not have direct access rights and instead look at inherited access rights, which indicate that C3 does have inherited access rights. In response, the access protection logic may look at the second hardware signal to determine that C1 is the calling function. Since C1 has direct access to M1, the access protection logic allows context C3 to inherit the direct access rights of context C1. The access protection logic then allows the memory access to continue.

[0022] Various embodiments may have advantages over other solutions. For example, the inherited access rights described above allow a context to inherit permissions when called. However, when not called, the context may not retain permissions. Therefore, various embodiments may provide flexibility and security by allowing called functions to temporarily inherit access rights.

[0023] Additionally, various embodiments may allow for easy use of common code in a secure system with per-context access permissions. Specifically, while it may be attractive to implement a unique copy of a function in each context, this may result in overly complex compile time scenarios and may waste on-chip memory as machine code instructions and data will be repeated across different contexts. Instead, various embodiments may allow commonly used functions to be placed in a common code context, where the common code context may be called from time to time and may comply with security measures due to inherited access.

[0024] Figure 1 is an illustration of example links, stacks, and zones according to various embodiments. 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.

[0025] 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 points to one or more address ranges of machine code instructions and data, and the instructions stored within the addresses of a given link may share a single set of permissions. During execution, links may be referred to as contexts, and a single program may have code and / or data stored in any number of links / contexts.

[0026] Stack is a concept in some programming languages ​​(such as C programming), and it 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 the execution of maintenance programs. 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 location of program execution and manage the control flow between different parts of the program. In some examples, each program can have its own associated unique stack, although any number of programs can share a given stack.

[0027] Partitions in this example are developed for the concept of isolation. For example, a processor can have access enforcement where some users can access some partitions but not others, and user permissions can vary among different users. Figure 1 As shown, links 1-5 are all associated with stack 1. Stack 1 is associated with partition 1. Link 6 is associated with stack 2, which is associated with partition 2. Link 7 is associated with stack 3, which is associated with partition 3. The scope of embodiments can include partition 3 being configured to be used only by the manufacturer of the device. In addition, the scope of embodiments can include partition 2 having some other lower security, such as being configured to be used by the manufacturer and some trusted downstream business partners. In addition, the scope of embodiments can include partition 1 having even lower security, such as being open to various authorized third-party application programmers. In such embodiments, authorized third-party application programmers will not be able to access partition 2 or partition 1. In many examples, a given partition is associated with more than one program.

[0028] In other words, links can act as memory protection units for memory and peripherals. Stacks can accomplish hardware context separation. Partitions can manage development time isolation, such as for debugging, firmware updates, security updates, etc. The number of links, stacks, and partitions can vary from device to device, thereby Figure 1 The numbers of links, stacks, and partitions are for illustration purposes only.

[0029] The relationship between links, stacks, and partitions can be defined using information in registers. For example, a security control unit (e.g., Figure 2 As shown) may include multiple registers having information defining links, stacks, and partitions.

[0030] Figure 2is an illustration of an example system 200 according to various embodiments. System 200 may be implemented on one or more semiconductor dies. For example, processor core 210, security control unit 220, and memory 240 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, and the like. However, the scope of the embodiments is not limited to any particular use case, such as an embedded system or other use case.

[0031] Processor core 210 may be a general purpose processor core, a reduced instruction set computer (RISC), an application specific integrated circuit (ASIC), or any other suitable processing unit. Processor core 210 retrieves instructions and data from memory 240 and then executes these 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.

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

[0033] Memory 240 may be on-chip memory, off-chip memory, or any other suitable memory. In this example, memory 240 includes multiple memory regions that processor core 210 can read or write to via multiple read or write operations 221. Furthermore, while memory 240 is shown as a single memory, that is for ease of illustration, and it is understood that memory 240 may include address ranges across multiple memory devices. Security control unit 220 may include an array of registers for storing information indicating memory region access rights. This is about Figure 3 Describe in more detail.

[0034] In one example, the processor core 210 obtains instructions and data from the memory 240 (e.g., on-chip flash memory) by providing an access request to the security control unit 220. The instructions and data are stored in a specific address range in the memory 240, where the specific address range corresponds to a link, such as described above with respect to Figure 1The security control unit 220 monitors the instruction bus, parses the information in the acquisition, and determines that the acquisition corresponds to a specific link, stack, and partition. The security control unit 220 then uses the hardware signal 211 to pass the link identification, stack identification, and partition identification information back to the processor core 210.

[0035] Continuing with the example, processor core 210 begins processing instructions and data according to its processing pipeline. The processing pipeline may generate one or more read or write access requests on hardware signal 212. Processor core 210 may include link identification, stack identification, and partition identification information in hardware signal 212. Security control unit 220 may then use the link identification, stack identification, and partition identification in signal 212 for the purpose of access permission enforcement. For example, if a link (which may be referred to as a context during runtime) has access to a particular memory area, security control unit 220 may allow the access request; otherwise, security control unit 220 may deny the access request. Read write operation 221 shows a read or write operation being performed.

[0036] In another example, an instruction in a context may call another context. For example, a first instruction in a first context C1 may call a second instruction in a second context C3. The processor core 210 is configured to store the identity of the calling context (C1) in a CLINK register 215. The processor core 210 is also configured to output a hardware signal 213 that carries information from the CLINK register 215, thereby allowing the security control unit 220 to determine the calling context identity based on the hardware signal 213. The processor core 210 also includes an RLINK register 216, in which identification information for a return link may be stored. The return link identification information may be output by the processor core 210 on a hardware signal 214. Reference Figure 6 Describes RLINK information in more detail.

[0037] The hardware signals 211-214 in this example include one or more bits transmitted from one piece of hardware logic to another piece on one or more buses. Depending on the particular architecture, the bits may be transmitted in parallel or serially. Thus, in some cases, the hardware logic may be executed without the use of firmware or software functions. Figure 2-Figure 4 Describes the communications and actions.

[0038] Figure 3is an illustration of an example implementation of a security control unit 220 according to various embodiments. The security control unit 220 includes a configuration register and a get partition decoder 302. The configuration register and get partition decoder 302 include an array of registers that store information indicating associations between partitions and stacks and between stacks, links, and address ranges. When the processor core 210 provides a request to get instructions, the get request can be monitored by the security control unit 220, and the address information in the get request can be used to determine the link identification, stack identification, and partition identification information using the configuration register and get partition decoder 302. The security control unit 220 can then transmit the link identification, stack identification, and partition identification information on the hardware signal 211.

[0039] Register 304 is a direct access permission register for a particular memory region. The example register 304 includes a bit for each link, including 16 links in the figure: 0-15. The number of registers 304 can be as many as the number of memory regions. Register 304 can be configured to indicate direct access permission by, for example, storing a number 1 in a bit corresponding to a particular link (for permission) and storing a number 0 in a bit corresponding to another link (for no permission). Of course, the scope of the embodiments is not limited to any particular way of configuring registers to indicate direct access permission.

[0040] In one example, the processor core 210 can transmit a memory access request to the security control unit 220 on the signal 212. The memory access request on the signal 212 can include a target memory address and link identification, stack identification, and partition identification information of the context that caused the memory access request. The security control unit 220 can then determine the corresponding access permission register 304 based on the target memory address, compare the link identification information with the bits in the register 304, and then allow or deny the memory access based on the direct access permission in the register 304.

[0041] Register 306 is an inherited access permission register for a particular memory region. The number of registers 306 can be as many as the number of memory regions. The inherited access permission register 306 may include information identifying one or more links that can inherit permissions from other links. For example, if an instruction in a first context C1 calls another instruction in context C3, and C3 issues a read or write access request, the security control unit 220 can then compare the link identification information of context C3 with the direct access permission register 304 associated with the target memory address. If there is no match between the link ID and the positive indication of permissions in register 304, the security control unit 220 can then check the register 306 associated with the target memory address. Register 306 can indicate that the link identification associated with context C3 can inherit (or not inherit) permissions.

[0042] Assuming that context C3 can inherit permissions, the security control unit 220 can compare the link identification information with the hardware signal 213 indicating the call link identification. The call link identification indicates which link the current context (C3) inherits direct permissions from. Continuing with this example, the CLINK register 215 and the hardware signal 213 can identify the link associated with context C1, and assuming that the link associated with context C1 has the direct access permission indicated in register 304, the security control unit 220 can allow instructions in C3 to have read or write access to the memory area, even if these instructions in C3 do not have direct access to the memory area.

[0043] The information in registers 304 and 306 may be set during any suitable time. For example, the information in registers 304 and 306 may be set during the manufacture of system 200. In another example, the information in registers 304 and 306 may be set for some links and some memory areas during the manufacture of system 200, while the system may still allow some access permissions to be set during the development process.

[0044] Access protection logic 310 is hardware logic of security control unit 220. Access protection logic 310 may receive hardware signals 212-214 and then determine whether access to a particular memory region is allowed or not allowed.

[0045] Figure 4 is a diagram of an example access right 400 according to various embodiments. The actions discussed with respect to access right 400 may be performed by Figure 3 The access protection logic 310 executes.

[0046] exist Figure 4 In the example, RAM 420 corresponds to Figure 2RAM 420 includes multiple memory regions, shown as memory region 1 (M1) and memory region 2 (M2). Of course, a given RAM may include any suitable number of memory regions, and Figure 4 Only two are shown for ease of illustration.

[0047] Flash memory 410 may include non-chip flash memory or some other suitable memory in which machine code instructions and data are stored. Context 1 (C1) corresponds to the main application code. As described above, C1 also corresponds to links, stacks, and partitions, where links and stacks are associated with address ranges within flash memory 410.

[0048] Furthermore, in this example, context 2 (C2) corresponds to a communication stack code. C2 also corresponds to a link, a stack, and a partition, wherein at least the link identification is different from the link identification associated with C1.

[0049] Context 3 (C3) includes a library of common code. The common code may include functions that are expected to be accessed from time to time by C1 and C2. One example includes a memory copy (memcpy), although the scope of the implementation may include any suitable function in the library of common code. In addition, although Figure 4 Only three contexts are shown, but it will be appreciated that various implementations may include any suitable number of contexts, each with its own permissions.

[0050] Memory region M1 is configured to allow read or write access from C1 (as indicated by register 304) and to allow access protection inheritance from C3 (as indicated by register 306). However, according to the information in register 304 or register 306, C2 is not granted access. Similarly, memory region M2 is configured to allow read and write access from C2 (as indicated by register 304) and to allow access protection inheritance from C3 (as indicated by register 306). However, C1 is not granted access to M2.

[0051] In one example, the first instruction in context C1 makes a function call to context C3 to perform a memory copy function on M1. Processor core 210 executes the machine code instructions of C1 during runtime and then transfers to C3 according to the function call. Processor core 210 then writes the identification of the link corresponding to calling context C1 into CLINK register 215.

[0052] Since processor core 210 is now executing instructions of context C3, when it sends a read or write request to security control unit 220, it transmits the link identification associated with context C3 on hardware signal 212. In addition, hardware signal 213 identifies the link ID associated with context C1.

[0053] In response to receiving a read or write request directed to the target memory address, the access protection logic 310 may then compare the link ID of context C3 with the direct access permission of register 304 associated with the target memory address. Register 304 does not indicate direct access permission to context C3. The access protection logic 310 may then compare the link ID of context C3 with the inherited access permission information in register 306 associated with the target memory address. In this example, there is a match between the link ID of context C3 and the inherited access permission information register 306. Based on the match, the access protection logic 310 may then compare the CLINK identification information (identifier C1) on the hardware signal 213 with the direct access permission of register 304. Register 304 indicates direct access permission to the link associated with C1. The access protection logic 310 may then allow read or write access to M1, as shown in FIG. Figure 2 The read or write operation 221 is shown.

[0054] Of course, in some cases, access protection logic 310 can deny access. For example, if neither C3 nor C1 has direct access to M1, access protection logic 310 will deny the read or write request. In addition, context C2 can use a similar process to call C3 to execute a function on memory region M2. However, even with inherited permissions, C1 cannot perform read or write operations on M2, and C2 cannot perform read or write operations on M1, as enforced by access protection logic 310.

[0055] Figure 5 is an illustration of an example method 500 for enforcing access rights according to various embodiments. The actions of method 500 may be performed by hardware logic (such as access protection logic 310) in, for example, security control unit 220. 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 a bus to receive hardware signals and transmit hardware signals. In this example, such actions may not require intervention of software or firmware functions.

[0056] At act 502, access protection logic receives a memory access request from an instruction in a first context. Figure 4 In the example of , the first context may be C3 because it issues an access request to read or write to a target address in the memory region M1.

[0057] At act 504, the access protection logic determines whether the first context has direct access to the first memory region. For example, the access protection logic may check a link ID associated with the first region (as received on a hardware signal) against information stored in one or more registers (e.g., register 304) associated with the target address.

[0058] If there is no direct access right in act 504, then at act 506, the access protection logic determines whether the first context has inherited access rights to the first memory region. Figure 4 In the example of , context C3 does not have direct access rights to M1 , but it does include inherited access rights, as given by the information in register 306 associated with the target address.

[0059] If, according to register 306, context C3 includes inherited access rights, then at act 508, the access protection logic may check the identifier of the calling context. Figure 2 In the example of , an identifier of the calling context may be transmitted on hardware signal 213, and it may carry information saved to CLINK register 215. The access protection logic may compare the link identifier associated with the calling context (e.g., C1) with the direct access rights to the first memory region. Figure 4 In the example of , calling context C1 has direct access to M1 , as provided by register 304 .

[0060] At action 510, the access protection logic may allow or deny the memory access request based on the results of actions 504-508. For example, the access protection logic may determine that the calling context has direct access rights to a particular memory region, such as C1 has direct access rights to memory region M1. In this case, the access protection logic may then allow a read or write operation to memory region M1.

[0061] The scope of the embodiments is not limited to Figure 5 . In contrast, some embodiments may add, omit, rearrange, or modify one or more of the actions. In one example, if actions 504 and 506 indicate no direct access or inherited access, then permission may be denied without even reaching other actions 508, 510. In another example, if the identifier of the calling context at action 508 is not associated with direct access rights, then access may be denied without reaching action 510.

[0062] In another example, the principles discussed herein may also be adapted for use with peripheral device access and memory regions. For example, the security control unit 220 may include registers indicating direct access rights and inherited access rights to one or more linked individual peripheral utilities. The actions discussed above may be performed to allow or deny access to peripheral utilities based on direct access rights and indirect access rights in the same manner as access to memory regions may be allowed or denied.

[0063] Various embodiments may allow for the use of CLINK register 215 and / or RLINK register 216 (e.g., Figure 2 shown). Figure 6 is an illustration of an example method 600 for using CLINK registers and RLINK registers according to various embodiments. The actions of method 600 may be performed by a processor core, such as Figure 2 Processor core 210.

[0064] Method 600 begins with a processor core processing machine code instructions and data of a first context C1. At action 602, the first context C1 calls a second context (C2). For example, C1 may make a function call to C2, and the processor core may begin processing data and machine code instructions of C2.

[0065] At act 604, the processor core may update the CLINK register to identify C1 as the calling context. At act 606, the second context C2 may call the third context C3. Acts 602 to 606 represent nested call operations.

[0066] At action 608, the processor core updates the CLINK register to identify C2 as the calling context. The processor core may also begin processing the data and machine code instructions of C3. At action 610, C3 completes its function and returns operation to C2. The processor core may then begin processing the data and machine code instructions of C2, and then update the RLINK register at action 612 to identify C3 as the return link. At action 614, the processor core may update the CLINK register to identify C1 as the calling context of the instruction in C2 currently being executed. Action 614 is performed so that processing eventually returns to C1, which is the first calling function.

[0067] At action 616, context C2 completes its function and processing returns from C2 to C1. The processor core may begin processing machine instructions and data for context C1. The processor core may also update the RLINK register to identify C2 as a return link.

[0068] The functionality provided by method 600 can be used during code execution to provide security advantages. For example, C1 may include code that checks the RLINK register after action 618. C1 can check the RLINK register to ensure that the return is indeed from C2. If the RLINK register identifies any other context, this may indicate a security issue. Context C1 may include code for continuing processing based on a match or taking some other action in the event of a mismatch. Examples of other actions may include issuing an error, restarting, etc. Similarly, a called function (such as C2) can check the CLINK register against the context (e.g., C1) to which it returns. A mismatch may indicate a security issue and action may be taken.

[0069] The term "semiconductor die" is used herein. A semiconductor device / 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. Semiconductor devices may also be referred to herein as semiconductor devices or integrated circuit (IC) dies.

[0070] 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 dies may be packaged together. For example, a power metal oxide semiconductor (MOS) field effect transistor (FET) semiconductor device and a second semiconductor device (such as a gate driver die or a controller die) may be packaged together to form a single packaged electronic device. Additional components such as passive objects such as capacitors, resistors, and inductors or coils may be included in the packaged electronic device. The semiconductor die is mounted through 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 with the device side surface facing away from the substrate and the back side surface facing the package substrate and mounted to the die pads of the package substrate. Semiconductor packages can have a package formed by a thermosetting epoxy molding compound in a molding process, or a package formed by using an epoxy, plastic or resin that is liquid at room temperature and subsequently solidified. The package can provide a hermetic package for the packaged device. The package can be formed in a mold using an encapsulation process, but during encapsulation, a portion of the leads of the package substrate is not covered, and these exposed lead portions form the terminals of the semiconductor package. Semiconductor packages can also be referred to as "integrated circuit packages", "microelectronic device packages" or "semiconductor device packages".

[0071] Although various examples of the present disclosure are described above, it should be understood that they are given as examples only, not limitations. Without departing from the spirit or scope of the present disclosure, various changes may be made to the disclosed examples according to the present disclosure. Within the scope of the claims, modifications in the described embodiments are possible, and other embodiments are also possible. Therefore, the breadth and scope of the present invention should not be limited by the above examples. On the contrary, the scope of the present disclosure should be defined according to the attached claims and their equivalents.

Claims

1. A device comprising: Processor core; hardware logic coupled to the processor core; a memory coupled to the hardware logic and having a plurality of memory regions; as well as a first register configured to identify direct access permissions for a first memory region of the memory, and a second register configured to identify inherited access permissions for the first memory region; The hardware logic is configured as follows: receiving a memory access request from the processor core, wherein the memory access request corresponds to the first memory region; receiving, from the processor core, an identifier of a first context associated with the memory access request; determining whether the identifier of the first context corresponds to information in the second register; receiving a hardware signal from the processor core, the hardware signal comprising an identifier of a second context; responsive to determining that the identifier of the first context corresponds to the information in the second register, determining whether the identifier of the second context corresponds to the information in the first register; and Based on determining whether the identifier of the second context corresponds to the information in the first register, determining whether to allow the memory access request to proceed.

2. The apparatus according to claim 1, wherein the processor core is configured to: executing instructions associated with the second context; In response to a function call from the second context to the first context, executing instructions associated with the first context; and The identifier of the second context is stored in a third register of the processor core, wherein the third register is associated with the hardware signal.

3. The apparatus according to claim 1, wherein the processor core is configured to: A value stored in a third register is updated upon a function call from the second context to the first context, wherein the third register is associated with the hardware signal. The apparatus of claim 1 , wherein the first context is associated with a shared library. The apparatus of claim 1 , wherein the second context is associated with code of an application. 6 . The apparatus of claim 1 , wherein the first register comprises a first plurality of bits, further wherein the first plurality of bits are configured to indicate that the second context has direct access to the first memory region. 7 . The apparatus of claim 6 , wherein the first plurality of bits are configured to indicate that the second context does not have direct access to a second memory region of the memory.

8. The apparatus of claim 6, wherein the second register comprises a second plurality of bits, further wherein the second plurality of bits are configured to indicate that the first context has inherited access to the first memory region.

9. The apparatus according to claim 1, wherein the hardware logic is further configured to: determining whether the identifier of the first context corresponds to the information in the first register; and In response to determining that the identifier of the first context does not match the information in the first register, determining whether the identifier of the first context corresponds to the information in the second register is performed.

10. The apparatus of claim 1, wherein the first context is associated with a first range of memory addresses in an on-chip memory, and wherein the second context is associated with a second range of memory addresses in the on-chip memory.

11. The apparatus of claim 1, wherein the first register and the second register are implemented in the hardware logic.

12. A method performed by hardware logic, the method comprising: receiving a memory access request from a processing unit, wherein the memory access request is directed to a first memory region; receiving a first hardware signal identifying a first context associated with the memory access request; determining whether the first context has inherited access rights to the first memory region; receiving, from the processing unit, an identifier of a calling context from a second hardware signal; determining whether the calling context has direct access rights to the first memory region based at least in part on the first context having the inherited access rights; as well as A determination is made whether to allow or deny the memory access request based at least in part on whether the calling context has direct access rights to the first memory region.

13. The method of claim 12, further comprising denying the memory access request in response to the calling context not having direct access rights to the first memory region.

14. The method of claim 12, further comprising allowing the memory access request in response to the calling context having direct access rights to the first memory region.

15. The method according to claim 12, further comprising: receiving a get operation from the processing unit; as well as Information in the get operation is parsed to determine links, stacks, and partitions associated with the get operation.

16. The method according to claim 15, further comprising: A third hardware signal is transmitted to the processing unit, the third hardware signal including link, stack, and partition information associated with the fetch operation.

17. The method of claim 12, wherein the first context is associated with a library of shared code.

18. An apparatus comprising: a first register configured to indicate direct access permissions with respect to a plurality of contexts; a second register configured to indicate inherited access permissions; Hardware logic configured to enforce access to a plurality of memory regions, wherein the hardware logic is further configured to: receiving an access request to a first memory region of the plurality of memory regions and an identifier of a first context associated with the access request; determining whether the first context has inherited access rights to the first memory region, comprising checking the identifier of the first context against information in the second register; In response to determining that the first context has inherited access rights to the first memory region, determining, based on information in the first register, whether an identifier of a second context received from a processor core via a hardware signal has direct access rights to the first memory region; as well as A determination is made whether to allow or deny an access request based at least in part on whether the identifier of the second context has direct access rights to the first memory region.

19. The apparatus of claim 18, wherein the first context is associated with a first link, and wherein the second context is associated with a second link.

20. The apparatus of claim 19, wherein the first link corresponds to a first address range storing a first set of machine code instructions and data, and wherein the second link corresponds to a second address range storing a second set of machine code instructions and data, wherein the first address range and the second address range are different.

Images