Patent Application
20130276096
The present invention relates to data processing apparatuses comprising a master device and a slave device. More particularly the present invention relates to such data processing apparatuses in which the slave device is configured to perform secure data processing operations and non-secure data processing operations on behalf of the master device.
It is known to provide a data processing apparatus having a master device in overall control of the data processing apparatus and a slave device configured to perform data processing operations delegated to it by the master device. For example, in a data processing apparatus which is required to perform video decoding operations, a master device (e.g. a general purpose CPU) may delegate much of the video decoding operations to a dedicated video processing unit (i.e. the slave device).
Data security is further known to be an important consideration when configuring a contemporary data processing apparatus. For example, it is known to categorise some data as “secure” and other data as “non-secure”, whereby the secure data is only allowed to be accessed by components within a data processing apparatus which are trusted (i.e. secure). Accordingly a general purpose processor (such as the above mentioned CPU) may be configured to have a secure domain and a non-secure domain, wherein only components which reside in the secure domain of the processor are allowed to access secure data in memory. For example, the TrustZone® technology developed by ARM Limited of Cambridge, UK provide mechanisms for enforcing such security boundaries in a data processing apparatus (as described for example in U.S. Pat. No. 7,849,310, the entire contents of which are incorporated herein by reference).
The secure domain of such a data processor must be carefully constructed and administered to ensure that the security which it is intended to provide is maintained. One aspect of maintaining the trusted status of the secure domain is that any program code (e.g. a driver) which is to be executed within the secure domain must itself be trusted and carefully checked to ensure that its execution will not jeopardise the integrity of the secure domain. Accordingly, it is common for dedicated driver code to be written to provide a secure driver within the secure domain and to provide separate program code for a non-secure driver executing in the non-secure domain. Following this approach driver code can be written which is appropriately configured for the security domain in which it operates and with respect to the processing tasks which it delegates to a slave device, but this has the disadvantage that two or more versions of the driver program code must be written.
Viewed from a first aspect, the present invention provides a data processing apparatus configured to perform secure data processing operations and non-secure data processing operations, wherein secure data in said data processing apparatus cannot be accessed by said non-secure data processing operations, the data processing apparatus comprising:
a master device comprising a secure domain and a non-secure domain, wherein components of said master device are configured to operate in said secure domain when performing said secure data processing operations and to operate in said non-secure domain when performing said non-secure data processing operations;
a slave device configured to perform a delegated data processing operation specified by said master device; and
a communication bus connecting said master device to said slave device,
wherein said delegated data processing operation is initiated by an issuing component in said master device issuing a delegated task definition to said slave device on said communication bus,
wherein said slave device comprises a security inheritance mechanism configured to cause said delegated data processing operation to inherit a non-secure security status if said issuing component in said master device is operating in said non-secure domain and to cause said delegated data processing operation to inherit a secure security status if said issuing component in said master device is operating in said secure domain.
The master device and the slave device in the data processing apparatus are coupled together by means of a communication bus which the master device can use to issue a delegated task definition to the slave device, the task definition setting out various parameters of a data processing operation which the master device is instructing the slave device to perform on its behalf. Whilst the issuing component in the master device which issues the delegated task definition to the slave device on the communication bus is free to define various parameters which configure the delegated data processing operation, the slave device is configured to have a security inheritance mechanism which causes the delegated data processing operation to inherit a non-secure security status if the issuing component is operating in the non-secure domain of the master device. Equally, the security inheritance mechanism of the slave device is configured such that by default the delegated data processing operation will inherit a secure security status if the issuing component is operating in the secure domain of the master device. In other words, the effect of the security inheritance mechanism is that the issuing component in the master device is generally able to specify all aspects of the delegated task definition which configures the delegated data processing operation to be carried out other than its security status. This security status is inherited from the security domain in which the issuing component is operating in the master device.
In this manner, a highly secure, hardware-enforced mechanism is provided for ensuring that only a trusted issuing component operating in the secure domain of the master device is able to cause a secure data processing operation to be performed by the slave device. Furthermore, because the security status of the delegated data processing operation is an integral part of the hardware configuration of the data processing apparatus, this aspect of the issuing component in the master device is no longer part of the configuration of that issuing component. For example, when the issuing component is a driver being executed in either the secure domain or the non-secure domain of the master device, the same driver program code can be used for a range of different security configurations such as the driver being executed solely in the secure domain, the driver being executed solely in the non-secure domain, or a driver in the non-secure domain communicating with a secure driver in the secure domain. This is due to the fact that the security inheritance mechanism in the slave device ensures that the critical security boundary in the system (that non-secure operations are not allowed to access secure data) is enforced, without this having to form part of the issuing component's own configuration.
An indication of which security domain the issuing component in the master device is operating in could be passed to the slave device in a number of ways, but in one embodiment said communication bus is configured such that said delegated task definition is accompanied by a domain identifier, said domain identifier indicating if said issuing component in said master device is operating in said non-secure domain or if said issuing component in said master device is operating in said secure domain.
In some embodiments, said slave device is configured to perform said delegated data processing operation as one of said non-secure data processing operations if said domain identifier indicates that said issuing component in said master device is operating in said non-secure domain. Accordingly, the security inheritance mechanism in the slave device can be configured so that the slave device uses the domain identifier as its reference for deciding how to set the security status of the delegated data processing operation, in particular setting it as “non-secure” when the domain identifier received on the communication bus shows that the issuing component is operating in the non-secure domain of the master device.
In some embodiments said delegated task definition comprises a security status request, said security status request indicating whether said delegated data processing operation is requested by said issuing component to be performed as a secure data processing operation or as a non-secure data processing operation. Thus, the security inheritance mechanism of the slave device notwithstanding, the issuing component in the master device may be able to include a security status request in the delegated task definition indicating the security status with which the issuing component would like the slave device to perform the delegated data processing operation.
In some embodiments said slave device is configured to perform said delegated data processing operation as said non-secure data processing operation if said issuing component in said master device is operating in said non-secure domain, regardless of said security status request. In other words, even if an issuing component in the non-secure domain of the master device seeks to initiate a secure data processing operation in the slave device by including a secure security status request in the delegated task definition is sends on the communication bus, the security inheritance mechanism in the slave device will override this request and only allow a non-secure data processing operation to be set up.
In some embodiments said slave device is configured to override said security inheritance mechanism and to perform said delegated data processing operation in accordance with said security status request if said issuing component in said master device is operating in said secure domain. The security inheritance mechanism in the slave device is essentially provided as a way of ensuring that a non-secure issuing component in the master device can only set up non-secure data processing operations in the slave device. However, in a data processing apparatus in which trust is categorised as secure or non-secure, a secure issuing component in the master device is inherently trusted within such a system and it may be advantageous to allow a secure issuing component in the master device to freely specify whether the delegated data processing operation is handled as secure or non-secure, in particular because this allows the secure issuing component to establish non-secure delegated data processing operations within the slave device.
In some embodiments said issuing component in said master device is configured to issue a delegated task update command to said slave device on said communication bus, wherein said slave device is configured to reconfigure said delegated data processing operation in accordance with said delegated task update command. In this way, even after a delegated data processing operation has been established in the slave device, reconfiguration of that delegated data processing operation may be carried out by means of the delegated task update command issued by the issuing component in the master device.
In one such embodiment, if said issuing component in said master device is operating in said secure domain said delegated task update command is configurable to cause said delegated data processing operation to convert to being performed as one of said non-secure data processing operations by causing said secure security status to be converted to said non-secure security status. Hence, in this manner a secure issuing component can cause a secure delegated data processing operation to be converted to a non-secure delegated data processing operation.
In some embodiments said slave device is configured to store said delegated task definition in an entry of a task definition table, wherein said entry of said task definition table comprises a task security definition, wherein said task security definition defines whether said delegated data processing operation is performed as one of said non-secure data processing operations or as one of said secure data processing operations, wherein said task security definition comprises either said secure security status or non-secure security status, wherein if said issuing component in said master device is operating in said non-secure domain said task security definition cannot be set with said secure security status. Accordingly, a task definition table may be provided in the slave device to administer and store the delegated task definitions received from the master device. A task security definition indicating either the secure security status or the non-secure security status forms part of each entry in this task definition table. This allows the slave device to maintain correct administration of each delegated task definition in the table, in particular ensuring that a non-secure issuing component in the master device cannot cause an entry in the task definition table to be set with secure security status.
In one such embodiment, a component operating in said non-secure domain in said master device cannot modify said entry of said task definition table if said task security definition is set with said secure security status. Accordingly, a component operating in the non-secure domain of the master device is simply blocked from modifying entries which are set with secure security status. Further, the blocking of such an attempted modification also extends to any attempt by a component operating in said non-secure domain in said master device to create a delegated data processing operation in a task definition table entry which is marked as secure. It should be understood that the above described security inheritance mechanism does not cause the secure status of an existing task to be “downgraded” to non-secure merely because a non-secure component attempted to modify this task definition table entry. Such attempted accesses are simply blocked. The security inheritance mechanism only applies to the creation of a new task definition table entry.
Alternatively, in another such embodiment, a component operating in said non-secure domain in said master device can modify a selected portion of said entry of said task definition table if said task security definition is set with said secure security status, wherein said selected portion is configured to indicate a status of a communication channel between said master device and said slave device. Accordingly, even though a component in the non-secure domain of the master device is generally blocked from modifying an entry of the task definition table which is labelled as secure, it may be allowed to modify a limited selected portion of the entry which relates to the status of communication channel between the master device and the slave device. For example, this communication channel may be an interrupt mechanism wherein although a non-secure component cannot generally modify an entry in the task definition table, it may use a selected portion thereof to flag an interrupt request, for example indicating that a message stored in a shared area of memory should be accessed by the secure delegated processing operation to allow communication between the master and the slave device.
In some embodiments said delegated task definition further comprises a page table base address, wherein said slave device comprises a memory management unit configured to administer accesses to a memory from said slave device, said memory management unit configured to perform translations between virtual memory addresses used by said slave device and physical memory addresses used by said memory, wherein said translations are configured in dependence on said page table base address, said page table base address identifying a storage location in said memory of a set of descriptors defining said translations. Accordingly the memory management unit in the slave device can receive, as part of the delegated task definition, a page table base address in dependence on which the virtual to physical memory address translations are made and therefore the page table base address defines the regions of the memory to which the delegated data processing operation has access. In this way further control over the operation of the delegated data processing operation can be given to the issuing component in the master device.
In one such embodiment, when the slave device is configured to store the delegated task definition in an entry of a task definition table, said entry of said task definition table comprises said page table base address, and wherein a component operating in said non-secure domain in said master device cannot modify said page table base address if said task security definition is set with said secure security status. Accordingly, this provides an additional level of security control to the secure domain in the master device since only a component operating in the secure domain can modify page table base addresses within task definitions that are labelled as secure. Within the context of secure delegated data processing operations this has the further advantage that even though the delegated data processing operation is configured as secure, its access to the memory can be further defined (and in particular constrained) by the page table base address. This therefore means that a secure delegated data processing operation being carried out on the slave device does not necessarily need to be given access to all secure memory and therefore some secure areas of memory can be retained as only accessible to the secure domain of the master device. Equally, two secure delegated data processing operations need not have access to each other's data.
In some embodiments said issuing component in said master device is a driver configured to operate in either said secure domain or said non-secure domain. As previously mentioned above as an example, this has the advantage that the system designer need only provide one driver which can be executed in either the secure domain or the non-secure domain without consideration of the consequences in terms of security that this would have, due to the fact that the slave device has the security inheritance mechanism.
Alternatively the system designer may explicitly choose to write dedicated drivers for each domain and in such embodiments, said issuing component in said master device is a driver configured to operate in a selected domain of said secure domain and said non-secure domain.
The slave device may take a wide variety of forms, but in one embodiment said slave device is a video processing unit.
In one such embodiment said video processing unit is configured to perform video coding operations on multiple video streams. Accordingly in this context the ability of the master device to control the security of delegated data processing operations being carried out in the video processing unit means that the video coding operations may be performed according to either the secure or the non-secure status for different video streams. This for example enables some video streams (e.g. encrypted video streams) to be handled by the video processing unit in a secure manner, such that the integrity of these selected video streams is not jeopardised by the video processing unit also performing non-secure video coding operations on other video streams.
Viewed from a second aspect the present invention provides a data processing apparatus configured to perform secure data processing operations and non-secure data processing operations, wherein secure data in said data processing apparatus cannot be accessed by said non-secure data processing operations, the data processing apparatus comprising:
master device means comprising a secure domain and a non-secure domain, components of said master device means for operating in said secure domain when performing said secure data processing operations and for operating in said non-secure domain when performing said non-secure data processing operations;
slave device means for performing a delegated data processing operation specified by said master device means; and
communication bus means for connecting said master device to said slave device,
wherein said delegated data processing operation is initiated by an issuing component in said master device means issuing a delegated task definition to said slave device means on said communication bus means,
said slave device means comprising security inheritance means for causing said delegated data processing operation to inherit a non-secure security status if said issuing component in said master device means is operating in said non-secure domain and to cause said delegated data processing operation to inherit a secure security status if said issuing component in said master device means is operating in said secure domain.
Viewed from a third aspect the present invention provides a method of data processing in a data processing apparatus configured to perform secure data processing operations and non-secure data processing operations, wherein secure data in said data processing apparatus cannot be accessed by said non-secure data processing operations, the method comprising the steps of:
operating components of a master device in a secure domain when performing said secure data processing operations and operating components of said master device in said non-secure domain when performing said non-secure data processing operations;
performing in a slave device a delegated data processing operation specified by said master device;
connecting said master device to said slave device via a communication bus;
initiating said delegated data processing operation by an issuing component in said master device issuing a delegated task definition to said slave device on said communication bus; and
causing said delegated data processing operation in said slave device to inherit a non-secure security status if said issuing component in said master device is operating in said non-secure domain and causing said delegated data processing operation to inherit a secure security status if said issuing component in said master device is operating in said secure domain.
The above, and other objects, features and advantages of this invention will be apparent from the following detailed description of illustrative embodiments which is to be read in connection with the accompanying drawings.
The present invention will be described further, by way of example only, with reference to embodiments thereof as illustrated in the accompanying drawings, in which:
In more detail, the VPU 104 has four processor cores 108 provided for the dedicated execution of video processing tasks. The distribution of video processing tasks to the video cores 108 is administered by the core scheduling unit 110. This core scheduling unit 110 in turn receives delegated task definitions from the CPU 102 over the APB 112. This APB 112 is an AXI Peripheral Bus (as provided by ARM Limited, Cambridge, UK). The APB 112 connects to the VPU 104 via the interfaces 114 and 118.
The CPU 102 is subdivided into a secure domain 120 and a non-secure domain 122. This subdivision of the CPU 102 into secure and non-secure domains may for example be provided in accordance with the TrustZone technology provided by ARM Limited of Cambridge, United Kingdom as described for example in U.S. Pat. No. 7,849,310, the entire contents of which are incorporated herein by reference. In essence, components within the secure domain 120 are trusted within the data processing apparatus 100, and therefore are allowed access to security-sensitive data within the data processing apparatus 100, whilst components in the non-secure domain 122 are not allowed access to such security-sensitive data. For example, within the memory 106 there may be stored decryption keys 124 which enable encoded data to be decrypted and are therefore examples of such security-sensitive data. The CPU 102 has access to the memory 106 via AXI bus 126 (as also provided by ARM Limited of Cambridge UK). Interfaces to the AXI bus 126 are not illustrated for clarity. In the same manner that the CPU 102 is subdivided into a secure domain 120 and a non-secure domain 122, the memory 106 is sub-divided into regions which may be specified as secure or non-secure. Most importantly, a component operating in the non-secure domain 122 of the CPU 102 cannot access a region of memory 106 which has been specified as secure. The reader is referred to the above mentioned description of the TrustZone® technology in U.S. Pat. No. 7,849,310 for further detail of how such access policing may be configured.
Furthermore, the video processing tasks delegated to the VPU 104 by the CPU 102 are also classified as either secure tasks or non-secure tasks, in dependence on the nature of the task and in particular the nature of the video stream which that task is required to perform video processing operations on. Thus, the VPU 104 is required to perform video processing tasks (in particular in this example embodiment video decoding tasks) on different video streams, some of which may be classified as secure. In this example embodiment a video stream is designated as secure if it is received as an encrypted bitstream and free access to the decrypted bitstream should not be allowed. For this reason, a video core 108 which is performing video processing tasks either performs its video processing tasks making use of a region of 130 of memory 106 which is dedicated to the “secure VPU” or to a region 132 of the memory 106 which is dedicated to the “non-secure VPU”. Most importantly therefore a video core 108 which is performing a non-secure video processing task should be prevented from accessing any region of memory which is defined as being secure. However, within the context of secure video processing tasks being carried out within the VPU 104, it would be undesirable to simply give a core 108 executing such a secure video processing task unlimited access to all secure regions of memory 106 because this would for example give that core access to a region of memory 106 such as that labelled 134 in which the decryption keys 124 are stored and should only be accessed by components operating within the secure domain 120 of the CPU 102. This is the case because although a component within the secure domain 120 of the CPU 102 may delegate a secure video processing task to a core 108 of the VPU 104, allowing that core to have full secure domain status, i.e. extending the secure domain 120 of the CPU 102 to include the video core 108 carrying out that secure processing task (at least for the duration thereof), would mean that the VPU 104 would have to run an operating system which is able to enforce the secure/non-secure subdivision in the same manner as is carried out in the CPU 102. However, a dedicated processing device such a VPU 104 typically does not have the facilities to run such an operating system.
The data processing apparatus 100 addresses this problem by enabling the CPU 102 to delegate video processing tasks to the VPU 104 which, as well as configurational parameters for the task, specify a page table base address which is used by a memory management unit (MMU) 140 within each video core 108 to perform translations between the virtual memory addresses used within each core 108 and the physical memory addresses used by the memory 106. Each MMU 140 is provided with one or more page table base registers (PTBR) 142 in which the page table base address for the processing task(s) to be carried out is(are) held.
Within the CPU 102, each of the two security domains 120 and 122 has its own kernel, namely secure kernel 150 and non-secure kernel 152. These kernels represent the core of the operating system running in each domain. In addition, as illustrated in
The memory 106 in
The second mechanism by which control over access to particular regions of memory 106 is exercised is by means of the above mentioned page table base addresses. Since these page table base addresses provide the translation between the virtual memory addresses used within each video core 108 and the physical memory addresses used by the memory 106, appropriate setting of these page table base addresses (and of course the corresponding page tables and descriptors) can further constrain which areas of memory 106 are accessible to a given video core 108 in dependence on the video processing task it is carrying out. Hence, within the secure areas of memory 106, the area 134 can be reserved as an area which is only accessible to secure components operating within the CPU 102, whilst access can be granted to the secure VPU area 130 to secure video processing tasks being carried out by a video core 108. Example items which may be held in the secure VPU memory 130 whilst a secure video processing task is being carried out are the secure frame buffer 162, the decrypted bit stream 164 and the secure workspace 166. Additionally, it may commonly be the case that the firmware provided to configure the operation of the video cores 108 in VPU 104 is too large to be held within VPU 104 and accordingly this VPU core firmware 168 may also be held in the secure VPU memory area 130 (such that it is shielded from non-secure processors being executed by a video core 108). Equivalently, within the non-secure VPU memory area 132, a frame buffer 170, a bit stream 172 and a workspace 174 are examples of items which may be held in the this non-secure memory for use by a video core 108 when performing a non-secure video processing task. Additionally, a message buffer 176 is also held within the non-secure VPU memory area 132, this message buffer being used to provide a communication channel between the video cores 108 and the CPU 102. Being held in non-secure memory, either a secure or a non-secure processing task can access this message buffer to read or write a message as appropriate. Note that although a given video processing task may be carried out as a secure data processing operation, aspects of the administration of the task may nevertheless be handled by the non-secure driver 156 (removing this processing burden from the secure driver 154). For example in the illustrated embodiment, the non-secure driver 156 can manage the rate and progress of the video decode by sending messages to the secure session using message buffer 176. Example messages are “frame complete” or “input buffer empty”.
In the GPU 254, the system control unit 270 plays the role that the core scheduling unit 110 plays in the embodiment illustrated in
Alternatively, if the new video decoding job to be performed can be handled non-securely then from step 302 the flow proceeds to step 310 whereby it is the non-secure driver 156 in the CPU 102 which allocates an area of non-secure memory to this task and configures the page tables and descriptors pointed to by a suitable page table base address to correspond to this allocated area of memory. Then at step 312 the non-secure driver 156 writes the new non-secure entry into LSIDENTRY (i.e. memory space allocation table 200) at an available slot including the page table base address defined at step 310. The entry is labelled as non-secure (i.e. NS=1). Note that the interface between the CPU 102 and the VPU 104 is such that a non-secure driver 156 cannot set the security status of an entry in the memory space allocation table to be secure. This mechanism described in more detail in the following. The flow then proceeds to step 308.
At step 308 the non-secure driver 156 adds the new job to the job queue 202 (LSIDQUEUE). In other words, the administration of the order in which the delegated video decoding tasks are carried out is administered by the non-secure driver 156, since this burden can be taken away from the secure driver 154 because it is not a security-critical task. Finally, at step 314 the core scheduling unit 110 (in particular by means of the job administration unit 204) allocates this job to an available VPU core 108 once it becomes first in the job queue 202.
In addition to the page table base address and security bit, an LSIDENTRY has various other parameters as schematically illustrates in
Here the AxPROT[1] value accompanying the access request on the APB 112 is examined and it is determined if the issuing component resides in the secure domain 120 of the CPU 102. If it does (i.e. AxPROT[1] is 0) then full write access to the LSIDENTRY is granted to this secure issuing component (e.g. secure driver 154) at step 608. If however AxPROT[1] is 1 (i.e. the request comes from a component such as non-secure driver 156 in the non-secure domain 122), then at step 610 it is determined what the security status is of the LSIDENTRY to which access is sought. If this LSIDENTRY is non-secure then the flow proceeds to step 608 and the write access is allowed. If on the other hand this LSIDENTRY is denoted as corresponding to a secure task, then only limited write access is permissible. Specifically, at step 612 it is determined if the write access is seeking to modify the IRQ or IRQACK parameters of this LSIDENTRY (by means of which a video core can signal a request for and acknowledge communication with the master CPU). Write access to these particular parameters is allowed (step 614), but all other write accesses are refused (step 616).
Although a particular embodiment has been described herein, it will be appreciated that the invention is not limited thereto and that many modifications and additions thereto may be made within the scope of the invention. For example, various combinations of the features of the following dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1206760.9 | Apr 2012 | GB | national |
