System and method for limiting access to a resource
Patent Information
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- STMICROELECTRONICS INT NV
- Filing Date
- 2023-05-30
- Publication Date
- 2026-06-05
Abstract
Description
Title of the invention: System and method for limiting access to a resource Technical field
[0001] The present description relates generally to computer processing systems comprising a processor or microcontroller and, more particularly, to systems and methods for limiting access by particular software modules to resources of a computer processing system. Prior art
[0002] It is known to provide processing environments in which applications can be assigned different levels of access rights to resources, such as hardware resources, for example peripheral devices or particular memory regions, or other resources, for example a software service, an encryption service, a particular parameter or confidential data.
[0003] A certified software application having the required level of authority to access a given limited-access resource can access it directly using a direct call. However, if an uncertified application not having the required level of authority wishes to access a limited-access resource, it may be necessary to make a system call that interrupts the execution of the application, and requests that a system having a higher level of authority, such as the operating system, access the resource on behalf of the uncertified application.
[0004] In order to support both certified and non-certified application cases, it would be possible to develop two versions of the software application, one intended for use in an environment in which it is certified, and another intended for use in an environment in which it is not certified. However, this leads to a technical problem, as it means that a given application code is not reusable on all systems and in all contexts, leading to additional cost and complexity.
[0005] An additional difficulty is that, in some processing environments, two or more software components may be operating independently of each other and may need to access one or more limited-access resources. This may require duplication of application code in each software component, or that each application code has particular code to call a given service provider, which again means that the software code cannot be reused across all systems and in all contexts.
[0006] There is therefore a need in the state of the art for a technical solution which makes it possible to selectively limit access by a software application to one or more resources on the basis of the rights level of the software application and using the same reusable code. Summary of the invention
[0007] An object of the embodiments of the present description is to at least partially fulfill one or more needs of the state of the art.
[0008] According to one aspect, a computing device is provided comprising: at least one memory device configured to store a software application; a processing device connected to the at least one memory device via a bus and configured to execute the software application;and one or more resources that can be called by execution of code in the software application, wherein the at least one memory device, or other memory device of the computing device, is configured to store a redirection table indicating, based on one or both of a calling address and a called address of a call to one of the resources, an alternative address to which the call is to be forwarded, wherein the computing device further comprises software or hardware for intercepting a call from the software application and selectively redirecting the call based on the redirection table. ;
[0009] According to another aspect, there is provided a method of accessing one or more resources of a computing device, the method comprising: intercepting, by software or hardware of the computing device, a call from a software application stored by at least one memory device of the computing device, wherein a processing device of the computing device is connected to the at least one memory device via a bus and is configured to execute the software application; and selectively redirecting, by said software or hardware of the computing device, the call based on a redirection table stored in the at least one memory device, or in an additional memory device, the redirection table indicating, based on one or both of a calling address and a called address of a call to one of the resources, an alternative address to which the call is to be forwarded.
[0010] According to one embodiment, the one or more resources comprise one or more hardware resources such as peripheral devices of the computing device.
[0011] According to one embodiment, the one or more resources comprise one or more memory regions of the at least one memory device.
[0012] According to one embodiment, the software or hardware intended to intercept the call is configured to compare the calling address of the call to a plurality of reference calling addresses indicated in the redirection table, and, in the event of a match, to redirect the call to the replacement address associated in the redirection table with the reference calling address of the call.
[0013] According to one embodiment, the software or hardware intended to intercept the call is configured to compare the called address of the call to a plurality of reference called addresses indicated in the redirection table, and, in the case of a match, to redirect the call to the replacement address associated in the redirection table with the reference called address of the call.
[0014] According to one embodiment, the software or hardware for intercepting the call is configured to compare the calling address of the call to a plurality of reference calling addresses indicated in the redirection table and to compare the called address of the call to a plurality of reference called addresses indicated in the redirection table, and, in the case of a match for both the calling and called addresses, to redirect the call to the replacement address associated in the redirection table with the reference calling and called addresses of the call.
[0015] According to one embodiment, the one or more resources that can be called by the execution of code in the software application comprise: a first resource that can be called by a call to a first function stored at a first address in the at least one memory device; and a second resource that can be called by a call to a second function stored at a second address in the at least one memory device.
[0016] According to one embodiment, the software or hardware intended to intercept the call is a software module stored in the at least one memory device.
[0017] According to one embodiment, the software or hardware intended to intercept the call is a circuit connected to the bus and comprising one or both of: a first comparator configured to compare an address on the bus to a reference calling address or a reference calling address range; and a second comparator configured to compare an address on the bus to a reference called address or a reference called address range. Brief description of the drawings
[0018] These characteristics and advantages, as well as others, will be explained in detail in the following description of particular embodiments given without limitation in relation to the attached figures among which:
[0019] [Fig.l] schematically represents a computer device according to an exemplary embodiment of the present description;
[0020] [Fig.2] schematically represents a resource call system based on direct calls from a software application;
[0021] [Fig.3] schematically represents a resource call system based on both direct calls and system calls from software applications;
[0022] [Fig.4] schematically represents a resource access system comprising a redirection module according to an exemplary embodiment of the present description; and
[0023] [Fig.5] schematically represents a resource access system comprising a redirection circuit according to an exemplary embodiment of the present description. Description of the embodiments
[0024] The same elements have been designated by the same references in the different figures. In particular, the structural and / or functional elements common to the different embodiments may have the same references and may have identical structural, dimensional and material properties.
[0025] For the sake of clarity, only the steps and elements useful for understanding the described embodiments have been shown and are detailed.
[0026] Unless otherwise specified, when referring to two elements connected to each other, this means directly connected without intermediate elements other than conductors, and when referring to two elements connected (in English "coupled") to each other, this means that these two elements can be connected or be connected by means of one or more other elements.
[0027] In the following description, when reference is made to absolute position qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative position qualifiers, such as the terms "above", "below", "upper", "lower", etc., or to orientation qualifiers, such as the terms "horizontal", "vertical", etc., reference is made unless otherwise specified to the orientation of the figures or to a ... in a normal position of use.
[0028] Unless otherwise specified, the expressions "about", "approximately", "substantially", and "of the order of" mean to within 10%, preferably to within 5%.
[0029] In this description, the following terms will be considered to have the following definitions: - system call: an electronic signal generated by the execution of a software application that causes the execution of the software application to stop and a service to be requested from a resource by a privileged component, such as an operating component, on behalf of the software application; - resource: any hardware or software resource that can be called by a software application by a direct call or a system call to a given address, and to to which access may be limited, examples being a peripheral device, such as a hardware accelerator device, an encryption circuit, a memory interface, etc., a volatile or non-volatile memory device, or a region or address range of a memory device, a software service, an encryption service, a particular parameter or confidential data; - call redirection: the translation of a call to a given address into a call to another address without the caller being involved in this process.
[0030] [Fig.l] schematically represents a computing device 100 according to an exemplary embodiment of the present description. The computing device 100 is for example implemented by a system on chip (SoC). The computing device 100 is for example part of an electronic device such as an loT (Internet of Things) device, a digital sensor, a digital controller of, for example, an electronic or electromechanical system, or the like, or any "smart device" that can benefit from security, such as a meter, for example of electricity, water, gas, etc., a body camera, a medical device, such as an insulin pump, a heart rate monitor, etc., or the like.
[0031] The computing device 100 comprises for example a processing device (P) 102 comprising one or more processors and one or more memory devices, such as a volatile memory (RAM) 104 and / or a non-volatile memory (FLASH) 106. In some embodiments, the volatile memory 104 is a RAM and / or the non-volatile memory 106 is a Flash memory, although other types of volatile and non-volatile memories could be present.
[0032] The processing device 102 and the memories 104, 106 are for example connected by a bus 108, consisting for example of an address bus and a data bus (not shown individually).
[0033] The non-volatile memory 106 stores, for example, software code, including, for example, an operating system (OS), which may be a secure operating system and / or a real-time operating system (RTOS), and one or more software applications. Two examples of software applications APP1, APP2 are shown in [Fig.l]. As is known to those skilled in the art, the operating system OS and the software applications may be at least partially loaded into the volatile memory 104 and executed by the processing device 102. It would also be possible for the computing device 100 to be a bare metal system without any operating system OS or without a rich operating system, the OS being, for example, an RTOS.
[0034] The computing device 100 further comprises, for example, one or more limited access hardware devices (RA HW 1, RA HW N) 110, 112 connected to the bus 108, which are for example peripheral devices, such as communication interfaces, or any other type of resources that can be accessed only directly by the OS and / or by one or more of the software applications having the required rights. In addition, the volatile memory 104 comprises for example a limited access zone (RA ZONE) 114, and / or the non-volatile memory 106 comprises for example a limited access zone (RA ZONE) 116, which are for example hardware resources in the form of memory regions or address ranges that can be accessed only directly by the OS and / or by one or more of the software applications having the required rights. Although not shown in [Fig.l], the computing device may further implement one or more software resources providing, for example, limited access services.
[0035] [Fig. 2] schematically represents a resource call system 200 based on direct calls from a software application. The system 200 comprises a software application (APP BINARY) 202, corresponding for example to the application APP1 of [Fig. 1], and hardware resources (HW) 206, 208. In alternative embodiments, one or more software resources are present in addition or according to a variant. The software application 202 is for example made up of a software code (SW), sometimes referred to as being a binary code, and includes a LIB_A library code (HAL) 204, which is for example a hardware abstraction layer (HAL) code which allows the software application to make direct calls to the hardware resources 206, 208. Indeed, the system 200 of [Fig. 2] is for example a bare metal system in which the software application 202 has all the rights required to access the hardware or software resources.In the example of [Fig.2], the hardware resource 206 is a UART (Universal Asynchronous Receiver-Transmitter) interface and the hardware resource 208 is a timer unit (TIM).
[0036] [Fig. 3] schematically represents a resource calling system 300 based on both direct calls and system calls from software applications. The system 300 comprises two software applications corresponding for example to the software applications APP1 and APP2 of [Fig. 1], a first of the software applications (APP. MODULE 1) 302 comprising a library code LIB_A (HAL) 304, and a second of the software applications (APP. MODULE 2) 306 comprising a library code LIB_A (HAL) 308. The system 300 further comprises an operating system (SECURE OS) 310, which is for example a secure OS. Alternatively, rather than an OS, which has scheduling capabilities, any secure development environment acting as a gatekeeper (in other words, a system having no scheduling capabilities) could be used. The system 300 also includes for example the hardware resources (HW) 206, 208 which are for example identical to those of [Fig.2]. The system 300 could further comprise one or more software resources in addition to or instead of one or both of the hardware resources 206, 208.
[0037] The software application 306 has for example rights similar to those of the software application 202 of [Fig.2], and can thus call both the hardware resources 206, 208 directly via the library code 308.
[0038] On the other hand, the software application 302 has for example a lower level of rights, and can for example call the hardware resource 208 directly, but must make a system call to the OS 310 in order to access the hardware resource 206.
[0039] Thus, although it is possible to reuse the library code 204 of the software application 202 as the library code 308 of the software application 306, without adding a mechanism to handle the resource calls, the library code 304 of the software application 302 might have to be different from the others in order to handle both types of calls to the hardware resources 206 and 208.
[0040] Figure 4 schematically represents a resource access system 400 comprising a redirection module 410 according to an exemplary embodiment of the present description. This system 400 is for example implemented in the computer system 100 of FIG. 1. The system 400 comprises two software applications corresponding for example to the software applications APP1 and APP2 of FIG. 1, a first of the software applications (BINARY: @SECTION 1) 402 comprising a library code LIB_A CHECK_REDIRECT() 404, and a second of the software applications (BINARY: @SECTION2) 406 comprising a library code LIB_A CHECK_REDIRECT() 408, which is for example identical to the library code 404. Therefore the codes 404 and 408 can be reused between the software applications 402, 406, even if these software applications have different rights levels.This is achieved by a redirection module (CHECK_REDIRECT()) 410, which is configured to intercept calls from the software applications 402 and 406, and to redirect them based on whether the call is to be made as a direct call or a system call. For this, each of the software applications 402, 406 is for example configured to call the same particular function FuncHR for a given resource HR. In some embodiments, the FuncHR functions are part of the software applications 402, 406, for example are part of the LIB_A library codes 404, 408 respectively, and have the role of calling the redirection module 410. In particular, the software applications 402, 406 call a service from the LIB_A library code using the FuncHR function and the FuncHR function invokes the CHECK_REDIRECT() redirection module 410. For example, the FuncHR function = . HAL_GPIO_Init. The FuncHR functions for the various resources are for example all stored in the non-volatile memory 106, and each contains for example code that starts by calling the redirection module 410 which for example implements a CHECK_REDIRECT() function. In this way, the redirection module 410 can intercept and process calls to the FuncHR functions. The redirection module 410 is configured to determine which actual call should be made: a direct call or a system call.
[0041] The CHECK_REDIRECT() function, for example, is not platform-dependent and is always the same code. For example, the only parts that may change from one system to another are the address of this function and the size of the redirection table.
[0042] The redirection module 410, and in particular the CHECK_REDIRECT() function, is for example configured to redirect the call if a redirection must be applied. For example, [Fig.4] represents an example in which the called resource is a UART, and the call is redirected by the redirection module 410 to either: a first memory address 412 corresponding to a UART direct call (UART_DIRECT CALL); or to a second memory address 414 corresponding to a UART system call (UART_SYS CALL). For example, the redirection performed by the redirection module 410 is based on rules stored in a redirection table 411, which is for example part of the redirection module 410. In some embodiments, the redirection table can be updated as represented by a TABLE UPDATE entry in the redirection module 410.
[0043] When leaving the redirection function CHECK_REDIRECT(), the stack is for example ignored and the link register is for example forced to the redirection address. In addition, a branch is for example applied to the redirection address, with the stack from the caller, based on the input parameters and the calling address in the link register. Alternatively, if no redirection is to be applied, then the code flow continues for example with the standard flow.
[0044] Tables 1 and 2 below provide examples of the redirection table.
[0045] As shown in Table 1, each of the table records #1 to #6 defines, for example, the rules applying to a call of a given resource at a given called address (Called @) from a given calling address (Caller @) in the software module 402 or 406, i.e., at any address in a section 1 (@SECTION1) or at any address in a section 2 (@SECTION2), or at a particular address in one of these sections. In the example of Table 1, there are two resources that can be called by functions FuncA and FuncB respectively. The called addresses of these functions as executed by the software applications 402 and 406 are, for example, example of addresses in the 410 redirection module, so that the 410 redirection module intercepts and processes these calls. In addition, for each table record #1 to #6, there is an indication of the redirection address (Redirected @), in other words the address to which the call would be redirected by the 410 redirection module.
[0046] [Tables 1] Record table Caller @ Called @ Redirected @ #1 Exact address of code II making the call to FuncA &FuncA in FLASH &SyscallFuncA #2 Exact address of code 12 making the call to FuncB &FuncB in FLASH &SyscallFuncB #3 Exact address of code 13 making the call to FuncB &FuncB in FLASH &SyscallFuncB #4 Caller @ in section S1 Called @ in range [@1; @2] called© + offset #5 Caller @ in section S2 &FuncA in FLASH &OtherS y scallF a A #6 Caller @ in RAM &FuncB in FLASH &DoNothing
[0047] For example, record #1 in Table 1 corresponds to a calling address at an exact address of a code II that calls the function FuncA, record #2 in the table corresponds to a calling address at an exact address of a code 12 that calls the function FuncB, and record #3 in the table corresponds to a calling address at an exact address of a code 13 that calls the function FuncB. Codes II, 12, and 13 may be in any of the software applications 402 or 406. Functions FuncA and FuncB are, for example, stored in non-volatile memory 106, which is, for example, FLASH memory. The redirect addresses for records #1, #2, and #3 are, for example, system calls to the corresponding function, because codes II, 12, and 13 do not, for example, have the required level of authority to directly call the resources associated with functions FuncA and FuncB.
[0048] For example, record #4 in Table 1 corresponds to a calling address in the software application 402, in other words in an address range of section S1, record #5 in the table corresponds to a calling address in the software application 406, in other words in an address range of section S2, and record #6 in the table corresponds to a calling address in the volatile memory 104, which is for example the random access memory RAM. The called address for table record #4 is for example an address range [@ 1 ; @ 2], in other words all addresses between addresses @ 1 and @ 2, and the redirect address is the called address plus an offset. This allows for example a direct call to a resource, but to a modified address.The called address for table record #5 is for example the function FuncA, and the redirect address is a system call to the function FuncA, but different from the system call of table record #1, for example because a different device is called in order to access the resource, such as a device that is external to the device 100 of [Fig. 1]. As an example, the system call is used to access a cryptographic service, such as a decryption operation involving the use of a confidential key. In a first case, the encryption key is for example protected directly in the device 100 itself, and therefore a first system call (for example, the system call of table record #1) is performed with all operations executed in the device 100, which is for example an SoC.In a second case, the encryption key may be even more sensitive and additional access to an external secure component may be implemented, thus leading to a different system call (e.g., the system call of table record #5). The address called for table record #6 is, for example, the function FuncB and this call is, for example, blocked, and not redirected, as indicated by the do nothing entry "&DoNothing".
[0049] Table 2 indicates in an "Applicability" column, for each table record #1 to #6 in Table 1, additional conditions that must, for example, apply before the redirection is applied. Providing additional conditions is optional, and in some cases there may be no additional conditions for all or some of the table records, as indicated by the "no condition" entry. Furthermore, in some cases, an additional "Rejection" column indicates, for each table record #1 to #6 in Table 1, what should be done if the condition is not met. If there is no condition, then an NA (not applicable) entry is present in this column.
[0050] [Tables2] Table Record Applicability Reject #1 1. Kernel in unprivileged mode 2. Value of register XX is YY 3. If applicability checks are negative, raise a hardware fault #2 Unconditional NA #3 1. Value at RAM@ XX is YY Do not perform redirection, call &FuncB #4 Kernel in privileged mode Reset #5 Secure mode Exception El #6 Unconditional NA
[0051] Of course, the preceding Tables 1 and 2 provide only an example of a set of rules for defining call redirections, and many modifications are possible, for example depending on the number of resources that can be called, the number of software applications that can issue calls, etc. Although examples have been provided in which each table record is defined for a particular calling address and for a particular called address, it would also be possible for some or all of the table records to be defined solely on the basis of the calling address or solely on the basis of the called address, if for example all calls from a given software code or to a given resource are to be treated in the same way.
[0052] Although [Fig.4] shows an embodiment in which the interception and redirection of calls are performed in software by a software module, a hardware implementation is also possible, an example of which will be described in more detail below in connection with [Fig.5].
[0053] [Fig. 5] schematically represents a resource access system 500 comprising a redirection circuit 502 according to an exemplary embodiment of the present description. This system 500 is for example implemented in the computer system 100 of [Fig. 1].
[0054] For example, the redirection circuit 502 is connected between the bus 108 and the volatile memory device 104 (RAM (CODE, VDATA)), which stores software code and / or volatile data, and / or between the bus 108 and the non-volatile memory device 106 (FLASH (CODE, NVDATA)), which stores software code and non-volatile data. Although [Fig. 5] shows an example in which a single circuit 502 is connected between the bus and each of the memory devices 104, 106, in alternative embodiments, it would be possible to provide a separate circuit for each memory device 104, 106.
[0055] As shown in [Fig.5], the processing device (P) 102 is also connected to the bus 108, and in some embodiments one or more other master devices (OTHER MASTER(S)) 504 may be connected to the bus 108 and may be configured to make calls to resources on the bus 108 which may be handled in a manner similar to the calls made by the processing device 102.
[0056] The redirection circuit 502 comprises, for example, a buffer memory (@IN) 506 connected to the bus 108 and configured to temporarily store addresses appearing on the address bus of the bus 108 which correspond to the addresses in the non-volatile memory 106. The redirection circuit 502 further comprises a comparator (CALLEE COMPARATOR) 508, configured to compare an address in the buffer memory 506 to one or more called reference addresses, or to called reference address ranges, stored for example in a register (REF ADDRS) 510. These called reference addresses or called reference address ranges correspond, for example, to the address or address ranges defined in the "called address" column of the redirection table described previously.
[0057] Furthermore, the redirection circuit 502 comprises for example a buffer memory (@IN) 512 connected to the bus 108 and configured to temporarily store addresses appearing on the address bus of the bus 108 which correspond to the addresses in the volatile memory 104. The comparator 508 is for example further configured to compare an address in the buffer memory 512 to the one or more reference called addresses or to the reference called address ranges stored in the register 510.
[0058] The redirection circuit 502 further comprises, for example, a buffer 514 configured to store a previous address present in the buffer 506 and / or the buffer 512. The redirection circuit 502 further comprises a comparator (CALLER COMPARATOR) 516 configured to compare an address in the buffer 514 to one or more reference calling addresses or reference calling address ranges stored for example in a register (REF ADDRS) 518. These reference calling addresses or reference calling address ranges correspond to the address or address ranges defined in the "calling address" column of the redirection table described previously.
[0059] The implementation of circuit 502 of [Fig.5] assumes that, for a given call, the calling address appears on the address bus one clock period before the called address.
[0060] Outputs of comparators 508 and 516 are for example connected to a memory 520 storing for example a truth table (LUT) 522 implementing the redirection table described previously. In the event that one or both of the comparators 508 and 516 detect a match, the corresponding calling and / or called address is, for example, provided as an entry in the truth table 522, which is configured to determine whether there is a match with one of the records in the redirection table and, if so, to make the redirection address available to an address fetcher (FETCHER) 524. The address fetcher is configured to store the redirection address in either a buffer 526 (REDIRECTED @ IN) if the call is intended for the non-volatile memory 106, or in a buffer 528 (REDIRECTED @ IN) if the call is intended for the volatile memory 104.
[0061] An output of buffer 506 is further connected to an input of buffer 526, and an output of buffer 512 is further connected to an input of buffer 528, such that addresses pass through circuit 502 transparently if no redirect address is set. If a redirect address is set, address fetcher 524 is configured to write back, into buffer 526 or 528, addresses transferred from buffer 506 or 512 by the redirect address.
[0062] Although not shown in [Fig.5], it will be apparent to those skilled in the art that circuit 502 is a synchronous implementation, with each of the components being, for example, synchronized by a common clock signal.
[0063] Although not shown in [Fig.5], the truth table 522 may have as additional entries additional information so that the conditions indicated in the "applicability" column of the redirection table described previously can be analyzed and applied.
[0064] Furthermore, in some embodiments, the contents of the truth table may be updated, as represented by a configuration entry (CONFIG) 530 and an update path (UPDATE) 532. In the event that the calling or called addresses or address ranges are updated, the new information is, for example, stored in registers 510, 518. In some embodiments, the update mechanism is a secure mechanism that can be accessed only based on authentication verification using, for example, one or more encryption keys.
[0065] Additionally or alternatively, the redirection table of both the hardware implementation ([Fig.5]) and the software implementation ([Fig.4]) may for example be stored in a ROM (Read-Only Memory) or as a non-volatile table, for example in Flash memory, which is configured during programming of the computing device 100. In some embodiments, the redirection table is write-protected, or can be updated under particular conditions, such as authentication and / or read protection (RDP) regression, by authorized and / or trusted software, based on an option byte, a system bit, or a status pin, etc. As a further alternative, the redirection table may be a dynamic RAM table that is configured each time the computing device 100 is reset or shut down.Updating the table may be performed via one or more input pins of the computing device 100, or via a wireless interface such as an OTA (Over The Air) interface.
[0066] An advantage of the embodiments described herein is that it is possible to access resources based on the same reusable code, independently of the context in which the software application is used, and in particular independently of the level of rights assigned to the software application. Indeed, the restricted access is obtained by using the redirection table described, which will either allow the call to act as a direct call to the resource, or redirect the call as a system call, or block the call.
[0067] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will occur to those skilled in the art. For example, it will be apparent to those skilled in the art that the principles described herein could be applied to any number of resources, which may correspond to peripheral devices or memory regions.
[0068] Finally, the practical implementation of the embodiments and variants described is within the reach of those skilled in the art from the functional indications given above.
Claims
Claims
1. A computing device comprising: - at least one memory device (104, 106) configured to store a software application (APP1, APP2); - a processing device (102) connected to the at least one memory device via a bus (108) and configured to execute the software application (APP1, APP2);and - one or more resources (110, 112, 114, 116) that can be called by executing code in the software application (APP1, APP2), wherein the at least one memory device (104, 106), or an additional memory device (520) of the computing device, is configured to store a redirection table (411, 522) indicating, based on one or both of a calling address and a called address of a call to one of the resources, an alternative address to which the call is to be forwarded, wherein the computing device further comprises software or hardware for intercepting a call from the software application (APP1, APP2) and redirecting the call based on the redirection table (411, 522).;
2. A method of accessing one or more resources (110, 112, 114, 116) of a computing device, the method comprising: - intercepting, by software or hardware of the computing device, a call from a software application (APP1, APP2) stored by at least one memory device (104, 106) of the computing device, wherein a processing device (102) of the computing device is connected to the at least one memory device (104, 106) via a bus (108) and is configured to execute the software application (APP1, APP2);and - selectively redirecting, by said software or hardware of the computing device, the call based on a redirection table (411, 522) stored in the at least one memory device (104, 106) or in an additional memory device (520), the redirection table (411, 522) indicating, based on one or both of a calling address and a called address of a call to one of the resources, an alternative address to which the call is to be forwarded.;
3. The computing device of claim 1, wherein the one or more resources (110, 112, 114, 116) comprise one or more hardware resources such as peripheral devices of the computer device.
4. The computing device of claim 1 or 3, wherein the one or more resources (110, 112) comprise one or more memory regions (114, 116) of the at least one memory device (104, 106).
5. A computing device according to any one of claims 1, 3 or 4, wherein the software or hardware for intercepting the call is configured to compare the calling address of the call to a plurality of reference calling addresses indicated in the redirection table, and, in the event of a match, to redirect the call to the replacement address associated in the redirection table with the reference calling address of the call.
6. A computing device according to any one of claims 1, 3 or 4, wherein the software or hardware for intercepting the call is configured to compare the called address of the call to a plurality of reference called addresses indicated in the redirection table, and, in the event of a match, to redirect the call to the replacement address associated in the redirection table with the reference called address of the call.
7. A computing device according to any one of claims 1, 3 or 4, wherein the software or hardware for intercepting the call is configured to compare the calling address of the call to a plurality of reference calling addresses indicated in the redirection table and to compare the called address of the call to a plurality of reference called addresses indicated in the redirection table, and, in the case of a match for both the calling and called addresses, to redirect the call to the alternate address associated in the redirection table with the reference calling and called addresses of the call.
8. A computing device according to any one of claims 1 or 3 to 7, wherein the one or more resources (110, 112, 114, 116) that can be called by executing code in the software application comprise: - a first resource that can be called by a call to a first function (FuncA) stored at a first address in the at least one memory device (104, 106); and - a second resource that can be called by a call to a second function (FuncB) stored at a second address in the at least one memory device (104, 106); at least one memory device (104, 106).
9. The computing device of claim 8, wherein the software or hardware for intercepting the call is a software module (410) stored in the at least one memory device (104, 106).
10. A computing device according to any one of claims 1 or 3 to 8, wherein the software or hardware for intercepting the call is a circuit (502) connected to the bus (108) and comprising one or both of: - a first comparator (516) configured to compare an address on the bus (108) to a reference calling address or a reference calling address range; and - a second comparator (508) configured to compare an address on the bus (108) to a reference called address or a reference called address range.