CN100354829C - Exception types within a secure processing system - Google Patents

Abstract

There is a provided apparatus for processing data, said apparatus comprising: a processor operable in a plurality modes and either a secure domain or a non-secure domain including: at least one secure mode being a mode in said secure domain; and at least one non-secure mode being a mode in said non-secure domain; wherein when said processor is executing a program in a secure mode said program has access to secure data which is not accessible when said processor is operating in a non-secure mode; said processor is responsive to one or more exception conditions for triggering exception processing using an exception handler, said processor being operable to select said exception handler from among a plurality of possible exception handlers in dependence upon whether said processor is operating is said secure domain of said non-secure domain.

Description

Exception types within a secure processing system

Technical Field

The present invention relates to data processing systems. More particularly, the present invention relates to exception types provided within a data processing system having a secure domain and a non-secure domain.

Background

A data processing apparatus typically comprises a processor for running an application program loaded on the data processing apparatus. The processor will operate under the control of an operating system. The data required to run any particular application is typically stored in the memory of the data processing apparatus. It will be appreciated that the data may be comprised of instructions contained within the application program and/or actual data values used during execution of those instructions on the processor.

There are many instances where data used by at least one application is sensitive data that should not be accessed by other applications capable of running on the processor. Examples are that the data processing device is a smart card and that one application is a secure application that uses sensitive data, such as e.g. a security key, to perform validation, authentication, decryption, etc. In these cases, it is important to ensure that sensitive data is secure from being accessed by other applications that may be loaded onto the data processing apparatus, such as hacker applications that have been loaded onto the data processing apparatus for the purpose of attempting to access that secure data.

In known systems, the task of an operating system developer is to ensure that the operating system provides sufficient security to ensure that the secure data of one application cannot be accessed by other applications running under the control of the operating system. However, as systems become more complex, the general trend is for operating systems to become larger and more complex, and in these cases, it becomes increasingly difficult to ensure adequate security within the operating system itself.

Examples of systems that attempt to provide secure storage of sensitive data and protection against malicious program code are disclosed in U.S. patent application US2002/0007456a1 and U.S. patents US6,282,657B and US6,292,874B.

US-A-5,745,770 discloses A processor responsive to system management interrupts and debug interrupts associated with the same program instructions.

Accordingly, it would be desirable to provide improved techniques for attempting to maintain the security of those secure data contained within the memory of a data processing apparatus.

Disclosure of Invention

Viewed from one aspect the present invention provides apparatus for processing data, said apparatus comprising:

a processor operable in a plurality of modes and a plurality of domains, the plurality of domains including a secure domain or a non-secure domain, the plurality of modes comprising:

at least one security mode that is a mode in the security domain;

at least one non-secure mode that is a mode in the non-secure domain; and

a monitoring mode characterized by, in a monitoring mode,

when the processor is executing a program in a secure mode, the program accessing secure data that is not accessible when the processor is operating in a non-secure mode; and

the processor is responsive to one or more exception conditions for triggering exception handling using an exception handler, the processor being operable to select the exception handler from a plurality of possible exception handlers dependent on whether the processor is operating in the secure domain or the non-secure domain.

The present invention recognizes that exception handling has the potential to provide security vulnerabilities within a security system. The present invention addresses this problem by providing a system having a combination of one or more exceptions that can selectively control either a secure or non-secure exception handler and one or more exceptions that can control a dedicated one of a non-secure and secure exception handler. Providing selectable exceptions allows a desired degree of flexibility in exception handling to meet the needs of various operating systems waiting while dedicated exceptions are more difficult to destroy, providing constraints on parallelism and well-defined responses for particular exceptions. For example, a watchdog security timer may be associated with a dedicated exception that is guaranteed to be handled by a security exception handler so that conventional security checks, as triggered by the watchdog timer, may not be blocked.

The present invention advantageously incorporates providing a monitoring mode via which all switching between secure and non-secure domains must be made by a monitoring mode responsible for data security activities such as refreshing register values at the time of switching, and the like.

Preferred examples of dedicated exceptions are a safety interrupt signal exception, a mode switch software interrupt signal and a reset exception. Preferred examples of selectable exceptions are interrupt signal exceptions, software interrupt signals, undefined instruction exceptions, prefetch abort exceptions, data abort exceptions, and fast interrupt signal exceptions.

Viewed from another aspect the present invention provides a method of processing data, said method comprising the steps of:

executing, by a processor operable in a plurality of modes and a plurality of domains, the plurality of domains including a secure domain or a non-secure domain, a program, the plurality of modes comprising:

at least one security mode that is a mode in the security domain;

at least one non-secure mode that is a mode in the non-secure domain;

it is characterized in that the preparation method is characterized in that,

when the processor is executing a program in a secure mode, the program may use secure data that is not accessible when the processor is operating in a non-secure mode;

triggering exception handling using an exception handler in response to one or more exception conditions, wherein,

at least one of the exceptions is a selectable exception handled by a selected one of a non-secure exception handler operating in a non-secure mode or a secure exception handler operating in a secure mode; and

at least one of the exceptions is a dedicated security exception that is processable by a dedicated one of a non-secure exception handler operating in a non-secure mode and a secure exception handler operating in a secure mode.

Drawings

The invention will be further described, by way of example only, with reference to preferred embodiments as illustrated in the accompanying drawings, in which:

FIG. 1 is a block diagram schematically illustrating a data processing apparatus according to a preferred embodiment of the present invention;

FIG. 2 schematically illustrates different programs operating in a non-secure domain and a secure domain;

FIG. 3 schematically illustrates a processing mode matrix relating to different security domains;

FIGS. 4 and 5 schematically illustrate different relationships between processing modes and security domains;

FIG. 6 illustrates a programmer's model of a processor's register set, according to processing mode;

FIG. 7 illustrates an example of providing separate register sets for secure and non-secure domains;

FIG. 8 schematically illustrates a plurality of processing modes with switching between security domains via separate monitoring modes;

FIG. 9 schematically illustrates the use of a mode switch software interrupt instruction for the case of a security domain switch;

FIG. 10 schematically illustrates one example of how a non-secure interrupt request and a secure interrupt request may be performed by the system;

FIGS. 11A and 11B schematically illustrate an example of non-secure interrupt request processing and an example of secure interrupt request processing, according to FIG. 10;

FIG. 12 illustrates another scheme for handling a non-secure interrupt request signal and a secure interrupt request signal as compared to that shown in FIG. 10;

FIGS. 13A and 13B illustrate an example scenario for handling a non-secure interrupt request and a secure interrupt request in accordance with the scheme shown in FIG. 12;

FIG. 14 is an example of a vector interrupt table;

FIG. 15 schematically illustrates a plurality of vector interrupt tables relating to different security domains;

FIG. 16 schematically illustrates an exception control register;

FIG. 17 is a flow diagram illustrating how an instruction attempting to modify a processing state register generates a separate mode change exception which in turn triggers entry into a monitor mode and running of a monitor program in a manner that modifies the security domain settings;

FIG. 18 schematically represents a thread of control of a processor operating in multiple modes, wherein tasks in the monitor mode are interrupted;

FIG. 19 schematically represents different threads of control of a processor operating in multiple modes;

FIG. 20 schematically represents another thread of control of a processor operating in multiple modes, wherein interrupts are enabled in a monitor mode;

FIGS. 21 to 23 illustrate views of different processing modes and scenarios for switching between secure and non-secure domains, according to another exemplary embodiment;

FIG. 24 schematically illustrates the principle of adding secure processing options to a conventional RAM core;

FIG. 25 schematically illustrates a processor having secure and non-secure domains and a reset;

FIG. 26 schematically illustrates the delivery of a processing request to a suspended operating system using a software pseudo-interrupt;

FIG. 27 schematically illustrates another example of delivery of a processing request to a suspended operating system via a software pseudo-interrupt;

FIG. 28 is a flow chart schematically illustrating a process performed upon receipt of a software pseudo-interrupt of the type generated in FIGS. 26 and 27;

FIGS. 29 and 30 schematically illustrate tasks after a secure operating system tracks possible task switches performed by a non-secure operating system;

FIG. 31 is a flow chart schematically illustrating a process performed when a call at the secure operating system of FIGS. 29 and 30 is received;

FIG. 32 is a diagram schematically illustrating the problem of interrupt priority reversal that occurs in a system having multiple operating systems, where different interrupts may be handled by different operating systems;

FIG. 33 is a diagram schematically illustrating the use of a instrumented interrupt) processor to avoid the problem shown in FIG. 32;

FIG. 34 schematically illustrates how interrupts of different types and priorities can be handled, depending on whether they can be interrupted by interrupts implemented with different operating systems;

FIG. 35 illustrates how processor structure data is overridden with monitor mode specific processor structure data when the processor is operating in monitor mode;

FIG. 36 is a flowchart illustrating how processor fabric data is switched when transitioning between secure and non-secure domains according to one embodiment of the invention;

FIG. 37 is a diagram illustrating memory management logic used in one embodiment of the invention to control access to memory;

FIG. 38 is a block diagram illustrating memory management logic for a second embodiment of the present invention used to control access to memory;

FIG. 39 is a flow diagram illustrating a process performed in one embodiment of the invention within memory management logic processing a memory access request specifying a virtual address;

FIG. 40 is a flow chart illustrating a process performed in one embodiment of the invention within memory management logic that processes memory access requests specifying physical addresses;

FIG. 41 schematically illustrates how the partition checker (partition checker) of the preferred embodiment acts to prevent access to physical addresses when the device issuing the memory access request is operating in a non-secure mode;

FIG. 42 is a diagram illustrating the use of non-secure page tables and secure page tables in a preferred embodiment of the present invention;

FIG. 43 is a diagram illustrating two forms of tags used within the main Translation Lookaside Buffer (TLB) of the preferred embodiment;

FIG. 44 illustrates how memory is partitioned after a boot stage in one embodiment of the invention;

FIG. 45 illustrates mapping of non-secure memory by a memory management unit according to the performance of a boot partition, according to an embodiment of the invention;

FIG. 46 illustrates how the entitlement of a portion of memory is modified to allow secure applications to share memory with non-secure applications, according to an embodiment of the present invention;

FIG. 47 illustrates how a device may be connected to an external bus of a data processing apparatus, according to one embodiment of the present invention;

FIG. 48 is a block diagram illustrating how devices are coupled to an external bus according to a second embodiment of the present invention;

FIG. 49 illustrates the configuration of physical memory in an embodiment using a single set of page tables;

FIG. 50A illustrates a configuration in which two MMUs are used to perform translation from a virtual address to a physical address via an intermediate address;

FIG. 50B illustrates, by way of example, another configuration in which two MMUs are used to perform translation from a virtual address to a physical address via an intermediate address;

FIG. 51 illustrates, by way of example, the correspondence of physical address spaces and intermediate address spaces for a secure domain and a non-secure domain;

FIG. 52 illustrates swapping memory areas between secure and non-secure domains by operating page tables associated with a second MMU;

FIG. 53 is an embodiment illustrating an implementation using a single MMU, and where an error in the main TLB would result in an exception called to determine the virtual to physical address translation;

FIG. 54 is a flow chart illustrating a process performed by a processor core for use with an exception issued upon a miss in the main TLB of the MMU of FIG. 53;

FIG. 55 is a block diagram illustrating elements provided within a data processing apparatus of one embodiment in which a cache has information regarding whether data stored in a single cache line is secure data or non-secure data;

FIG. 56 illustrates the structure of the memory management unit shown in FIG. 55;

FIG. 57 is a flowchart illustrating a process for handling a non-secure memory access request performed within the data processing apparatus of FIG. 55;

FIG. 58 is a flowchart illustrating a process performed within the data processing apparatus of FIG. 55 to process a secure memory access request;

FIG. 59 schematically represents a possible granularity of monitoring functions for programs running on a processor in different modes;

FIG. 60 illustrates a possible manner of initiating different monitoring functions;

FIG. 61 shows a table of control values for controlling the availability of different monitoring functions;

FIG. 62 shows a trigger view for positive edge triggering;

FIG. 63 shows a scan chain cell;

FIG. 64 shows a plurality of scan chain cells in a scan chain;

FIG. 65 shows a debug TAP controller;

FIG. 66A shows a debug TAP controller having a JADI input;

FIG. 66B shows a scan chain cell with a bypass register (bypass register);

FIG. 67 schematically illustrates a processor including cores, scan chains, and debug status and control registers;

FIG. 68 schematically illustrates factors that control debug or trace initialization;

FIGS. 69A and 69B show an overview of debug granularity;

FIG. 70 schematically illustrates debug granularity at runtime; and

fig. 71A and 71B show monitoring debugging when debugging is allowed and when debugging is not allowed in the secure area, respectively.

Detailed Description

Fig. 1 is a block diagram illustrating a data processing apparatus according to a preferred embodiment of the present invention. The data processing apparatus comprises a processor core 10 within which is provided an Arithmetic Logic Unit (ALU)16 for executing sequences of instructions. The data required by ALU16 is stored in register set 14. The core 10 has various monitoring functions to allow capture of diagnostic data representing the activity of the processor core. For example, an Embedded Trace Module (ETM)22 is provided for generating a real-time trace of some activity of the processor core according to the contents of some control register 26 within EMT22 that defines the activity to be traced. Typically, the trace signal is output to a trace buffer, from which it can then be analyzed. A vector interrupt controller 21 is provided for managing the maintenance of multiple interrupts initiated by various peripheral devices (not shown).

In addition, as shown in FIG. 1, another monitoring function that can be provided within the core 10 is a debug function, an external debug application of the data processing apparatus being able to communicate with the core 10 via a Joint Test Access Group (JTAG) controller 18, the Joint Test Access Group (JTAG) controller 18 being coupled to one or more scan chains 12. Information about the state of various portions of processor core 10 can be output to an external debug application via scan chain 12 and JTAG controller 18. Built-in on-line emulation circuitry (ICE)20 is used to store conditions within registers 24 that identify when to start and stop debug functions, and thus, for example, will be used to store breakpoints, watchpoints, and the like.

Memory management logic 30, configured to manage memory access requests issued by the core 10 to access locations in the memory of the data processing apparatus, couples the core 10 to a system bus 40. Certain portions of memory may be embedded by direct connection to a system bus 40, such as the Tightly Coupled Memory (TCM)36 and cache 38 shown in FIG. 1. Additional devices may also be provided for accessing these memories, such as a Direct Memory Access (DMA) controller 32. Typically, various control registers 34, also referred to herein as Coprocessor (CP)15 registers, will be provided for defining certain control parameters of the various elements of the chip.

The chip containing the core 10 may also be coupled to an external bus 70 (e.g., a bus operating in accordance with the "advanced microcontroller bus architecture" (AMBA) specification developed by ARM Limited) via an external bus interface 42, and may also connect various devices to the external bus 70. These devices may include a master device, such as a Digital Signal Processor (DSP)50, or a Direct Memory Access (DMA) controller 52, as well as various slave devices, such as a boot ROM44, a screen driver 46, external memory 56, an input/output (I/O) interface 60, or a key storage unit 64. These various slaves shown in fig. 1 can also be regarded as containing components of the overall memory of the data processing device. For example, the boot ROM44 will form part of the accessible memory of the data processing apparatus, such as the external memory 56. In addition, devices such as the screen driver 46, the I/O interface 60, and the key storage unit 64 each include internal storage elements, such as registers or buffers 48, 62, 66, respectively, that are individually addressable as part of the overall memory of the data processing apparatus. As will be discussed in more detail later, a portion of memory, such as a portion of external memory 56, will be used to store one or more page tables 58 that define information related to memory access control.

As will be appreciated by those skilled in the art, the external bus 70 will typically have arbiter and decoder logic 54, using the arbiter to arbitrate among the multiple memory access requests issued by the multiple masters, e.g., core 10, DMA32, DSP50, DMA52, etc., while using the decoder to determine which slave on the external bus will process any particular memory access request.

Although in some embodiments, the external bus may be provided off-chip with the core 10, in other embodiments, the external bus may be provided on-chip with the core 10. This has the advantage that the security data on the external bus is easier to keep secret than when the external bus is off-chip. When the external bus is off-chip, data encryption techniques may be used to increase the security of the secure data.

Fig. 2 schematically illustrates various programs running on a processing system having a secure domain and a non-secure domain. The system has a monitoring program 72 that executes at least partially in a monitoring mode. In this exemplary embodiment, the security status flag is only accessible for writes in monitor mode, and may be written by the monitor program 72. The monitor 72 is responsible for managing the back and forth changes between secure and non-secure domains. From an off-core perspective, the monitor mode is always secure and the monitor is located in secure memory.

Within the non-secure domain, a non-secure operating system 74 and a plurality of non-secure applications 76, 78 are provided that execute in conjunction with the non-secure operating system 74. In the secure domain, a security kernel 80 is provided. The security kernel 80 can be viewed as forming a secure operating system. Typically, these security kernels 80 will be designed to provide only those functions that are critical to the processing activity that must be provided in the secure domain, so that the security kernels 80 can be as small and simple as possible, as this will make them more secure. A plurality of security applications 82, 84 are shown executing in conjunction with security kernel 80.

Fig. 3 illustrates a matrix of processing modes related to different security domains. In this illustrative example, the processing modes are symmetric with respect to the secure domain, and thus, mode 1 and mode 2 exist in both secure and non-secure forms.

The monitoring mode has the highest level of security access in the system and, in the exemplary embodiment, is the only mode that has the right to switch the system in either direction, between the non-secure domain and the secure inter-domain. Thus, upon switching, all domain switching to monitor mode occurs and monitor program 72 is executed within monitor mode.

Fig. 4 schematically illustrates another set of non-secure domain processing modes 1, 2, 3 and 4 and secure domain processing modes A, B and C. In contrast to the symmetric arrangement of fig. 3, fig. 4 shows that some processing modes may not exist in one or the other of the security domains. The monitoring mode 86 is also illustrated as spanning both the non-secure domain and the secure domain. The monitor mode 86 can be considered a secure processing mode because the security status flag can be changed in this mode and the monitor program 72 in monitor mode has the ability to set the security status flag itself, effectively providing a maximum level of security within the system as a whole.

Fig. 5 schematically illustrates another configuration of the processing modes with respect to the security domains. In this configuration, secure and non-secure domains and additional domains are identified. This further domain may be independent of other components of the system in a manner that does not require interaction with the secure or non-secure domains shown, such that its transmission is independent of those components to which it belongs.

As will be appreciated, processing systems, such as microprocessors, typically have register sets 88 in which operand values may be stored. FIG. 6 illustrates a programmer's mode view of an exemplary register set with special purpose registers provided for certain register numbers in certain processing modes. More specifically, the example of FIG. 6 is an extension of the known ARM register set (such as that provided in ARMLimited ARM processors, Cambridge, England) with a dedicated saved program state register, a dedicated stack pointer register, and a dedicated link register R14 for each processing mode, but in this case by providing a monitor mode. As shown in fig. 6, the interrupt mode has an additional special purpose register provided so that when entering the fast interrupt mode, no saving is required and then the register contents are restored from the other modes. In a similar manner to the fast interrupt mode, in further embodiments, the monitor mode may have further special purpose registers to speed up the processing of security domain transitions, as well as to reduce system latency associated with these transitions.

Fig. 7 schematically illustrates another embodiment in which the register set 88 is provided in the form of two complete and separate register sets for use in a secure domain and a non-secure domain respectively. This is a way to prevent secure data stored in registers operable in the secure domain from being accessed when switching to the non-secure domain. However, such an arrangement hinders the possibility of data transfer from the non-secure domain to the secure domain, which can be allowed and desired by replacing it with a fast and efficient mechanism in registers that are accessible in both the non-secure and secure domains.

An important advantage of having a secure register bank is to avoid the need to flush the contents of the registers before switching from one region to another. If latency is not a major issue, a simpler hardware system for the secure domain area, without duplicate registers, such as fig. 6, may be used. The monitoring mode is responsible for switching from one domain to another. Restoring the context, saving the previous context, and flushing the registers are performed by a monitor program executing at least partially in monitor mode. The system thus behaves as a virtualization model. Such embodiments are discussed further below. Reference will be made to the programmer mode of, for example, ARM7 on which the security features described herein are built.

Processor mode

Instead of a replication mode in the secure mode, the same mode supports both secure and non-secure domains (see fig. 8). The monitor mode knows the current state of the core, whether secure or not secure (e.g., as read out of the stored S bit as a coprocessor configuration register).

In fig. 8, whenever an SMI (software monitor interrupt instruction) occurs, the kernel enters a monitor mode to appropriately switch from one region to another.

Referring to fig. 9, where SMIs are allowed from user mode:

1. dispatcher running thread 1

2. Thread 1 needs to execute a security function > SMI security call and the kernel enters monitor mode. Under hardware control, the current PC and CPRS (current processor status registers) are stored in R14_ MON and SPSR _ MON (processor status registers saved for monitor mode) and IRQ/FIQ interrupts are disabled.

3. The monitor performs the following tasks:

setting S bit (safety status flag)

-saving at least R14_ mon and SPSR _ mon in the stack so that if an exception occurs while running the secure application, the non-secure context is not lost.

-checking whether to run a new thread: secure thread 1. The mechanism (via the thread ID table in some embodiments) indicates that thread 1 is active in the secure region.

-re-enabling IRQ/FIQ interrupts. Then, in the secure user mode, the secure application can start.

4. Run secure thread 1 until it ends, then transfer (SIM) onto the "return from secure" function of the monitor mode (IRQ/FIQ interrupts are disabled when the kernel enters monitor mode).

The "return from secure" function performs the following tasks:

indicating the safe thread 1 is finished (e.g. in case of a thread ID table, thread 1 is removed from the table).

-restoring and clearing the required registers from the stack non-secure context so that the secure data cannot be read as long as it is returned to the non-secure domain.

Then by SUBS instruction (which restores the program counter to the correct point and updates the state flags), transition to the non-secure domain, restore PC (from R14_ mon) and CPSR (from SPSR _ mon). Thus, the return point in the non-secure domain is the instruction following the previously executed SMI in thread 1.

6. Thread 1 executes until finished, and then returns control to the scheduler.

Depending on the particular embodiment, some of the above functionality may be split between the monitor and the secure operating system.

In other embodiments, it is not desirable to have SMIs enabled while in user mode.

Secure enclave entry

Reduction of position

When a hardware reset occurs, the MMU is disabled and the ARM core (processor) is transitioned to a secure supervisor mode with the S bit set. The SMI entering the monitor mode can be executed whenever the secure boot is terminated, and the monitor can switch to the OS in the non-secure region (non-secure svc mode) if necessary. This can simply boot and ignore the security state in a secure supervisor mode if it is desired to use a conventional OS.

SMI instruction

This instruction (mode switch software interrupt instruction) can be invoked from any non-secure mode in the non-secure domain (as previously described, it may be desirable to limit SMIs to privileged mode), but the target entry point determined by the correlation vector is always fixed and within monitor mode. Up to the SMI handler in order to transfer to the appropriate security function that must be run (e.g. controlled by operands passed through the instruction).

The passing of parameters from the non-secure area to the secure area is performed using shared registers of a register set within the register set of the type of figure 6.

When an SMI occurs in an unsecured area, the ARM core, in hardware, can perform the following actions:

transferring the SMI vector (allowing secure memory access since it will now be in monitor mode) into monitor mode

-saving PC in R14_ mon and CPSR in SPSR _ mon

Using a monitor program, setting the S bit

In monitor mode, start execution of the security exception handler (in case of multithreading, restore/save context)

Transition to secure user mode (or another mode, such as svc mode) in order to execute the appropriate function

Disable IRQ and FIQ, while the core is in monitor mode (increase latency)

Secure enclave logout

Two possibilities for exiting the secure area:

-ending the secure function and returning to the previous non-secure mode in which the function has been called.

Interrupting the security function by a non-security exception (e.g. IRQ/FIQ/SMI).

Normal termination of security function

The secure function terminates normally and the application in the non-secure area needs to be restored with the instruction right after the SMI. In secure user mode, an "SMI" instruction is executed to return to monitoring mode by appropriate parameters corresponding to a "return from secure area" routine. At this stage, the registers are flushed to avoid data leakage between the unsecure and secure regions, and then the unsecure context general purpose registers are restored and the unsecure group registers are updated with the values already in the unsecure region. R14_ mon and SPSR _ mon thus obtain the appropriate values to resume the non-secure application after the SMI by executing the MOVS PC, R14 instruction.

Secure function exit due to non-secure exception

In this case, the secure function is not ended, and after entering the non-secure exception handler, the secure context must be saved, regardless of whether the interrupts need to be handled.

Safety interruption

For a safety interruption, several possibilities exist.

Two possible solutions are proposed, depending on the following:

what kind of interruption (safe or not)

When an IRQ is present (whether in a secure or non-secure region), the kernel is in what mode.

Solution one

In this solution, two different pins are required to support secure and non-secure interrupts.

When in the non-safety area, if

An IRQ occurs and the core enters IRQ mode to handle the interrupt, as in an ARM core, such as ARM 7.

-SIRQ present, kernel enters monitor mode to save non-secure context and then enters secure IRQ handler to handle secure interrupts.

When in the safe area, if

SIRQ occurs and kernel enters secure IRQ handler. Kernel not leaving secure enclave

-IRQ is present, the kernel enters monitor mode, where the secure context is saved, and then enters the non-secure IRQ handler to handle the non-secure interrupt.

In other words, the kernel directly enters the monitoring mode when there is an interruption that does not belong to the current area, otherwise stays in the current area (see fig. 10).

IRQ in secure enclaves

See FIG. 11A:

1. the scheduler runs thread 1.

2. Thread 1 needs to execute a security function > SMI security call and the kernel enters monitor mode. Current PC and CPSR are saved in R14_ MON and SPSR _ MON, IRQ/FIQ is disabled.

3. The monitor processing program (program) performs the following tasks:

-setting the S bit.

At least R14_ mon and SPSR _ mon are saved in the stack (and possibly also pushed to other registers) so that if an exception occurs while running the secure application, the non-secure context is not lost.

-checking for running a new thread: security thread 1: the mechanism indicates (via the thread ID table) that thread 1 is valid in the secure enclave.

-then starting the secure application in secure user mode. The IRQ/FIQ is then re-enabled.

4. The IRQ occurs while running security thread 1. The kernel jumps directly to monitor mode (a particular vector) and, in monitor mode, stores the current PC in R14_ mon and the CPSR in SPSR _ mon, (and then disables IRQ/FIQ).

5. The secure context must be saved and the previous non-secure context restored. The monitor handler may switch to IRQ mode to update R14_ IRQ/SPSR _ IRQ with the appropriate values and then pass control to the non-secure IRQ handler.

The IRQ handler provides the IRQ and then returns control to thread 1 in the insecure area. By restoring SPSR _ irq and R14_ irq to the CPSR and PC, thread 1 now points to the SMI instruction that has been interrupted.

7. The SMI instruction is re-executed (instruction same as 2).

8. The monitor handler notes that the thread has been previously interrupted and resumes the thread 1 context. Then transfer to secure thread 1 in user mode, pointing to the interrupted instruction.

9. Run secure thread 1 until completed, then transition to the "from secure return" function in monitor mode (special SMI).

The "return from secure" function performs the following tasks:

indicating that secure thread 1 is complete (i.e., thread 1 is removed from the table in the case of the thread ID table).

-restoring and clearing the required registers from the stack non-secure context so that the secure data cannot be read as long as it is returned to the non-secure area.

The PC is restored (from restored R14_ mon and CPSR (from SPSR _ mon)) by the SUBS instruction, causing a transition back to the insecure area.

11. Thread 1 is executed until the end, and then control is returned to the scheduler.

SIRQ in unsafe areas

See FIG. 11B:

1. dispatcher running thread 1

2. When safety line 1 is running, SIRQ occurs. The kernel jumps directly to monitor mode (specific vector) and in monitor mode, stores the current PC in R14_ mon and CPSR in SPSR _ mon, and then disables IRQ/FIQ.

3. The non-secure context must be saved and then the kernel enters the secure IRQ handler.

The IRQ handler provides the SIRQ and then returns control to the monitor mode handler using the SMI with the appropriate parameters.

5. The monitor handler restores the insecure context so that the SUBS instruction returns the kernel to the insecure area and resumes interrupt thread 1.

6. Thread 1 is executed until the end, and then control is returned to the scheduler.

The mechanism of fig. 11A has the advantage of providing a method of determination of entry into a secure area. However, there are some problems associated with interrupt priority: for example, a non-secure IRQ with a higher priority may occur when SIRQ is running in a secure interrupt handler. Once the non-secure IRQ is completed, the SIRQ event needs to be re-established so that the kernel can recover the secure interrupt.

Solution 2

In this mechanism (see fig. 12), two different pins, or only one, may support both secure and non-secure interrupts. Having two pins reduces interrupt latency.

When in the non-safety area, if

The IRQ is present and the core enters IRQ mode to handle the interrupt, as in an ARM7 system.

-SIRQ present, kernel enter IRQ handler, where SMI instruction will cause kernel to transition to monitor mode to save non-secure context and then enter secure IRQ handler to handle secure interrupt.

When in the safe area, if

SIRQ occurs and kernel enters secure IRQ handler. Kernel not leaving secure enclave

Upon occurrence of an IRQ, the kernel enters a secure IRQ handler, wherein an SMI instruction will cause the kernel to transition to monitor mode (in which a secure context is saved), and then enter a non-secure IRQ handler in order to handle the non-secure interrupt.

IRQ in secure enclaves

See FIG. 13A:

1. the scheduler runs thread 1.

2. Thread 1 needs to execute a security function > SMI security call and the kernel enters monitor mode. Current PC and CPSR are saved in R14_ MON and SPSR _ MON, IRQ/FIQ is disabled.

3. The monitor handler performs the following tasks:

-setting the S bit.

At least R14_ mon and SPSR _ mon are saved in the stack (last other register) so that if an exception occurs while running the secure application, the non-secure context is not lost.

-checking for running a new thread: security thread 1: the mechanism (via thread ID table) indicates that thread 1 is active in the secure region.

-then starting the secure application in secure user mode. The IRQ/FIQ is re-enabled.

4. The IRQ occurs while running security thread 1. The kernel jumps directly to secure IRQ mode.

5. The kernel stores the current PC in R14_ irq and the CPSR in SPSR _ irq. The IRQ handler detects this as an insecure interrupt and executes an SMI to enter the monitor mode with the appropriate parameters.

6. The secure context must be saved and the previous non-secure context restored. The monitor handler knows where the SMI came from by reading the CPRS. IRQ mode can also be entered to read R14_ IRQ/SPSR _ IRQ to save the security context appropriately. Non-secure contexts can also be saved in the same registers, and must be restored once the IRQ transaction is complete.

The IRQ handler provides the IRQ and then returns control to thread 1 in the insecure area. By restoring SPSR _ irq and R14_ irq to CPSR and PC, the kernel now points to the SMI instruction that has been interrupted.

8. The SMI instruction is re-executed (instruction same as 2).

9. The monitor handler notes that the thread has been previously interrupted and resumes the thread 1 context. Then transfer to secure thread 1 in user mode, pointing to the interrupted instruction.

10. Run secure thread 1 until completed, then transition to the "from secure return" function in monitor mode (special SMI).

The "return from secure" function performs the following tasks:

indicating that secure thread 1 is complete (i.e., thread 1 is removed from the table in the case of the thread ID table).

-restoring and clearing the required registers from the stack insecure context so that the secure data can be read as soon as it is returned to the insecure area.

By the SUBS instruction, branching back to the insecure area, restoring the PC (from restored R14_ mon and CPSR (from SPSR _ mon). the return point in the insecure area should be the instruction after the SMI previously executed in thread 1.

12. Thread 1 is executed until the end, and then control is returned to the scheduler.

SIRQ in unsafe areas

See FIG. 13B:

1. dispatcher running thread 1

2. When safety line 1 is running, SIRQ occurs.

3. The kernel directly jumps to the IRQ mode and stores the current PC in R14_ IRQ and the CPSR in SPSR _ IRQ, and then disables the IRQ. The IRQ handler detects that this is SIRQ and, with appropriate parameters, executes the SMI instruction.

4. Whenever in monitor mode, a non-secure context must be saved, then the kernel enters a secure IRQ handler.

The IRQ handler provides the SIRQ service routine and then returns control to the monitor mode handler via an SMI with appropriate parameters.

6. The monitor handler restores the insecure context so that the SUBS instruction returns the kernel to the insecure area and resumes the interrupt IRQ handler.

7. Then, by executing the SUBS, the IRQ handler returns to the insecure thread.

8. Thread 1 is executed until the end, and then control is returned to the scheduler.

With the mechanism of fig. 12, in the case of nested interrupts, SIRQ events do not need to be re-established, but there is no guarantee that a safe interrupt will be executed.

Anomaly vector

At least two physical vector tables are maintained (although from the viewpoint of virtual addresses they look like a single vector table), one for the non-secure regions in non-secure memory and one for the secure regions in secure memory (not accessible from the non-secure regions). The different virtual-to-physical memory mappings used in the secure and non-secure regions effectively allow the same virtual memory address to access different vector tables stored in physical memory. The monitor mode may always use a monotonic memory mapping to provide the third vector table in physical memory.

If the interrupt follows the mechanism of FIG. 12, there will be a vector as shown in FIG. 14 for each table. The set of vectors is copied in secure and non-secure memory.

Abnormality (S)	Deviation of vector	Corresponding mode
			Reduction of position	0x00	Supervision mode (S position setting)
Is not defined	0x04	Monitor/undefined mode
			SWI	0x08	Supervisory/monitoring mode
Prefetch abort	0x0C	Suspend mode/monitor mode

Data abort	0x10	Suspend mode/monitor mode
IRQ/SIRQ	0x18	IRQ mode
			FIQ	0x1X	FIQ mode
SMI	0x20	Undefined mode/monitor mode

NB. the reset item is only in the secure vector table, when a reset is performed in the non-secure region, the kernel hardware forces entry into the supervisor mode and sets the S bit to enable access to the reset vector in the secure memory.

Fig. 15 illustrates three exception vector tables applied to the secure mode, the non-secure mode, and the monitor mode, respectively. These exception vector tables may be programmed with exception vectors to meet the requirements and characteristics of both secure and non-secure operating systems. Each exception vector table may have an associated vector table base address register within CP15 that stores a base address pointing to that table in memory. When an exception occurs, the hardware will reference the vector table base address register corresponding to the current state of the system to determine the base address of the vector table to be used. In addition, three different vector tables stored at different physical memory addresses may be separated using different virtual-to-physical memory mappings applied in different modes. As shown in fig. 16, an abort mask register is provided in a system (configuration control) coprocessor (CP15) associated with a processor core. The abort mask register provides a flag associated with each exception type. These flags indicate whether the hardware is currently being used to directly process vectors for its current domain or should be forced to switch to a monitor mode (a secure mode) and then follow the vectors in the monitor mode vector table. The abort mask register (exception control register) can only be written from the monitor mode. Read access to the abort mask register can also be prevented when in the non-secure mode. It will be seen that the abort mask register of figure 16 does not include a flag for the reset vector because the system is configured to always jump this to the reset vector in the security supervision mode as specified in the security vector table in order to ensure secure boot and backward compatibility. It will be seen that in fig. 15, for completeness, the reset vectors are shown in the vector table in addition to the safety supervision mode safety vector table.

FIG. 16 also illustrates that the flags for different exception types within the abort mask register are programmable, such as by a monitor during secure boot. Additionally, some or all of the flags may be provided in some implementations by physical input signals, for example the security interrupt flag SIRQ may be hardwired so that when a security interrupt signal is received, the monitor mode is always enabled to input and execute the corresponding monitor mode security interrupt request vector. Fig. 16 illustrates only a portion of the abort register associated with a non-secure domain exception, for which a similar set of programmable bits would be provided.

Although it will be appreciated from the above that at one level, the hardware either forces interrupts to be implemented by current domain exception handling for control management or by monitor mode exception management depending on the exception control register flags, this is only the first level of control applied. For example, an exception may occur in secure mode with a secure mode exception vector following the secure mode exception handler, but the secure mode exception handler determines that the exception is a better attribute of the non-secure exception handler, and therefore utilizes the SMI instruction to switch to non-secure mode and invoke the non-secure exception handler. The reverse process is also possible, where hardware may be used to launch a non-secure handler, but then execute a secure exception handler or monitor the instructions of the mode exception handler for direct processing.

FIG. 17 is a flow chart schematically illustrating operation of the system to support additional possible handover request types related to new types of exceptions. At step 98, the hardware detects any instruction that is attempting to change monitor mode, as indicated in the Current Program Status Register (CPSR). When this attempt is detected, then a new type of exception is triggered, referred to as a CPSR collision exception. At step 100, the CPSR conflict exception layer is generated to reference the appropriate exception within the monitoring mode and at step 102 a monitor is run to handle the CPSR conflict exception.

It will be appreciated that in addition to supporting the SMI instruction described above, mechanisms for initiating a switch between secure and non-secure domains as described in relation to figure 17 may be provided. This exception mechanism may be provided in response to an unauthorized attempt to switch modes when all authorized attempts are made via the SMI instruction. Additionally, the mechanism may be a legal approach to switching between secure and non-secure domains or may be provided so as to provide backward compatibility with existing code, e.g. attempting to clear the processing state registers as part of its normal operation, even if it is not a real attempt to perform an unauthorized attempt to switch between a secure domain and a non-secure domain.

As described above, in general, interrupts are disabled when the processor is in monitor mode. This is done to increase the security of the system. When an interrupt occurs, the then-current processor state is stored in an interrupt exception register so that processing of the interrupt function can resume at the point of the interrupt when the interrupt function is completed. If the process is allowed in monitor mode, the security of the monitor mode is reduced, providing a possible secure data leak path. For this reason, in the monitor mode, the interrupt is normally disabled. However, one consequence of disabling interrupts during the monitor mode is increased interrupt latency.

If the processor state to execute the function is not stored, an interrupt may be allowed in the monitor mode. This can only be performed without restoring the function after the interruption. Thus, by allowing for the interruption of only the secure restart capable function in the monitor mode, the problem of interruption latency in the monitor mode can be solved. In this case, after an interrupt in the monitor mode, data relating to the processing of the function is not stored but discarded, and an instruction is issued to the processor after the interrupt is ended, and the function is processed from the beginning. In the above example, this is a simple event that is handled when the processor simply returns to the point when switching to monitor mode. It should be noted that some functions that can be restarted are only possible to restart and produce reproducible results for some specific functions. Restarting a function is not a good idea if the function has changed the state of the processor such that if it were restarted, a different result would be produced. For this reason, in the monitor mode, only those functions that can be safely restarted are interrupted, and for the other functions, the interruption is disabled.

FIG. 18 illustrates a method of handling interrupts that occur in a monitor mode, according to an embodiment of the invention. An SMI occurs during processing of task A in the non-secure mode and this switches the processor to the monitor mode. The SMI instruction causes the kernel to enter monitor mode via a dedicated non-secure SMI vector. Save the current state of the PC, set s bit and disable interrupts. In general, LR _ mon and SPSR _ mon are used to save the PC and CPSR in the non-secure mode.

Then the function, function C, is started in the monitoring mode. The first thing function C does is to allow interrupts and then process function C. If an interrupt occurs during processing of function C, the interrupt is not disabled in order to accept and execute the interrupt. However, the monitor mode indicator instructs the processor not to resume the function after the interrupt, but to restart. In addition, this may also instruct the processor through a separate control parameter. Thus, after an interrupt, the interrupt exception vector is updated with the values of LR _ mon and SPSR _ mon and the current state of the processor is not saved.

As shown in FIG. 18, upon completion of the interrupt task, task B, the processor reads the address of the SMI instruction that has been copied to the interrupt register and executes the SMI and begins to process function C again.

The above procedure can only be performed if the function C is repeatable, i.e. if restarted, procedure C will result in repeatable processing steps. The situation is quite different if function C changes any of the processor's states, such as the case of stack pointers that would affect its future processing. A function that is repeatable in this way is considered to be idempotent. One way to deal with the problem of functions that do not have idempotency is to rearrange the code defining the function in such a way that the first part of the code has idempotency and interrupts are disabled as long as different possible codes are arranged to have idempotency. For example, if code C involves writing to a stack, the operation may be performed without at least first updating the stack pointer. The code for function C can instruct the processor to disable interrupts whenever it is determined that it is no longer feasible to safely restart the code, and it can then update the stack pointer to the correct location. This is illustrated in fig. 18, where interrupts are disabled in some way by the processing of function C.

Fig. 19 illustrates a slightly different example. In this example, additional control parameters are set by some method of processing task C. This indicates that the subsequent part of task C is not strictly idempotent, but can safely be restarted assuming that the repair routine is run first. The repair routine is used to restore the state of the processor to the situation at the beginning of task C so that task C can be safely restarted and at the end of the task, the same processor state is generated as it would have been had it not been interrupted. In some embodiments, interrupts may be disabled for a short time while some state of the processor, such as a stack pointer being updated, is corrected at the point where additional control parameters are set. This allows the processor to later revert to the power-idempotent state.

When an interruption occurs after the further control parameters have been set, then there are two possible ways to do this. Either the repair routine is executed immediately (at F1) and then the interrupt can be handled, or the interrupt is processed immediately and, after the interrupt is completed, the SMI is executed and then the repair routine is executed (at F2) before restarting task C. As can be seen, in these embodiments, the repair routine is executed in monitor mode, and therefore does not affect execution in the non-secure domain, which is not aware of the secure domain or monitor mode.

As can be seen from fig. 19, the first part of the code C has idempotent and can be restarted after an interrupt. Assuming that the repair routine is run first, the second part can be restarted, which is indicated by setting an "additional" control parameter, and the last part of the code cannot be restarted, thus disabling the interruption before processing the code.

Fig. 20 illustrates a further example, in which case, unlike other embodiments, interrupts are allowed during the monitoring mode. Then, the function running in monitor mode is disabled as long as it can no longer be safely restarted. This is possible if all functions interrupted in monitor mode are restarted instead of resumed.

There can be several ways to ensure that when interrupted, all functions running in a certain mode are restarted instead of resumed. One approach is by adding a new processor state, where the interrupt saves the start address of the instruction sequence instead of the address of the interrupt instruction. In this case, the monitoring mode always operates in this state. Another approach is to interrupt the exception register by preloading the start address of the function into the interrupt exception register at the start of each function, and after the interrupt, disabling the sequential writing of the state of the processor.

In the embodiment shown in fig. 20, the restart of the function is performed immediately after the interruption function is terminated, or after the repair routine if it is required to safely restart the function.

Although the method of handling interrupt latency has been described in terms of a system having a secure and non-secure domain and a monitoring mode, it is clear that it can be applied to any system having functions that should not be restored for a particular reason. Typically, these functions operate by disabling interrupts that increase interrupt latency. Modifying functions to be rebooteable and controlling processors to reboot them after an interrupt allows at least a portion of the processing of the functions, allows interrupts and helps to reduce interrupt latency. Such as standard context switching of the operating system.

Accessing secure and non-secure memory

As described with reference to fig. 1, the data processing apparatus has a memory including, inter alia, the TCM36, the cache 38, the ROM44, the memory of the slave device and the external memory 56. As shown with reference to fig. 37, for example, the memory is partitioned into secure and non-secure memory. It will be appreciated that at the time of manufacture there is generally no substantial difference between the secure and non-secure memory regions of the memory, but when operating in the secure domain these regions are defined by the secure operating system of the data processing apparatus. Thus, any physical portion of the memory device may be allocated as secure memory, and any physical portion may be allocated as non-secure memory.

As described with reference to fig. 2 to 5, the processing system has a secure domain and a non-secure domain. In the secure domain, a secure kernel 80 is provided and executes in a secure mode. A monitor program 72 is provided that spans the secure domain and the non-secure domain and executes at least partially in a monitor mode. In an embodiment of the invention, the monitor program is executed partly in monitor mode and partly in secure mode. As shown for example in fig. 10, there are a plurality of safety modes, including in particular the supervision mode SVC.

The monitor 72 is responsible for managing all changes between secure and non-secure domains in either direction. In section "processor mode", some functions thereof are described with reference to fig. 8 and 9. The monitor program is responsive to a mode switch request SMI issued in a non-secure mode to initiate a switch from the non-secure mode to the secure mode and to a mode switch request SMI issued in a secure mode to initiate a switch from the secure mode to the non-secure mode. As described in the section "switching between regions", in monitor mode switching occurs at least some of the registers switch from one of the secure and non-secure domains to the other. Involving the saving of the state of registers present in one domain and the writing of new state to registers in another domain (or restoring of previously saved state in registers). As described herein, when such switching is performed, access to some registers may be prohibited. Preferably, in the monitor mode, the interrupt is disabled.

Because the monitor mode of monitor execution spans secure and non-secure domains, it is important to prove monitor security: i.e. it implements only those functions that it is intended to implement. It is therefore advantageous if the monitoring procedure is as simple as possible. The secure mode allows processes to be performed only in the secure domain. In this embodiment of the invention, the privileged secure mode and the monitor mode allow access to the same secure and non-secure memory. By ensuring that the privileged secure mode "sees" the same secure and non-secure memory, functions implemented only in the monitor mode are transferred to the secure mode which allows the monitor program to be simplified. In addition, this allows a process operating in the privileged secure mode to switch directly to the monitoring mode or vice versa. Switching from the privileged secure mode to the monitoring mode is allowed and in the monitoring mode, switching to the non-secure domain may be performed. The unlicensed security mode must use SMI to enter the monitor mode. The system enters a privileged secure mode after reset. Switching and returning between the monitor mode and the privileged security mode is performed to facilitate state saving when moving between domains.

In other embodiments, access to the S-tag may be allowed from within the secure privileged mode as well as the monitor mode. These security privileged modes have effectively had the ability to change the S flag (bit) if they were allowed to cause the processor to switch into a monitor mode while maintaining control of program flow. Therefore, it is not reasonable to provide the additional complexity of being able to change the S flag only within the monitoring mode. Instead, the S tag can be stored in the same manner as other configuration tags that are changed by one or more security privilege modes. These embodiments where the S flag may be changed within one of a plurality of security privilege modes are included in the current technology.

Returning to the previously described exemplary embodiment, the apparatus has a processor core 10, a definition mode and a privilege level that defines the mode, i.e., the set of functions that any mode allows. Thus, processor core 10 is configured in a well-known manner to allow secure and monitor modes to access both secure and non-secure memory and secure modes to access all memory that the monitor mode allows access to, and to allow processes operating in privileged secure mode to switch directly to monitor mode or vice versa. The processor core 10 is preferably configured to allow the following.

In one example of the apparatus, the memory is partitioned into secure memory and non-secure memory, and the secure and non-secure memories are accessible only in the monitor and secure modes. Preferably, the non-secure memory is accessible in a monitor mode, a secure mode and a non-secure mode.

In another example of the apparatus, the secure mode denies access to the non-secure memory in one or more of the monitor mode and the secure mode, and the secure and monitor modes deny access to the non-secure memory in the non-secure mode. Thus, security is increased by accessing the secure memory only in the monitor and secure modes, and by accessing the non-secure memory only in the non-secure mode.

In the example of the device, the reset and boot of the device may be performed in a monitor mode, which may be considered a more privileged mode of the secure mode. However, in many examples of the apparatus, it is configured to provide a reset or boot in the secure mode, which is possible because a direct switch between the secure mode and the monitoring mode is allowed.

As described with reference to fig. 2, in the secure domain, and in the secure mode, secure kernel 80 (or operating system) functions, and one or more secure applications 82, 84 may run under the secure kernel 80. The secure kernel and/or secure applications or any other program code running in secure mode are allowed to access the secure and non-secure memory.

Although examples of the invention have been described with reference to an apparatus having a processor, the invention may be implemented by a computer program which, when run on a suitable processor, causes the processor to operate as described in this section.

Further embodiments of the invention considered from the programmer's model will be described below with reference to fig. 21 to 23 as follows:

in the following description, the following terminology will be used which must be understood in the context of an ARM processor designed by ARM Limited of Cambridge, England.

-S bit: a security status bit included in a dedicated CP15 register.

- "safe/unsafe state". This state is defined by an S-bit value. Indicating whether the kernel has access to a secure area (when it is in a secure state, i.e., S-1) or is restricted to only a non-secure area (S-0). Note that the monitor mode (see also) covers the S-bit state.

The set of "insecure areas" has access to all hardware/software of insecure applications that do not require security.

A set of "secure regions" is all hardware/software (kernel, memory) that is accessible only when secure code is executed.

-a monitoring mode: and is responsible for switching the new mode of the kernel between the secure and non-secure states.

SUMMARY

The kernel always has access to the insecure area.

The kernel can access the secure area only when in the secure state or monitor mode.

-SMI: software monitoring interrupts: and enabling the kernel to enter a new instruction of a monitoring mode through a special SMI exception vector. "thread ID": an identifier associated with each thread (under OS control). For some types of OS, where the OS is running in an insecure area, each time a secure function is called, it is necessary to pass the current thread ID as a parameter in order to link the secure function to the insecure application it calls. Thus, secure enclaves can support multithreading.

-the secure interrupt defines an interrupt generated by the secure peripheral.

Programmer's model

Overview of Carbon Kernel

As used herein for the principles of the Carbon using the term processor of the present technology, the architecture includes two separate regions, a secure region and an unsecure region. The secure area must not leak any data to the insecure area.

In the proposed solution, the secure and non-secure states will share the same (existing) register set. Thus, all current modes (suspend, undefined, Irq, user.) that exist in the ARM core will exist in each state.

Due to the new status bit, the S (secure) bit, shown in the dedicated CP15 register, the kernel will know that it is operating in a secure or non-secure state.

The control that allows an instruction or event to modify the S bit, i.e. change from one state to another, is a major feature of the security of the system. The current technical solution proposes to add a new mode, the monitoring mode, that will "supervise" the switching between the two states. The monitor mode will be the only mode that allows modification of the S bit by writing to the appropriate CP15 register.

Finally, it is proposed to add some flexibility to exception handling. Except for reset, all exceptions will be handled in the state they appear, or directed to monitor mode. This would allow for configurability due to the dedicated CP15 register.

In the following paragraphs, details of this solution will be discussed.

Processor states and modes

Novel feature of Carbon

Safe or non-safe state (S position)

One of the main features of a Carbon core is the presence of an S bit, indicating whether the core is in a secure (S-1) or non-secure (S-0) state. When in the secure state, the kernel will have access to any data in the secure or non-secure region. When in the unsecure state, the kernel will be limited to accessing only the unsecure region.

The only exception to this rule relates to the prison mode, overriding the S-bit information. Even when S is 0, the kernel will perform secure privileged access when it is in monitor mode. See the next paragraph for monitoring patterns for additional information.

Only in monitor mode, the S bit can be read and written. Regardless of the value of S, if any other mode attempts to access it, it will be ignored or cause an undefined exception.

All exceptions have no effect on the safety status bit except reset. On reset, the S bit will be set and the kernel will start in monitor mode. See guide section for detailed information.

The secure/non-secure state is independent and operates independently of the ARM/Thumb/Java state.

Monitoring mode

One other important feature of the Carbon system is the creation of a new mode, the monitoring mode. This will be used to control the kernel switching between secure and non-secure states. It will always be considered secure mode, i.e. the kernel will always perform secure privileged access to the external region when it is in monitor mode, regardless of the value of the S bit.

Any security privileged mode (i.e. privileged mode when S ═ 1) will be able to switch to monitor mode simply by writing a CPSR mode bit (MSR, MOVS or equivalent instruction). However, this will be disabled in the non-secure mode or the secure user mode. If this happens frequently, the instruction will be ignored or an exception will result.

A dedicated CPSR collision exception will be required. Any attempt to switch to the monitoring mode by writing the CPSR directly from any non-secure mode or secure user mode will generate the exception.

When the monitor mode is active, virtually all exceptions except reset will be disabled:

● masking all interrupts

● all memory exceptions either can be ignored or result in a fatal exception

● undefined/SWI/SMI may either ignore or cause a fatal exception.

When the monitor mode is entered, interrupts are automatically disabled and the system monitor should be written so that no other type of exception occurs while the system monitor is running.

The monitor mode needs to have some special registers. This solution suggests copying only the minimum register set, namely R13(sp _ mon), R14(lr _ mon) and SPSR (spr _ mon).

In monitor mode, the MMU (monotonic address mapping) and MPU or partition checker are disabled (monitor mode will always perform secure privileged external accesses). However, the dedicated programmed MPU region attributes (cacheability..) will still be valid. Alternatively, a monitoring mode may be used regardless of which mapping the security domain uses.

New instruction

This proposal requires the addition of a new instruction to the existing ARM instruction set.

An SMI (software monitor interrupt) is used to enter monitor mode, transitioning on a fixed SMI exception vector. The instruction will be used primarily to indicate to the monitor that an exchange between non-secure and secure states is to be made.

As another approach (or in addition), new instructions may be added to allow the monitor mode to save/restore any other modes to/from the monitor stack to improve context switch performance.

Processor mode

As described in the previous paragraph, only one new mode, the monitor mode, is added to the kernel. All existing modes are still available and will exist in both secure and non-secure states.

In fact, the Carbon user will see the structure as shown in fig. 21.

Processor register

The present embodiment proposes that the secure and non-secure areas share the same register set. This means that when switching from one area to another through the monitoring mode, the system monitor will need to save the context of the first area and create (or restore) the context in the second area.

Passing parameters becomes a simple task: any data contained in a register in the first region will be used in the same register in the second region as long as the S bit has been toggled by the system monitor.

However, except for a limited number of registers dedicated to passing parameters, which require strict control, all other registers need to be cleared when passing from secure to non-secure state in order to avoid any leakage of the secure enclave.

It is also possible to implement hardware mechanisms or new instructions to flush registers directly when switching from a secure to a non-secure state.

Another proposed solution involves duplicating all (or most) of the existing register sets, so that there are two physically separated registers between secure and non-secure states. This solution has the main advantage of clearly separating the secure and non-secure data contained in the registers. Fast context switching between secure and non-secure states is also allowed. However, a disadvantage is that passing parameters through registers becomes difficult unless some special purpose instruction is created to allow secure regions to access non-secure registers.

FIG. 22 illustrates available registers according to processor mode. Note that the processor state has no effect on the subject.

Abnormality (S)

Safety interruption

Current solutions

It is currently proposed to keep the same interrupt pins, i.e., IRQ and FIQ, as in the current core. In connection with the abort mask register (defined later in this document), there is enough flexibility for any system to implement and handle different types of interrupts.

VIC enhancement

Increase VIC (vector interrupt controller) by the following method: the VIC may contain one bit of security information associated with each vector address. The bit can only be programmed through a monitor or security privileged mode. Indicating whether the considered interrupt should be considered safe and should therefore be handled at the secure end.

Two new vector address registers are also added, one for all secure interrupts that occur in the non-secure state and one for all non-secure interrupts that occur in the secure state.

The S bit information contained in CP15 will be available to the VIC as a new VIC input.

The following table summarizes different possible scenarios depending on the state of the input interrupt (safe or not, represented by the bit associated with each interrupt line) and the state of the kernel (S bit in CP 15-the S input signal on VIC).

	Inner core in safe state (CP15-S ═ 1)	Kernel in unsafe state (CP15-S ═ 0)
			Safety interruption	No inter-domain handover is required. The VIC provides the secure address associated with the interrupt line directly to the core. The kernel only needs to branch at this address, where the relevant ISR should be looked up	In the non-secure domain, the VIC does not have a vector associated with the interrupt. Thus, the kernel is provided with the address contained in the vector address register that is dedicated to all secure interrupts that occur in the non-secure region. Still in the unsecured region, the kernel then branches to that address where the SMI instruction should be looked up to switch to the secure region. As long as in the secure domain, the correct ISR will be accessible.
Non-safety interruption	In the secure domain, the VIC does not have a vector associated with the interrupt. Thus, the kernel is provided with the address contained in the vector address register that is dedicated to all non-secure interrupts in the secure region. Still in the secure enclave, the kernel then branches to that address, where the SMI instruction should be looked up to switch to the non-secure enclave. Will have access to the correct ISR as long as it is in the non-secure area	No inter-domain handover is required. The VIC provides the insecure address associated with the interrupt line directly to the core. The kernel only needs to branch at this address where the associated insecure ISR should be looked up

Exception handling configurability.

To increase the flexibility of the Carbon, a new register, abort mask, will be added to the CP 15. The register will contain the following bits:

-bit 0: undefined Exception (non-safety State)

-bit 1: SWI Exception (non-safety state)

-bit 2: prefetch abort exception (non-secure state)

-bit 3: data abort exception (non-secure state)

-bit 4: IRQ Exception (non-safety state)

-bit 5: FIQ Exception (non-safety state)

-bit 6: SMI Exception (non-safety/safety state)

-bit 16: undefined Exception (safe State)

-bit 17: SWI Exception (safe State)

-bit 18: prefetch abort exception (safe state)

-bit 19: data abort exception (safe state)

-bit 20: IRQ Exception (safe State)

-bit 21: FIQ Exception (safe State)

The reset exception does not have any corresponding bits in the register. A reset will always put the kernel into secure supervisor mode with its dedicated vector.

If the bit is set, the corresponding exception causes the kernel to enter monitor mode. Otherwise, the exception will be handled in the corresponding handler in the area in which it appears.

This register will only be visible in monitor mode. Any instruction that attempts to access it in any other mode will be ignored.

This register should be initialized to a system specific value depending on whether the system is monitoring the program. This functionality can be controlled by the VIC.

Exception vector table

Separate safe and unsafe exception vector tables are also required when there are separate safe and unsafe zones.

In addition, when the monitor program can also set some abort, a third exception vector table dedicated to the monitor program is also required.

The following table summarizes those three different exception vector tables:

in the non-secure memory:

address	Abnormality (S)	Mode(s)	When to automatically access
				0x00
0x04	Is not defined	Is not defined	When the kernel is in the non-secure state and the exception interrupt mask register [ non-secure undefined]Undefined instruction executed when 0

0x08	SWI	Supervision	When kernel is in non-safe state and abnormal interrupt shielding register [ non-safe SWI]Execute SWI instruction when 0
				0x0C	Prefetch abort	Pause	Abort the instruction when the kernel is in the unsecure state and the abort mask register [ unsecure PAbort ═ 0
0x10	Data abort	Pause	Abort data when kernel is in non-secure state and abort mask register [ non-secure DAbort ═ 0]
				0x14	Reservation
0x18	IRQ	IRQ	When kernel is in non-secure state and abnormal interrupt shielding register [ non-secure IRQ]IRQ pin inferred when 0
				0x1C	FIQ	FIQ	When kernel is in non-safety state and abnormal interrupt shielding register [ non-safety FIQ]FIQ pin inferred when 0

In the secure memory:

address	Abnormality (S)	Mode(s)	When to automatically access
				0x00	Reduction of	Supervision	Inferred reset pin
0x04	Is not defined	Is not defined	When the kernel is in the safe state and the exception interrupt mask register [ safe undefined ]]Undefined instruction executed when 0
				0x0g	SWI	Supervision	When kernel is in safe state and abnormal interrupt mask register secure SWI]Execute SWI instruction when 0
0x0C	Prefetch abort	Pause	Abort the instruction when the kernel is in the secure state and abort mask register [ secure PAbort ═ 0 [ ]
				0x10	Data abort	Pause	Abort data when the kernel is in the secure state and abort mask register [ secure DAbort ═ 0 [ ]
0x14	Reservation
				0x18	IRQ	IRQ	When kernel is in safe state and abnormal interrupt shielding register [ non-safe IRQ]IRQ pin inferred when 0
0x1C	FIQ	FIQ	When kernel is in safe state and abnormal interrupt shielding register [ non-safe FIQ]FIQ pin inferred when 0

See the "boot" section for further description of the reset mechanism.

In watch memory (monotonic mapping)

Address	Abnormality (S)	Mode(s)	When to automatically access
				0x00
0x04	Is not defined	Monitoring	When the kernel is in the safe state and the exception interrupt mask register [ safe undefined ]]1 and kernel in an unsecure state and an abort mask register [ unsecure undefined]Undefined instruction executed when 1
				0x08	SWI	Monitoring	When kernel is in safe state and abnormal interrupt mask register secure SWI]1 and kernel in unsecure state and abort mask register [ unsecure SWI]SWI instruction executed when 1
0x0C	Prefetch abort	Monitoring	When kernel is in safe state and abnormal interrupt shielding register [ safe IAbort]1 and kernel in unsecure State and abort mask register [ unsecure IAbort ]]When 1, the instruction is suspended
				0x10	Data abort	Monitoring	When the kernel is in the safe state and the abnormal interrupt shielding register [ safe PAbort ]]1 and kernel in unsecure State and abort mask register [ unsecure PAbort ]]When 1, the data is suspended
0x14	SMI	Monitoring
				0x18	IRQ	Monitoring	When kernel is in safe state and abnormal interrupt shielding register safety IRQ]1 and kernel in unsecure State and abort mask register [ unsecure IRQ]IRQ pin inferred when 1
0x1C	FIQ	Monitoring	When kernel is in safe state and abnormal interrupt shielding register

Full FIQ]1 and kernel in unsecure State and abort mask register [ unsecure FIQ]FIQ pin inferred when 1

In monitor mode, the anomaly vectors can be replicated so that each anomaly will have two different correlation vectors:

an exception for occurrence in an unsafe state

An exception for occurrence in a safe state

This is useful to reduce the exception latency, since the monitoring core no longer has the need to detect the original state of the exception occurrence.

Note that this feature may be limited to exceptions, SMI being the most appropriate candidate for improving the switch between secure and non-secure states.

Inter-domain handover

When switching between states, the monitoring mode must save the context of the first state on its monitoring stack and restore the second state context from the monitoring stack.

Thus, the monitor mode requires access to any register of any other mode, including special purpose registers (r14, SPSR.).

To deal with this, the proposed solution consists in providing any privileged mode in the secure state with the right to switch directly to the monitor mode by simply writing a CPSR.

With this system, switching between areas is performed as follows:

-entering a monitoring mode

Setting the S bit

Switching to supervisor mode-saving the monitor register on the monitor stack (of course supervisor mode would require access to the monitor stack pointer, but this can be easily achieved, for example by using common registers (R0-R8))

Switching to system mode-saving a register (identical to user mode) on the monitoring stack

-monitoring IRQ registers on the stack

Use in all modes

Reverting to supervisor mode by a simple MSR instruction (simply writing the supervisor value in the CPSR mode field) once all the special registers of all modes are saved

Other solutions are also contemplated:

-adding a new instruction that allows the monitor to save the other mode's special purpose register on its own stack.

Implement the monitor program as a new "state", i.e. able to be in monitor state (with appropriate access rights) and IRQ (or any other mode) to look at IRQ (or any other) special purpose register.

Basic situation (see FIG. 23)

1. Thread 1 runs in an unsecured area (S bit ═ 0)

2. With an insecure SMI vector, the SMI instruction causes the kernel to enter monitor mode.

LR _ mon and SPSR _ mon are used to save the PC and CPSR in the non-secure mode.

At this stage, the S bit remains unchanged, although the system is now in a secure state.

The monitor core saves the non-secure context on the monitor.

LR _ mon and SPSR _ mon are also pushed in.

The monitor core then changes the "S" bit by writing to the CP15 register.

In this embodiment, the monitoring kernel records that "secure thread 1" is to be initiated in a secure area (e.g., by updating the thread ID table).

Finally, it exits the monitor mode and switches to the safety supervision mode (MOVS instructions after updating LR _ mon and SPSR _ mon.

3. The security kernel dispatches the application to the correct secure storage location and then switches to user mode (e.g., using MOVS).

4. The security function is executed in the secure user mode. Once completed, an "exit" function is called by executing the appropriate SWI.

5. The SWI instruction causes the kernel to enter secure svc mode by executing the special SWI vector of the exit function in return. The "exit" function ends with "SMI" to switch back to monitor mode.

An SMI instruction causes the kernel to enter monitor mode with a dedicated secure SMI vector.

The LR _ mon and SPSR _ mon are used to save PC and CPSR in secure svc mode.

The S position is still unchanged (namely a safe state)

The monitor core records the fact that security thread 1 ended (removed from the thread ID table is security thread 1ID

The "S" bit is then changed by writing to the CP15 register, returning to an unsecured state.

The monitoring core restores the non-secure context from the monitoring stack.

In step 2, the previously saved LR _ mon and SPSR _ mon are also loaded.

Finally, upon instruction, it exits the watch mode via the SUBS, returning the kernel to the unsecure user mode.

7. Thread 1 can resume normally.

Referring to fig. 6, all registers are shared between secure and non-secure domains. In monitor mode, a switch occurs, with the register switching from one of the secure and non-secure domains to the other. Including saving the state of registers present in one domain and writing the new state to registers in the other domain (or restoring a previously saved state in registers), as described in the "switch between domains" section above.

It is desirable to reduce the time required to perform this switch. To reduce the time taken to perform a switch, shared registers are disabled while switches between secure and non-secure domains remain unchanged with the values stored therein. For example, assume a switch from a non-secure domain to a secure domain. It is assumed that the FIQ register shown in fig. 6 is not needed, for example, in the secure area. Therefore, those registers are disabled and do not need to be switched to the secure domain and the contents of those registers do not need to be saved.

The disable register may be implemented in a number of ways. One approach is to lock out the mode in which those registers are used. This is accomplished by writing a control bit into the CP15 register indicating that mode is disabled.

Additionally, access to the registers may be disabled on an instruction-by-instruction basis by writing control bits to the CP15 registers. The bit written into CP15 is explicitly associated with the register rather than the mode, so that instead of disabling the mode, access to the register in the mode is disabled.

The FIQ register stores data related to fast interrupts. If the FIQ register is disabled and a fast interrupt occurs, the processor signals an exception in the monitor program. In response to an exception, the monitor mode can be used to save any data value associated with one domain and stored in the disable register and load a new data value associated with another domain into that register, and then re-enable the FIQ mode register.

The processor may be configured to disable all of the banked registers when the processor switches domains when in the monitor mode. In addition, the disable register is optional because some predetermined shared registers are disabled when switching domains, and other registers may be disabled according to the programmer's selection.

The processor may be configured to disable one or more of the shared registers when switching domains in the monitor mode, and when there is one domain, one or more other shared registers hold their data and load new data in another domain. The new data may be null data.

Figure 24 schematically illustrates the principle of adding secure processing options to a conventional ARM core. This figure schematically shows how a processor containing secure processing options can be formed by adding secure processing options to an existing core. If the system is to be backward compatible with existing legacy operating systems, it is intuitive to think of legacy systems operating in the legacy non-secure portion of the processor. However, as schematically shown in the lower half of the figure and described in further detail below, in practice, conventional systems operate in the secure portion of the system.

Fig. 25 shows a processor having secure and non-secure domains and illustrating a reset and similar to fig. 2. FIG. 2 illustrates a processor operable to run security-sensitive operations through a secure OS system that controls processes in a secure domain and a non-secure OS system that controls processes in a non-secure domain. However, the processor is backward compatible with legacy operating systems, and therefore, the processor operates in a security insensitive manner using legacy operating systems.

As shown in fig. 25, the reset is in the secure domain and occurs with the S bit or security state flag set regardless of the type of operation. In the case of a security insensitive operation, a reset occurs in the secure domain and then processing continues within the secure domain. However, the traditional operating system that controls the process is unaware of the security aspects of the system.

As shown in fig. 25, a reset is performed to set an address from which processing in the safety supervision mode is started, regardless of whether the processing is safety-sensitive or actually safety-insensitive. Once the reset is performed, additional tasks present in the boot or reboot mechanism are performed. The following describes the boot mechanism.

Boot mechanism

The boot mechanism must take into account the following features:

maintaining compatibility with legacy OSes

Booting in the most privileged mode in order to ensure the security of the system.

Thus, the Carbon kernel will boot in secure supervisor mode.

The different systems would then be:

for systems that want to run a legacy OS, the S bit is not considered and the kernel will just see it booted in supervisor mode.

For systems that wish to use the Carbon feature, the kernel boots in a security privileged mode in which all security protections should be able to be configured in the system (which may be after switching to the monitor mode).

In accordance with the details of the boot mechanism given above, the processor of embodiments of the present invention resets the processor to begin processing in a secure supervisory mode under all circumstances. In the case of security insensitive operation, the operating system actually operates in the secure domain, although security is not an issue here, because the S bit is set (although the operating system is unaware of this). This has the advantage that parts of the memory that cannot be accessed from the non-secure domain are accessible in this case.

In a safety-sensitive system, booting in a safety supervision mode is also advantageous in all cases, since it helps to ensure the safety of the system. In a security sensitive system, in a secure supervisor mode, an address is provided at a boot point where a boot program is stored, allowing the system to configure as a secure system and switch to a monitor mode. It is generally allowed to switch from the safety supervision mode to the supervision mode and, at the appropriate time, to start processing in the supervision mode for initializing the monitoring mode configuration.

FIG. 26 illustrates that at step 1, an insecure thread NSA is executed by an insecure operating system. At step 2, the insecure thread NSA invokes the secure domain via the monitor mode running the monitor mode program at step 3. At step 5, the monitor mode program changes the S bit to switch domains and performs any required context save and context restore before moving to the secure operating system. Then, at step 6, the corresponding secure thread SA is executed before being subjected to the interrupt irq. At step 7, the interrupt handling hardware triggers a return to a monitoring mode in which it is determined whether the relevant interrupt is to be handled by a secure operating system or a non-secure operating system. In this case, the interrupt will be handled by the insecure operating system beginning at step 9. When the interrupt is handled by the non-secure operating system, the non-secure thread NSA is restored to the current task in the non-secure operating system before the normal thread switching operation at step 11. The thread switch may be the result of a timed event wait. At step 12, a different thread NSB is executed through a non-secure domain in the non-secure operating system, and then at step 14, the secure domain is invoked via the monitoring domain/program. The monitor of step 7 has stored a flag, which in some other mechanism, is used to indicate that the secure operating system was last halted, rather than left, as the secure thread has finished executing or left due to a normal request, depending on the outcome of the interrupt. Thus, since the secure operating system is suspended by the interrupt, the monitor of step 15 re-enters the secure operating system using a software pseudo-interrupt that specifies the return thread ID (e.g., an identifier of the thread initiated by the secure operating system and other parameter data upon request by the non-secure thread NSB). These parameters of the software dummy interrupt may be passed as register values.

At step 15, the software pseudo-interrupt triggers the return interrupt handler routine of the secure operating system. The return interrupt handler routine checks the return thread ID of the software pseudo-interrupt to determine if this matches the thread ID of the secure thread SA that was interrupted when the secure operating system was last executed before the pause. In this case there is no match and therefore, at step 16, the secure operating system is triggered to perform a switch to the thread of the return thread as specified by the non-secure thread NSB after the context of the secure thread SA has been saved. The secure thread SA is then restarted from the point of the interrupt, upon request.

Fig. 27 schematically illustrates another example of the type of behavior shown in fig. 26. In this example, although the process executes to process irq under the control of the non-secure operating system, there is no non-secure switch, and therefore when the return interrupt handler of the secure operating system receives a software dummy interrupt, it is determined that a thread switch is not required, and at step 15, only the secure thread SA is resumed.

Fig. 28 is a flowchart schematically illustrating processing performed by the return thread handler. At step 4002, a return to thread handler is initiated. At step 4004, when the secure operating system is halted, a return thread identifier from the software pseudo-interrupt is checked and compared to the currently executing secure thread. If these match, then processing proceeds to step 4006, where the secure thread is resumed. If at step 4004 the comparison yields a mismatch, then processing proceeds to step 4008, where the context of the previous secure thread is saved (for subsequent recovery) before performing a switch to the new secure thread at step 4010. The new thread may have already been done so step 4010 is a resume.

FIG. 29 schematically illustrates the process of a slave secure operating system following a task switch performed by a master non-secure operating system. The primary unsecure operating system may be a conventional operating system, without mechanisms for communicating with other operating systems and coordinating their activities, and thus operates only as the primary program. As a starting entry point in fig. 29, the insecure operating system is executing an insecure thread NSA. Using a software interrupt, the insecure thread NSA calls a secure thread, SMI, to be executed by the secure operating system. At step 2, the SMI call enters a monitor program that executes in monitor mode, whereby, at step 4, the monitor program performs any necessary context saving and switching before passing the call to the secure operating system. The secure operating system then starts the corresponding secure thread SA. The secure thread may return control to the non-secure operating system via the monitor mode, such as a result of a timer event or the like. When the insecure thread NSA passes control to the secure operating system again in step 9, this is performed by reissuing the original software interrupt. The software interrupt includes an insecure thread ID identifying the NSA, a secure thread ID of the target secure thread to be activated, i.e., a thread ID identifying the secure thread SA, and other parameters.

When the call generated at step 9 is passed through the monitor and received at step 12 by the secure operating system, in the secure domain, the insecure thread ID is checked to determine if there is a context switch by the insecure operating system. The secure thread ID of the target thread may also be checked to see the correct thread under the secure operating system restarted or started as a new thread. In the example of FIG. 29, with a secure operating system, no thread switching is required in the secure domain.

FIG. 30 is similar to FIG. 29 except that a thread switch occurs at step 9 in the non-secure domain under the control of the non-secure operating system. Thus, in step 11, it is the software interrupt call that is passed through the different non-secure thread NSB of the secure operating system. At step 14, the secure operating system identifies the different thread ID of the non-secure thread NSB, and therefore performs a task switch that includes saving the context of the secure thread SA and starting the secure thread SB.

FIG. 31 is a flow chart that schematically illustrates the processing performed by the secure operating system when a software interrupt is received as a call to start a thread or to resume a thread of the secure operating system. At step 4012, a call is received. At step 4014, the parameters of the call are examined to determine if they match the currently active secure thread on the secure operating system. If a match occurs, then the secure thread is restarted, at step 4016. If a match does not occur, then processing proceeds to step 4018, where a determination is made as to whether the newly requested thread is available. The newly requested thread is unavailable due to reasons such as it being or requiring a mutually exclusive resource that is already being used by some other thread executing on the secure operating system. In this case, the call is rejected at step 4020 by an appropriate message returned to the non-secure operating system. If it is determined in step 4018 that a new thread is available, then processing proceeds to step 4022, where the context of the previous secure thread is saved for possible later resumption. At step 4024, a switch is made to the new secure thread as specified in the software interrupt call to the secure operating system.

Fig. 32 schematically illustrates an operation in which priority reversal occurs when an interrupt within a system having a plurality of operating systems is processed by different interrupts processed by different operating systems.

Processing begins with the secure operating system executing the secure thread SA. And then interrupted by a first interrupt Int 1. This triggers the monitor in monitor mode to determine whether the interrupt is to be handled in the secure domain or the non-secure domain. In this case, the interrupt will be processed in the secure domain and processed back to the secure operating system, initiating an interrupt handling routine for interrupt Int 1. By the time half of the interrupt handling routine for Int1 is executed, an additional interrupt Int2 with a higher priority is received. Thus, the interrupt handler for Int1 is stopped, and the monitor in monitor mode is used to determine that the interrupt Int2 is to be handled. In this case, the interrupt Int2 will be handled by the insecure operating system, so control passes to the insecure operating system and the interrupt handler for Int2 starts. When the interrupt handler for interrupt Int2 ends, the non-secure operating system does not have information indicating that there is a pending interrupt Int2 in the secure domain that has suspended maintenance. Thus, the insecure operating system may perform some additional processing, such as task switching or launching a different insecure thread NSB, while the initial interrupt Int1 remains unprocessed.

Fig. 33 illustrates a technique that can avoid problems associated with the operation of fig. 32. When the interrupt Int1 is generated, the monitor passes this to the non-secure domain, where the instrumented interrupt handler is launched. The instrumented interrupt handlers are relatively small and, via monitor mode, quickly return processing to the secure domain and trigger interrupt handlers within the secure domain for interrupts Int 1. Handling the interrupt Int1 primarily in the secure domain and launching the instrumented interrupt handler in the non-secure domain can be viewed as a stake, indicating to the non-secure domain that the interrupt is being suspended in the secure domain.

The interrupt handler in the secure domain for interrupting Int1 again encounters high priority Int 2. As previously described, this triggers the execution of an interrupt handler in the non-secure domain for interrupting Int 2. However, in this case, when that interrupt handler for Int2 ends, the non-secure operating system has data indicating that a instrumented interrupt handler for interrupt Int1 is still pending, and therefore, the instrumented interrupt handler will be restored. The instrumented interrupt handler appears to hang at a point that causes it to call back to the secure domain, thus re-executing the call, thereby switching to the secure domain. Once back in the secure domain, the secure domain itself can restart the interrupt handler for the interrupt Int1 at the point that it was suspended. When the interrupt handler for the interrupt Int1 ends in the secure domain, the call returns to the non-secure domain to shut down the instrumented interrupt handler in the non-secure domain before resuming the initial execution of the secure thread SA.

FIG. 34 schematically illustrates interrupts with their associated priorities and different types and how they are processed. High priority interrupts are processed using fully secure domain interrupt handlers that provide higher priority interrupts that are not processed by the non-secure domain. As long as there are interrupts of higher priority than subsequent interrupts and that are processed in the non-secure domain, all lower interrupts must be processed entirely in the non-secure domain or using the instrumented interrupt handler technique shown in figure 33, so that the non-secure domain is aware of the interrupts, even if most of their processing occurs in the secure domain.

As previously described, a monitoring mode is used to perform a switch between secure and non-secure domains. In an embodiment where registers are shared between two different domains, this involves saving the state within those registers in memory and then loading the new state for the target domain from memory into those registers. For any registers that are not shared between the two domains, it is not necessary to save state, since those registers will not be accessed by the other domain, and the switch between states is implemented as a direct switch result between secure and non-secure domains (i.e., the value of the S bit stored in one of the CP15 registers determines which non-shared register to use).

The portion of the state that needs to be switched when in monitor mode is processor configuration data that controls access to memory by the processor. Since within each domain there is a different view of memory, e.g. a secure domain accessing secure memory for storing secure data, which secure memory cannot be accessed by a non-secure domain, it is clear that when switching between domains, processor configuration data needs to be changed.

As shown in fig. 35, the processor configuration data is stored in CP15 registers 34, and in one embodiment, these registers are shared between domains. Thus, when switching monitor modes between secure and non-secure domains, the processor configuration data currently in the CP15 registers 34 needs to be moved from the CP15 registers into memory, while the processor configuration data relating to the target domain needs to be loaded into the CP15 registers 34.

Since the processor configuration data in CP15 typically has a rapid effect on accessing memory within the system, it is clear that these settings are quickly valid when operating in monitor mode by the processor updating them. However, this is not desirable because it is desirable for the monitor mode to have a static processor configuration data set that controls access to the memory when in the monitor mode.

Thus, as shown in FIG. 35, in one embodiment of the present invention, monitor mode specific processor configuration data 2000 is provided that can be used to overwrite the processor configuration data in CP15 register 34 when the processor is operating in monitor mode. This is achieved in the embodiment shown in fig. 35 by providing a multiplexer 2010 that receives at its inputs the processor configuration data stored in the CP15 registers and the monitor mode specific processor configuration data 2000. In addition, multiplexer 2010 receives a control signal on path 2015 indicating whether the processor is operating in monitor mode. If the processor is not operating in monitor mode, the processor configuration data in the CP15 registers 34 is output to the system, but in the case of the processor operating in monitor mode, the multiplexer 2010 instead outputs monitor mode specific processor configuration data 2000 to ensure that a consistent set of processor configuration data is applied while the processor is operating in monitor mode.

The monitor mode specific processor configuration data can be hard coded within the system to ensure that it cannot be operated. However, assuming that only the monitor mode-specific processor configuration data can be modified when operating in the secure privileged mode, the monitor mode-specific processor configuration data 2000 can be programmed without compromising security. This provides some flexibility regarding the settings of the monitor mode specific processor configuration data. If the monitor mode processor configuration data is configured to be programmable, the configuration data can be stored in a separate register set in an appropriate location within the system, such as within CP15 registers 34.

Typically, the monitor mode specific processor configuration data will be set in order to provide a very secure environment for operating the processor in the monitor mode. Thus, in the above embodiments, the monitor mode specific processor configuration data may specify that the memory configuration unit 30 is disabled when the processor is operating in the monitor mode, thereby disabling any virtual to physical address translation that may be applied by the memory management unit. In this case, the processor is always configured to send the physical address directly when a memory access request is issued, i.e. a monotonic mapping will be employed. This ensures that the processor can reliably access memory while operating in monitor mode, regardless of whether any virtual-to-physical address mappings have been tampered with.

The monitor mode specific processor configuration data also typically specifies that the processor is allowed to access secure data when the processor is operating in the monitor mode. This is preferably specified by the memory enable data using a domain status bit having the same value as would be specified for the corresponding domain status bit ("S" bit) within the secure processor configuration data. Thus, regardless of the actual value of the domain status bit stored within the CP15 register, access to secure data by the supervisor mode is ensured by the domain status bit specified by the supervisor mode specific processor configuration data overriding that value.

The monitor mode specific processor configuration data also specifies other data used to control access to portions of the memory. For example, monitor mode specific processor configuration data may specify that when the processor is operating in monitor mode, the cache 38 is not used to access the data.

In the above embodiment, it has been assumed that all CP15 registers containing processor configuration data are shared between domains. However, in the above embodiments, the plurality of CP15 registers are "ganged" so as to have, for example, two registers for storing particular items of processor configuration data, one register being accessible in the non-secure domain and containing the value of that item of processor configuration data for the non-secure domain, and the other register being accessible in the secure domain and containing the value of that item of processor configuration data for the secure domain.

One CP15 register that is not to be banked is to contain an "S" bit, but in principle any other CP15 register may be banked if desired. In these embodiments, switching processor configuration data by monitoring modes includes moving processor configuration data currently in those shared registers from any shared CP15 registers into memory, and loading processor configuration data related to the target domain into those shared CP15 registers. For any banked register, the processor configuration data need not be stored out of memory, but rather the switch will occur automatically as a result of changing the S-bit value stored in the associated shared CP15 register.

As previously described, the monitor mode processor configuration data will include a domain status bit that overrides the domain status bit stored in the associated CP15 register, but has the same value as the domain status bit for use in the secure domain (i.e., in the above-described embodiment, the S-bit value is 1). When multiple CP15 registers are ganged, this means that at least a portion of the monitor mode dedicated processor configuration data 2000 in fig. 35 can be derived from the secure processor configuration data stored in the ganged registers, since those register contents are not written out of memory during the switching process.

Thus, for example, since the monitor mode specific processor configuration data will specify the domain status bit to override the domain status bit that is not used in monitor mode, and in the preferred embodiment this has the same value as used in the secure domain, this indicates that the logic that selects which of the grouped CP15 registers to access will allow access to the secure grouped CP15 register. By allowing the monitor mode to use this secure processor configuration data as a relevant part of the monitor mode specific processor configuration data, a resource saving can be achieved, since it is no longer necessary to provide a separate register set for those items of the monitor mode specific processor configuration data.

FIG. 36 is a flowchart illustrating the steps performed by switching processor configuration data when a transition between one domain and another is required. As previously described, an SMI instruction is issued to cause a transition between domains. Therefore, at step 2020, an SMI instruction is awaited. Upon receiving the SMI instruction, the processor proceeds to step 2030, wherein the processor begins running the monitor program in monitor mode, causing the use of monitor mode specific processor configuration data in accordance with a control signal on path 2015 entered into multiplexer 2010 causing the multiplexer to switch to monitor mode specific processor configuration data. As previously mentioned, this can be a separate data set, or some portion can be derived from the secure processor configuration data stored in the banked register.

Thereafter, at step 2040, the current state is saved from the domain issuing the SMI instruction into memory, which includes saving the state of the processor configuration data associated with that domain from any shared CP15 registers. Typically, there is a portion of the memory that is set in addition to storing these states. Then, at step 2050, the state pointer is switched to the partial memory containing the corresponding state for the target domain. Thus, in general, there are two portions of memory allocated for storing state information, one allocated for storing state for the non-secure domain and one allocated for storing state for the secure domain.

Upon switching the state pointer at step 2050, the state pointed to by the state pointer is now loaded into the associated shared CP15 register at step 2060, which includes loading the configuration data for the target domain in the associated processor. Thereafter, at step 2070, the monitoring procedure is exited, as in monitoring mode, and the processor then switches to the desired mode in the target domain.

FIG. 37 illustrates in more detail the operation of the memory management logic 30 of one embodiment of the present invention. The memory management logic consists of a Memory Management Unit (MMU)200 and a Memory Protection Unit (MPU) 220. On path 234, any memory access requests issued by the core 10 specifying a virtual address are passed to the MMU200, and the MMU200 is responsible for performing predetermined access control functions, more specifically for determining the physical address corresponding to that virtual address, as well as for deciding access permissions and determining region attributes.

The memory system of the data processing apparatus is composed of a secure memory and a non-secure memory, the secure memory being used to store secure data for access only by the kernel 10, or one or more other master devices, when the kernel or other device is operating in a secure mode of operation, and correspondingly, in the secure domain.

In the embodiment of the invention shown in FIG. 37, attempted control of access to secure data in secure memory by an application running on the kernel 10 in non-secure mode is performed by a partition checker 222 within the MPU220, the MPU220 being managed by a secure operating system, also referred to herein as a secure kernel.

In accordance with a preferred embodiment of the present invention, a non-secure page table 58 is provided within a non-secure memory, such as a non-secure memory portion of the external memory 56, and is used to store a respective descriptor for each of a plurality of non-secure memory regions defined within that page table.

The descriptor contains information from which the MMU200 can derive the control information required to allow the MMU to perform the predetermined access control function, and therefore, in the embodiment described with reference to fig. 37, information will be provided regarding the virtual to physical address mapping, access permissions, and any region attributes.

Furthermore, in accordance with a preferred embodiment of the present invention, at least one secure page table 58 is provided within a secure memory of the memory system, such as a secure portion of the external memory 56, again providing associated descriptors for a plurality of memory regions defined within the table. When the processor is operating in a non-secure mode, the non-secure page table is referenced in order to obtain the relevant descriptors used in managing memory accesses, while when the processor is operating in a secure mode, descriptors from the secure page table will be used.

The descriptors are retrieved from the relevant page tables in the MMU as follows. In the case where a memory access request issued by the core 10 specifies a virtual address, a lookup is performed in the microTLB 206 that stores the corresponding physical address portion obtained from the associated page table for one of the plurality of virtual address portions. Thus, the microTLB 206 compares certain portions of the virtual address to corresponding virtual addresses stored in the microTLB to determine if there is a match. The portion compared is typically the most significant bits of some predetermined plurality of virtual addresses, the number of bits depending on the granularity of the page within the page table 58. The lookup performed within the microTLB 206 is typically relatively fast, as the microTLB 206 will only include a relatively small number of entries, such as eight entries.

In the event that no match is found in the microTLB 206, then on path 242, the memory access request is transferred to the main TLB208, which contains multiple descriptors obtained from the page table. As will be discussed in more detail later, descriptors from the non-secure page table and the secure page table can coexist in the main TLB208, and each entry within the main TLB has a corresponding tag (referred to as a main tag) that can be set to indicate whether the corresponding descriptor in that input has been obtained from the secure page table or the non-secure page table. In any embodiment where all secure modes of operation directly specify a physical address within their memory access request, it will be appreciated that this tag is not required within the main TLB, as the main TLB will only store non-secure descriptors.

Within the main TLB208, a similar lookup process is performed in order to determine whether the relevant portion of the virtual address issued within the memory access request corresponds to any of the portions of the virtual address associated with descriptors in the main TLB208 that are relevant to the particular mode of operation. Thus, if the core 10 is operating in a non-secure mode, only those descriptors within the main TLB208 that have been obtained from the non-secure page table will be checked, whereas if the core 10 is operating in a secure mode, only descriptors within the main TLB that have been obtained from the secure page table will be checked.

If there is a hit in the main TLB, as a result of that checking process, then the access control information is extracted from the relevant descriptor and passed back on path 242. In particular, on path 242, the virtual address portion and corresponding physical address portion of the descriptor are transferred to the microTLB 206 for storage in the entry of the microTLB, the access permissions are loaded into the access permissions logic 202, and the region attributes are loaded into the region attributes logic 204, either separate from the microTLB or may be included in the microTLB.

At this point, the MMU200 can then process the store request because there is now a hit within the microTLB 206. Thus, the microTLB 206 will generate a physical address, which is then output on path 238 onto the system bus 40 for transfer to an associated memory, which will be an on-chip memory, such as the TCM36, the cache 38, or the like, or one of the external memory locations accessible via the external bus interface 42. At this point, the access permission logic 202 will determine whether the memory access is permitted and, if it is determined that the core is not permitted to access a particular memory location in the current mode of operation, send an abort signal back to the core 10 on path 230. For example, when a kernel is operating in supervisor mode, certain memory portions, whether in secure or non-secure memory, may be designated as accessible only by that kernel, so if, while in user mode for example, the kernel 10 is attempting to access the memory location, the access permission logic 202 will detect that the kernel 10 does not currently have the appropriate access rights, and will issue an abort signal on path 230. This will result in the memory access being aborted. Finally, region attribute logic 204 will determine the region attributes for a particular memory access, such as whether the access is cacheable, etc., and will issue these signals on path 232, which will then be used to determine whether the data that is the subject of the memory access request can be cached, in the case of a write access, the write data can be buffered, etc., for example, within cache 38.

In the event of a miss in the main TLB208, then the relevant page table 58 is accessed using translation table walk logic (walklogic)210 to retrieve the required descriptor on path 248, and then that descriptor is passed to the main TLB208, on path 246, where it is stored. The base addresses for the non-secure page table and secure page table will be stored in registers 34 of CP15 and in registers of CP15 will also set the current domain, i.e. the secure domain or non-secure domain, in which the processor core 10 is operating, that domain state register being set by the monitor mode when a transition occurs between the non-secure domain and the secure domain, or vice versa. The contents of the domain status register are referred to herein as the domain bits. Thus, if a translation table walk process needs to be performed, the translation table walk logic 210 will know in which domain the kernel 10 is operating, and therefore, its base address is used to access the relevant table. The virtual address is then used as an offset to the base address to access the appropriate entry in the appropriate page table to obtain the desired descriptor.

Once the descriptor is retrieved by the translation table walk logic 210 and placed in the main TLB208, a hit is obtained in the main TLB and the previously described process is invoked to retrieve the access control information and store it in the micro TLB206, access grant logic 202, and region attribute logic 204. The memory access can then be acted upon by the MMU 200.

As previously mentioned, in the preferred embodiment, the main TLB208 is capable of storing descriptors from both secure page tables and non-secure page tables, but once relevant information is stored in the main TLB206, memory access requests are only handled by the MMU 200. In the preferred embodiment, the transfer of information between the main TLB208 and the microTLB 206 is monitored by a partition checker 222 located within the MPU220 to ensure that, in the event that the core 10 is operating in a non-secure mode, no access control information is transferred from descriptors within the main TLB208 to the microTLB 206, if this would result in the generation of a physical address within secure memory.

The memory protection unit is managed by a secure operating system that can be located within registers 34 of CP15, dividing information defining partitions between secure and non-secure memory. The partition checker 222 can then reference that partition information to determine whether access control information is being transferred to the microTLB 206, which, in a non-secure mode, allows the core 10 to access secure memory. More specifically, in the preferred embodiment, when the core 10 is in a non-secure mode of operation, as indicated by the domain bit set by the monitor mode within the CP15 domain status register, the partition checker 222 can monitor, via path 244, any portion of the physical address that is attempting to be restored from the main TLB208 into the microTLB 206 and determine whether the physical address generated for the virtual address based on that portion of the physical address is within secure memory. In this case, partition checker 222 will issue an abort signal on path 230 to core 10 to prevent a memory access from occurring.

It will be appreciated that, in addition, the partition checker 222 can be configured to actually prevent that physical address portion from being stored in the microTLB 206, or that the physical address portion is still within the microTLB 206, but that the abort process portion will remove that incorrect physical address portion from the microTLB 206, e.g., by flushing the microTLB 206.

Whenever the core 10 is in the monitor mode, the monitor mode will change the field value in the CP15 field status register to indicate that the processor's operation is changing into the field when changing between the unsecure mode and the secure mode of operation. As part of the inter-domain transfer process, the microTLB 206 will be flushed, so the translated first memory access between the secure and non-secure domains will generate a miss in the microTLB 206, and require that the access information be retrieved from the TLB208, either directly or via retrieving the associated descriptor from the associated page table.

In the above manner, it will be appreciated that the partition checker 222 will ensure that when the kernel is operating in a non-secure domain, a memory access abort will be generated if an attempt is made to restore access control information that allows access to secure memory to the microTLB 206.

If in any operating mode of processor core 10 the memory access request is configured to directly specify a physical address, then in that operating mode MMU200 will be disabled and the physical address will be communicated to MPU220 on path 236, and in a secure operating mode access permission logic 224 and region attribute logic 226 will perform the necessary access permission and region attribute analysis based on the access permission rights and region attributes identified for the corresponding region within partition information register 34 within CP 15. If the secure memory location being attempted to be accessed is located within a portion of secure memory that is accessible only in certain operating modes, e.g., secure privileged mode, then in a different operating mode, e.g., secure user mode, the kernel's access attempt will cause the access permission logic 224 to generate an abort to the kernel on path 230 in the same manner as the MMU's access permission logic 202 would generate an abort under these circumstances. Similarly, the region attribute logic 226 will generate cacheable and bufferable signals with the region attribute logic 204 of the MMU in the same manner as those signals that generate memory access requests specified by the virtual address. Assuming that access is allowed, the access request then enters on path 240 onto system bus 40, from which it is transferred to the appropriate memory location.

Non-secure access to the physical address specified by the access request, the access request is passed to partition checker 222, via path 236, which will reference the partition information in CP15 register 34, perform a partition check to determine if the physical address specifies a location in secure memory, in which case an abort signal will again be generated on path 230.

The processing of the above-described memory management logic will now be described in more detail with reference to the flow diagrams of fig. 39 and 40. FIG. 39 illustrates a scenario where a program running on the kernel 10 generates a virtual address, as shown in step 300. The relevant domain bit within the CP15 domain status register 34 set by the monitor mode will indicate whether the kernel is currently running in the secure domain or the non-secure domain. In the case where the kernel is running in the secure domain, processing branches to step 302 where a lookup is performed within the microTLB 206 to see if the relevant portion of the virtual address matches the virtual address portion within the microTLB 206. In the event of a hit in step 302, processing directly transfers to step 312 where the access permission logic 202 performs the necessary access analysis. At step 314, it is then determined whether there is an access permission violation and, if so, the process proceeds to step 316, where the access permission logic 202 issues an abort on path 230. Otherwise, in the absence of such an access permission violation, the process proceeds from step 314 to step 318, where a memory access is entered. In particular, the region attribute logic 204 will output the necessary cacheable and buffered attributes on path 232 and the microTLB 206 will issue a physical address on path 238, as previously described.

If at step 302 there is a miss in the microTLB, then at step 304, a lookup process is performed within the main TLB208 in order to determine whether the desired security descriptor is present in the main TLB. If not, then a page table walk process is performed at step 306, whereby the translation table walk logic 210 obtains the required descriptors from the secure page tables, as described with reference to FIG. 37. The process then proceeds to step 308, or directly from step 304 to step 308 in the event that a security descriptor already exists in the main TLB 208.

At step 308, it is determined that the main TLB now contains a secure descriptor of a valid tag, so the process proceeds to step 310, where the micro TLB is loaded with a sub-portion of the descriptor containing the physical address portion. Since the kernel 10 is currently running in secure mode, the partition checker 222 is not required to perform any partition checking functions.

The process then proceeds to step 312 where the remainder of the memory access is performed as previously described.

In the case of a non-secure memory access, the process transitions from step 300 to step 320 wherein a lookup process is performed within the microTLB 206 to determine whether the corresponding physical address portion from the non-secure descriptor exists. If so, processing transfers directly to step 336, where the access permissions are checked by the access permission logic 202. Note that at this point, if the relevant physical address is partially within the microTLB, it is assumed that there is no security violation, since the partition checker 222 effectively controls the information before it is stored in the microTLB, so that if the information is located within the microTLB, it is important to assume that it is appropriate non-secure information. Once the access permissions have been checked at step 336, the process proceeds to step 338 where a determination is made as to whether there are any violations, in either event, at step 316, an access permission abort is issued. Otherwise, processing proceeds to step 318, where the remainder of the memory access is performed, as previously described.

In the event of a miss in the microTLB, at step 320, processing proceeds to step 322, where a lookup process is performed in the main TLB208 to determine whether the relevant non-secure descriptor exists. If not, by the translation table walk logic 210, a page table walk process is performed at step 324 to restore the necessary non-secure descriptors from the non-secure page tables into the main TLB 208. Processing then proceeds to step 326 or, in the event that a command within the main TLB208 occurs at step 322, directly from step 322 to step 326. At step 326, it is determined that the main TLB now contains a valid tag non-secure descriptor for the virtual address, and then, at step 328, the partition checker 222 checks that the physical address (assuming the physical address portion within the descriptor) to be generated from the virtual address of the memory access request will specify a location in non-secure memory. If not, i.e., if the physical address points to a location in secure memory, then in step 330, a security violation is determined and the process proceeds to step 331, where a security/non-security failover is issued by the partition checker 222.

If, however, the partition checker logic 222 determines that there is no security violation, the process proceeds to step 334, where the microTLB is loaded with the subsection containing the associated descriptor of the physical address section, and then, at step 336, the memory access is processed in the manner previously described.

Now, the processing of a memory access request directly issuing a physical address is described with reference to fig. 40. As previously described, in this case, MMU200 would be deactivated, preferably by setting an MMU enable bit in the associated register of CP15 registers, which is accomplished by monitoring the mode. Therein, in step 350, the kernel 10 will generate the physical address passed into the MPU220 on path 236. Then, at step 352, the MPU verifies permissions to verify that the memory access being requested can handle the current mode of operation, i.e., user, supervisor, etc. Further, if the kernel is operating in a non-secure mode, the partition checker 222 will check if the physical address is in non-secure memory at step 352. Then, at step 354, it is determined whether there is a violation, i.e., whether the access permissions processing shows a violation, or if in non-secure mode, the partition checking process identifies a violation. If any of these violations occur, the process proceeds to step 356, where an access permission fault abort is generated by the MPU 220. It will be appreciated that in some embodiments there is no distinction between the two types of aborts, while in other embodiments the abort signal can indicate whether it relates to an access permission failure or a security failure.

If at step 354 a violation is not detected, the process proceeds to step 358 where a memory access to the cell identified by the physical address occurs.

In the preferred embodiment, the monitor mode is only configured to generate physical addresses directly, so in all other cases, the MMU200 will be active and the generation of physical addresses from the virtual addresses of the memory access requests will occur, as previously described.

FIG. 38 illustrates another embodiment of memory management logic where all memory access requests specify a virtual address, and thus, in any mode of operation, physical addresses are not generated directly. In this case, it will be appreciated that a separate MPU220 is not required, but rather a partition checker 222 is included in the MMU 200. This process is performed in the same manner as described with reference to fig. 37 and 39, except for this change.

It will be appreciated that various other options are also possible. For example, assuming that a memory access request is issued by both secure and non-secure modes specifying virtual addresses, two MMUs can be provided, one for secure access requests and one for non-secure access requests, i.e., the MPU220 in FIG. 37 can be replaced with a complete MMU. In these cases, it would not be necessary to use a tag and the main TLB of each MMU to define whether the descriptor is secure or non-secure, since one MMU stores the non-secure descriptor in its main TLB and the other MMU stores the secure descriptor in its main TLB. Of course, a partition checker is still needed to check if an attempt is being made to access secure memory while the kernel is in the non-secure domain.

In addition, if all memory access requests specify physical addresses directly, alternative implementations may use two MPUs, one for secure access requests and one for non-secure access requests. The MPU for the non-secure access request will have its access request controlled by the partition checker to ensure that in non-secure mode, access to secure memory is not allowed.

As another feature with either the FIG. 37 or FIG. 38 configurations, the partition checker 222 can be configured to perform some partition checks to manage the activity of the translation table walk logic 210. In particular, if the core is currently operating in a non-secure domain, the partition checker 222 can be configured to check that it is accessing a non-secure page table instead of a secure page table as long as the translation table walk logic 210 is attempting to access the page table. If a violation is detected, a abort signal is preferably generated. Since the translation table walk logic 210 typically performs a page table walk by combining the page table base address with certain bits of the virtual address issued by the memory access request, this partition checking may include, for example, checking that the translation table walk logic 210 is using the base address of the non-secure page table rather than the base address of the secure page table.

FIG. 41 schematically illustrates a process performed by the partition checker 222 when the kernel 10 is operating in a non-secure mode. It will be appreciated that in normal operation, the descriptors obtained from the non-secure page table will only describe pages mapped in non-secure memory. However, in the case of a software attack, the descriptor may be tampered with to now describe the portion of the memory that contains the non-secure and secure regions of memory. Thus, considering the example in FIG. 41, an unreliable insecure descriptor may cover a page that includes insecure regions 370, 372, 374 and secure regions 376, 378, and 380. If the virtual address issued as part of the memory access request corresponds to a physical address in a secure storage area, such as secure storage area 376 shown in FIG. 41, then partition checker 222 is configured to generate an abort to prevent the access from occurring. Thus, even if the non-secure descriptor is corrupted in an attempt to access secure memory, the partition checker 222 may prevent access from occurring. In contrast, if the physical address derived using the descriptor corresponds to a non-secure memory region, such as the region 374 shown in FIG. 41, the access control information loaded into the microTLB 206 only identifies the non-secure region 374. Thus, access within the non-secure storage area 374 will occur, but access to any of the secure areas 376, 378, or 380 will not occur. Thus, it can be seen that even though the main TLB208 may contain descriptors from non-secure page tables that have been tampered with, the microTLB will contain only the portion of the physical address that will allow access to the non-secure memory region.

As previously described, in embodiments where a memory access request specifying a virtual address may be generated in a non-secure mode or a secure mode, then the memory preferably includes a non-secure page table within the non-secure memory, and a secure page table within the secure memory. When in non-secure mode, the non-secure page table will be referenced by the translation table walk logic 210, while when in secure mode, the secure page table will be referenced by the translation table walk logic 210. FIG. 42 illustrates these two page tables. As shown in FIG. 42, non-secure memory 390, which may be located, for example, in external memory 56 of FIG. 1, includes therein a non-secure page table 395 specified in CP15 register 34 by reference to a base address 397. Similarly, in secure memory 400, also located within external memory 56 of fig. 1, there is provided a corresponding secure page table 405 specified within dedicated CP15 register 34 by way of a secure page table base address 407. Each descriptor of the non-secure page table 395 will point to a corresponding non-secure page in the non-secure memory 390, while each descriptor within the secure page table 405 will define a corresponding secure page in the secure memory 400. In addition, as will be described in more detail later, for certain areas of memory, the memory area 410 may be shared that is accessible by both the non-secure mode and the secure mode.

FIG. 43 illustrates in more detail the lookup process performed within the main TLB208, according to a preferred embodiment. As previously described, the main TLB208 includes a security label 425 that identifies whether the corresponding descriptor is from a secure page table or a non-secure page table. This ensures that when the lookup process is performed, only the descriptors relating to the particular domain in which the core 10 is operating will be checked. FIG. 43 illustrates an example of a kernel running in a secure domain, also referred to as a secure domain. As can be seen from FIG. 43, when a main TLB208 lookup is performed, this will result in ignoring the descriptor 440, and only the descriptor 445 will be identified as a candidate for the lookup process.

According to a preferred embodiment, a further process ID tag 430, also referred to herein as ASID tag, is provided to identify descriptors from the process specific page table. Thus, processes P1, P2, and P3, respectively, may have respective page tables provided within memory, and additionally may have different page tables for non-secure and secure operations. In addition, it will be appreciated that processes P1, P2, and P3 in the secure domain may completely separate processes from processes P1, P2, and P3 in the non-secure domain. Thus, as shown in FIG. 43, in addition to checking the domain when a main TLB lookup 208 is required, the ASID tag is also checked.

Thus, in the example of FIG. 43, where in the secure domain, process P1 is performed, the lookup process identifies exactly two entries 450 within the main TLB208, and then generates a hit or miss depending on whether the portions of the virtual address within those two descriptors match the corresponding portions of the virtual address issued by the memory access request. If so, then the relevant access control information is extracted and passed to the microTLB 206, access grant logic 202, and region attribute logic 204. Otherwise, a miss occurs, and translation table walk logic 210 is used to restore the required descriptors from the page table provided for the security process P1 to the main TLBA 208. As will be appreciated by those skilled in the art, there are many techniques for managing the contents of the TLB, and thus, when a new descriptor stored in the main TLB208 is retrieved, the main TLB is full, any of a number of known techniques may be used to determine which descriptor to evict from the main TLB to make room for the new descriptor, such as a recently used method, and so forth.

It will be appreciated that the security kernel used in the secure mode of operation may be developed completely separate from the non-secure operating system. However, in some cases, the development of secure kernels and non-secure operating systems may be tightly coupled, and in these cases it may also be appropriate to allow secure applications to use non-secure descriptors. Indeed, this allows the secure application to directly access the non-secure data (for sharing) by only knowing the virtual address. Of course, this assumes that the secure virtual mapping and the non-secure virtual mapping are mutually exclusive for a particular ASID. In these cases, the previously introduced marker to distinguish between secure and non-secure descriptors (i.e., a domain marker) would not be needed. Then, a lookup in the TLB is performed through all available descriptors.

In the preferred embodiment, the choice between the configuration of the main TLB and the previously described configuration with separate secure and non-secure descriptors can be set by specific bits provided in the CP15 control registers. In the preferred embodiment, this bit is set only by the security kernel.

In embodiments that directly allow secure applications to use non-secure virtual addresses, it will be possible to obtain a non-secure stack pointer from the secure domain. This can be accomplished by copying the non-secure register value identifying the non-secure stack pointer to a special purpose register within CP15 register 34. This would then allow the non-secure application to pass parameters through the stack, according to a scheme understood by the secure application.

As previously described, the memory may be partitioned into non-secure and secure portions, and the partition controlled using CP15 register 34 dedicated to partition checker 222. The basic partitioning method is based on zone access permissions as defined in typical MPU devices. Thus, the memory is divided into regions, and each region is preferably defined by its base address, size, memory attributes, and access permissions. In addition, when a coverage area is programmed, the attributes of the previous area get the highest priority. Further in accordance with a preferred embodiment of the present invention, a new region attribute is provided to define whether the corresponding region is located in secure memory or non-secure memory. The new region attribute is used by the security kernel to define the portion of memory to be protected as secure memory.

In the boot phase, as shown in FIG. 44, a first partition is performed. This initial partition will define the amount of memory 460 allocated to the insecure area, the insecure operating system and the insecure application. The amount corresponds to the non-secure zone defined in the partition. This information is then used by the insecure operating system for its memory management. The remaining portions of memory 462, 464 defined as secure are not known to the non-secure operating system. To protect integrity in the unsecure region, the unsecure memory is programmed with access permissions only for the secure privileged mode. Thus, the secure application will not damage the non-secure application. As seen from fig. 44, after this boot phase partitioning, memory 460 is available for use by the non-secure operating system, memory 462 is available for use by the secure kernel, and memory 464 is available for use by the secure application.

Once the boot phase partition is executed, the memory map of the non-secure memory 460 is processed by the non-secure operating system using the MMU200, and thus a series of non-secure pages can be defined in a conventional manner. This is shown in fig. 45.

If the secure application needs to share memory with the non-secure application, the secure kernel can change the rights of the memory portion in order to manually transfer data from one domain to another. Thus, as shown in FIG. 46, after checking the integrity of an unsecure page, the security kernel changes the rights of that page so that it becomes a secure page 466 accessible to the shared memory.

The microTLB 206 needs to be flushed after the partition of the memory has changed. Thus, in this case, when an unsecure access occurs sequentially, a miss will occur in the microTLB 206, and thus, a new descriptor will be loaded from the main TLB 208. When attempting to restore it into the microTLB 206, the new descriptor is sequentially checked by the MPU's partition checker 222, and will therefore be consistent with the new partition of memory.

In the preferred embodiment, the cache 38 is virtually indexed and physically tagged. Thus, when an access is performed in the cache 38, a lookup will first be performed in the microTLB 206, and thus access permissions, in particular security and non-security permissions, are checked. Thus, secure data cannot be stored in the cache 38 by non-secure applications. Access to the cache 38 is under control of partition checks performed by the partition checker 222, and thus, in the non-secure mode, access to secure data cannot be performed.

However, one problem that can occur is that applications in the non-secure domain can use the cache operation register to invalidate, flush or flush the cache. It is necessary to ensure that these operations will not affect the security of the system. For example, if a non-secure operating system wants to invalidate cache 38, rather than clean it, any secure bad data must be written to external memory before replacement. Preferably, the secure data is tagged in the cache so that it can be handled differently if desired.

In the preferred embodiment, if the "invalidate line by address" operation is performed by a non-secure program, the physical address is checked by the partition checker 222, and if the cache line is a secure cache line, the operation becomes a "clean and invalidate" operation, thereby maintaining the security of the system. In addition, in the preferred embodiment, all "invalidate line by index" operations performed by the non-secure program change to "clear and invalidate by index" operations. Similarly, all "invalidate all" operations performed by a non-secure program become "clear and invalidate all" operations.

Further, referring to FIG. 1, any access to the TCM36 through the DMA32 is controlled by the microTLB 206. Thus, when DMA32 performs a lookup in the TLB to translate its virtual address to a physical address, the previously described tag that has been added to the main TLB allows the required security checks to be performed, just as the access request has been issued by kernel 10. In addition, as will be described later, a copy partition checker is coupled to the external bus 70, preferably in the arbiter/decoder block 54, to check the validity of accesses connected to the external bus if the DMA32 directly accesses memory coupled to the external bus 70 via the external bus interface 42. Furthermore, in some preferred embodiments, whether the DMA controller 32 can be used in the non-secure domain can be defined by adding a bit to the CP15 register 34 that only allows setting by the secure kernel when operating in the privileged mode.

Considering the TCM36, if secure data is located in the TCM36, this must be handled with care. For example, one can imagine a situation where a non-secure operating system programs a physical address range for TCM memory 36 so that it covers an external secure memory portion. If the operating mode changes to the secure mode, the secure kernel may cause data to be stored in that overlay portion, typically in TCM36, because TCM36 typically has a higher priority than external memory. If the non-secure operating system changes the settings for the physical address space of the TCM36 in order to map the previous secure area in the non-secure physical area of memory, it will be appreciated that the non-secure operating system can access the secure data because the partition checker treats the area as non-secure and will not assert abort. Thus, to summarize, if the TCM is configured to act as a conventional local RAM and not as a smart cache, the non-secure operating system may read secure region data if it can move TCM base registers to non-secure physical addresses.

To prevent this, in the preferred embodiment, a control bit is provided within the CP15 register 34 that is accessible only in the secure privileged mode of operation, as well as providing two possible configurations. In a first configuration, the control bit is set to "1", in which case the TCM can only be controlled by the security privilege mode. Thus, any attempted unsecure access to TCM control registers within CP1534 will cause an input undefined instruction exception. Thus, in this first embodiment, secure and non-secure modes enable the use of TCM, but TCM is controlled only by the secure privileged mode. In this second configuration, the control bit is set to "0", in which case the TCM is controlled by the unsecure operating system. In this case, the TCM is used only by non-secure applications. Any secure data cannot be stored or loaded from the TCM. Thus, when performing secure access, no lookup is performed within the TCM to see if the address matches the TCM address range.

By default, it is contemplated that the TCM is used only by the non-secure operating system, since in this case, no changes to the non-secure operating system are required.

As previously described, in addition to providing the partition checker 222 within the MPU220, the preferred embodiment of the present invention also provides a similar partition checker block coupled to the external bus 70, which additional partition checker serves to manage memory access by other masters, such as a Digital Signal Processor (DSP)50, a DMA controller 52 coupled directly to the external bus, a DMA controller 32 connectable to the external bus via the external bus interface 42, and the like. Indeed, in some embodiments, as described later, there may be only a partition parity block coupled to the external (or device) bus, and no partition checker provided as part of the memory management logic 30. In some such embodiments, a partition checker may optionally be provided as part of the memory management logic 30, which in these instances can be considered another partition checker provided in addition to being coupled to the device bus.

As previously mentioned, the overall memory system can be made up of several memory units, and a number of these memory units may reside on external bus 70, such as external memory 56, boot ROM44, or the actual buffers or registers 48, 62, 66 within peripheral devices such as screen driver 46, I/O interface 60, key storage unit 64, and so forth. In addition, different portions of the memory system need to be defined as secure memory, for example, it may be desirable for the key buffer 66 within the key storage unit 64 to be treated as secure memory. If a device coupled to the external bus attempts to access the secure memory, it will be apparent that the previously described memory management logic 30 within the chip contained in the core 10 will not be able to manage the access.

FIG. 47 illustrates how an additional partition checker 492 coupled to an external bus, also referred to herein as a device bus, may be used. The external bus is typically configured so that whenever memory access requests are sent to that external bus by a device, such as devices 470, 472, those memory access requests also include certain signals on the external bus that define the mode of operation, e.g., privileged, user waiting. According to a preferred embodiment of the present invention, the memory access request further comprises sending a domain signal onto the external bus to identify whether the device is operating in a secure mode or an unsecure mode. The domain signal is preferably issued at the hardware level and in a preferred embodiment, a device capable of operating in either the secure or non-secure domain will include a predetermined pin for outputting the domain signal on path 490 within the external bus. This path 490 is shown separately from other signal paths 488 on the external bus for illustrative purposes.

This domain signal, also referred to herein as the "S bit," will identify whether the device issuing the memory access request is operating in the secure domain or the non-secure domain, and this information is received by the partition checker 492, which is coupled to the external bus. Partition checker 492 also accesses partition information identifying the storage area as secure or non-secure and, therefore, can be configured to only allow the device to access the secure portion of memory if it is asserted that the S bit identifies the secure mode of operation.

By default, it is contemplated that the S bit will not be asserted, and thus, pre-existing non-secure devices, such as device 472 shown in FIG. 47, will not output an asserted S bit, and thus, partition checker 492 will never be guaranteed to access any secure portion of memory, whether within registers or buffers 482, 486 of screen driver 480, I/O interface 484, or external memory 474.

For ease of illustration, arbiter block 476, which is used to arbitrate between memory access requests issued by a master device, such as devices 470, 472, is illustrated separately from decoder 478, which is used to determine the appropriate memory device to service the memory access request, and from partition checker 492. However, it will be appreciated that one or more of these components may be integrated in the same unit if desired.

FIG. 48 illustrates a further embodiment in which no partition checker is provided. Instead, each memory device 474, 480, 484 is configured to manage its own memory access according to the S-bit value. Thus, if the device 470 wants to make a memory access request to a register 482 within the screen driver 480 that is marked as secure memory in the non-secure mode, then the screen driver 480 determines that the S bit is not asserted and does not process the memory access request. Thus, it is contemplated that by appropriate design of the various memory devices, the need to separately provide partition checkers 492 on the peripheral bus may be avoided.

In the above description of fig. 47 and 48, the "S bit" identifies whether the device issuing the memory access request is operating in the secure domain or the non-secure domain. Looking at another approach, the S bit can be considered to indicate whether the memory access request belongs to a secure domain or a non-secure domain.

In the embodiment described with reference to FIGS. 37 and 38, the translation of virtual addresses to physical addresses is performed using a single MMU and a single set of page tables. In this way, the physical address space is typically segmented between the non-secure memory and the secure memory in a simple manner, as shown in FIG. 49. Where the physical address space comprises an address space starting at address 0 and extending to address Y for one memory location within the memory system, e.g., external memory 56. For each memory unit, the addressable memory is typically divided into two portions, a first portion 2110 allocated as non-secure memory and a second portion 2120 allocated as secure memory.

In this way, it will be appreciated that there are certain physical addresses that cannot be accessed by a particular domain, and that these differences are apparent to the operating system used in those domains. Whilst an operating system used in the secure domain will know the non-secure domain, so it will not be of concern that an operating system in the non-secure domain will theoretically not need to know that a secure domain exists, but instead should operate as if a secure domain does not exist.

As a further problem, it will be appreciated that the non-secure operating system sees the address space for the external memory as starting with address 0 and extending to address X, and that the non-secure operating system does not know anything of the secure kernel, in particular there is secure memory extending from address X +1 to address Y. In contrast, the security kernel will not see the address space starting from address 0, which is not normally desired by operating systems.

One embodiment that avoids the above-described problems by allowing secure hiding of the secure storage area from the view of the insecure operating system of its physical address space, and by allowing the secure kernel in the secure domain and the insecure operating system in the insecure domain to see their address spaces for external memory as starting from address 0 is schematically illustrated in FIG. 51. Physical address space 2200 can be divided into secure or non-secure segments in page groups, among others. In the example shown in fig. 51, the address space for the external memory is shown divided into four parts 2210, 2220, 2230, and 2240, consisting of two secure memory areas and two non-secure memory areas.

Instead of a translation between a virtual address space and a physical address space via a single page table translation, two separate address layer translations are performed with reference to a first page table and a second page table, allowing the introduction of the notion of an intermediate address space that is differently configured depending on whether the processor is in a secure domain or a non-secure domain. More specifically, as shown in fig. 51, two secure storage areas 2210 and 2230 in a physical address space can be mapped to a single area 2265 in an intermediate address space for a secure domain by using descriptors provided within a secure page table in a page table set 2250. Regarding the operating systems involved running on the processors, the intermediate address space is considered a physical address space, and the MMU is used to translate virtual addresses to intermediate addresses within the intermediate address space.

Similarly, for a non-secure domain, an intermediate address space 2270 can be configured in which two non-secure storage areas 2220 and 2240 in the physical address space are mapped to a non-secure area 2275 in the intermediate address space for the non-secure domain via corresponding descriptors in non-secure page tables within page table set 2250.

In one embodiment, two separate MMUs are used to process the intermediate addresses to translate virtual addresses to physical addresses, as shown in FIG. 50A, and each of the MMUs 2150 and 2170 in FIG. 50A can be considered to be constructed in a similar manner to the MMU200 shown in FIG. 37, but certain details are omitted from FIG. 50A for ease of illustration.

The first MMU2150 includes a microTLB 2155, a main TLB2160, and translation table walk logic 2165, and similarly, the second MMU2170 includes a microTLB 2175, a main TLB2180, and translation table walk logic 2185. The first MMU is controlled by the unsecure operating system when the processor is operating in the unsecure domain or by the secure core when the processor is operating in the secure domain. However, in the preferred embodiment, the second MMU could only be controlled by the security kernel or monitor.

When processor core 10 issues a memory access request, the virtual address is sent to microTLB 2155 on path 2153. The microTLB 2155 will store respective intermediate address portions for the plurality of virtual address portions retrieved from descriptors stored within the main TLB2160, descriptors in the main TLB2160 that have been retrieved from the first set of page tables associated with the first MMU 2150. If a hit is detected in microTLB 2155, microTLB 2155 will send an intermediate address on path 2157 that corresponds to the virtual address received on path 2153. If there is no hit in microTLB 2155, main TLB2160 will be referenced to see if a hit is detected within the main TLB, and if so, the relevant virtual address portion and corresponding intermediate address portion are restored into microTLB 2155, and the intermediate address is then sent on path 2157.

If there is no hit in the microTLB 2155 and main TLB2160, translation table walk logic 2165 is used to send a request for the desired descriptor from a predetermined page table in a first set of page tables accessible by the first MMU 2150. Typically there are page tables associated with a single processor for either the secure domain or the non-secure domain, and intermediate base addresses for those page tables are accessible by translation table walk logic 2165, e.g. from appropriate registers within CP15 registers 34. Thus, translation table walk logic 2165 can send an intermediate address on path 2167 in order to request descriptors from the appropriate page tables.

A second MMU2170 is configured on path 2157, by microTLB 2155, or on path 2167, to receive any intermediate addresses output by translation table walk logic 2165, and if a hit is detected within microTLB 2175, then on path 2192 the microTLB sends the required physical address to memory in order to retrieve the required data on data bus 2190. In the case of an intermediate address sent on path 2157, this will result in the required data being returned to the core 10, while for an intermediate address sent on path 2167, the required descriptor will be returned to the first MMU2150 for storage in the main TLB 2160.

In the event of a micro TLB2175 miss, the main TLB2180 will be referenced, and if there is a hit within the main TLB, the desired intermediate address portion and corresponding physical address portion are returned to the micro TLB2175, which then allows the micro TLB2175 to send the desired physical address on path 2192. However, in the event of a miss in either the micro-TLB 2175 or the main TLB2170, then the translation table walk logic 2185 is configured to output on path 2194 the relevant page table from within the second set of page tables associated with the second MMU2170, requesting the desired descriptor. The second set of page tables includes descriptors associating intermediate address portions with physical address portions, there typically being at least one page table for the secure domain and one page table for the non-secure domain. When a request is issued on path 2194, the relevant descriptors from the second set of page tables will be caused to be returned to the second MMU2170 for storage within the main TLB 2180.

The operation of the embodiment shown in fig. 50A is now further illustrated by the specific example described below, where the abbreviation VA denotes a virtual address, IA denotes an intermediate address, and PA denotes a physical address.

1) The kernel sends out VA 3000 [ IA5000, PA7000 ]

2) Misses in the micro-TLB of MMU1

3) Misses in the main TLB of MMU1

Page table 1 base address 8000IA PA 10000

4) Translation table walk logic in MMU1 performs a page table walk-issue IA 8003

5) Misses in the micro-TLB of MMU2

6) Misses in the main TLB of MMU2

Page table 2 base 12000PA

7) Translation table walk logic in MMU2 performs a page table walk-issue PA 12008 "8000 IA 10000 PA" back as page table data

8) Stored in the main TLB of MMU2

9) Stored in the micro TLB of MMU2

10) The microtlb in MMU2 now hits-issues PA 10003 "3000 VA" 5000IA "back as page table data

11) Stored in the main TLB of MMU1

12) Stored in the micro TLB of MMU1

13) The microtlb in MMU1 now hits-issues IA5000 to perform the data access

14) Misses in the micro-TLB of MMU2

15) Misses in the main TLB of MMU2

16) Translation table walk logic in MMU2 performs a page table walk-issuing PA 12005 "5000 IA 7000 PA" back as page table data

17) Stored in the main TLB of MMU2

18) Stored in the micro TLB of MMU2

19) The microTLB in MMU2 now hits-issues PA7000 to perform the data access

20) Data at physical address 7000 is returned to the kernel

The next time the kernel issues a memory access request (assuming a VA3001.)

1) 3001 for kernel sending out VA

2) On a hit in the microTLB of MMU1, the request is sent to IA5001 of MMU2

3) Command in micro TLB of MMU2, request PA7001 sent to memory

4) Data returned to the PA7001 of the core.

It will be appreciated that in the above example, misses occur in the micro-TLB and main TLB of both MMUs, and therefore, this example represents a "worst case" scenario. Typically, it is desirable to observe a hit in at least one of the micro-TLB or the main TLB, thereby significantly reducing the time taken to retrieve data.

Returning to FIG. 51, a second set 2250 of page tables is typically provided in some region of the physical address space, in the preferred embodiment a secure region. The first set of page tables is divided into two categories, named secure page tables and non-secure page tables. Preferably, the secure page tables will appear contiguously within the intermediate address space 2265, as if the non-secure page tables were located in the non-secure intermediate address space 2275. However, they need not be located contiguously in the physical address space, so for example, the secure page tables for the first set of page tables are distributed across the secure regions 2210, 2230, and in a similar manner the non-secure page tables may be distributed across the non-secure storage regions 2220 and 2240.

As previously mentioned, one major benefit of the two-level approach using two sets of page tables is that the physical address space can be configured to start with 0 for both the operating system of the secure domain and the operating system of the non-secure domain, which is generally desirable for operating systems. In addition, the secure storage area can be completely hidden from view of the non-secure operating system of its "physical address" space, since the intermediate address space is treated as its physical address space, which can be configured with a continuous sequence of intermediate addresses.

In addition, using this approach greatly simplifies the process of swapping memory areas between unsecure memory and secure memory. This is illustrated schematically with reference to fig. 52. As seen in fig. 52, memory area 2300, which is, for example, a single memory page, may reside in non-secure memory area 2220, and similarly, memory area 2300 may reside in secure memory area 2210. However, the two storage areas 2300 and 2310 can be easily swapped simply by swapping the relevant descriptors within the second set of page tables so that area 2300 now becomes the secure area mapped to area 2305 in the secure area's intermediate address space and area 2310 can become the non-secure area mapped to area 2315 in the non-secure area's intermediate address space. Complete transparency occurs to operating systems in the secure domain and the non-secure domain because their views of physical address space are effectively intermediate address spaces of the secure domain or the non-secure domain, respectively. Thus, the method avoids redefining the physical address space within each operating system.

Another embodiment of the present invention using two MMUs, different from the configuration of FIG. 50A, is now described with reference to FIG. 50B. As can be seen from a comparison of fig. 50B and 50A, the configuration is almost the same, but in this embodiment the first MMU2150 is configured to perform virtual to physical address translations and the second MMU is configured to perform intermediate to physical address translations. Thus, instead of path 2157 from microTLB 2155 in first MMU2150 to microTLB 2175 in second MMU2170 used in the embodiment of FIG. 50A, microTLB 2155 in the first MMU is configured to output physical addresses directly on path 2192, as shown in FIG. 50B. The operation of the embodiment shown in FIG. 50B is now illustrated by the specific example shown below, which details the processing of the same kernel memory access request, as previously described for the FIG. 50A embodiment.

1) The kernel sends out VA 3000 [ IA5000, PA7000 ]

2) Misses in the micro-TLB and main TLB of MMU1

Page table 1 base address 8000IA PA 10000

3) Translation table walk logic in MMU1 performs a page table walk-issue IA 8003

4) Misses in the micro-TLB and main TLB of MMU2

Page table 2 base 12000PA

5) Translation table walk logic in MMU2 performs a page table walk-issue PA 12008 "8000 IA 10000 PA" back as page table data

6) -8000 IA 10000PA mappings stored in main and micro TLB of MMU2

7) The microTLB in MMU2 can now translate the request from step (3) into PA1003 and issue a fetch "3000 VA-5000 IA" back as page table data

Note that: the translation is retained in temporary memory by the MMU1, but is not stored directly in any TLB.

8) The translation table walk logic in the MMU1 now issues a request to the MMU2 for IA5000

9) IA5000 misses in the uTLB and main TLB of MMU2

10) Translation table walk logic in MMU2 performs a page table walk-issuing PA 12005 "5000 IA 7000 PA" back as page table data

11) The MMU2 stores "5000 IA 7000 PA" in the uTLB and main TLB. The translation is also passed to MMU 1.

12a) MMU2 issues PA7000 memory access

12b) The MMU1 combines the "3000 VA-5000 IA" and "5000 IA-7000 PA" descriptors to give a "3000 VA-7000 PA" descriptor, which is stored in the main TLB and the micro TLB of the MMU 1.

13) Returning data at PA7000 to kernel

The next time the kernel issues a memory access request (assuming a VA3001.)

1) 3001 for kernel sending out VA

2) On a hit in the microTLB of MMU1, MMU1 issues a PA7001 request

3) The data at the PA7001 is returned to the core.

As can be seen from a comparison of the above example with that provided in FIG. 50A, the main difference is in step 7, where the MMU1 does not directly store the first table descriptor, and in step 12b (12a and 12b can occur simultaneously), where the MMU1 also receives the IA- > PA translation and joins and stores the combined descriptors in its TLBs.

Thus, it can be seen that while this alternative embodiment still uses two sets of page tables to translate virtual addresses to physical addresses, the fact that microTLB 2155 and main TLB2160 store direct virtual-to-physical address translations avoids the need to perform lookups in both MMUs when a hit is made in microTLB 2155 or main TLB 2160. In these cases, the first MMU can directly handle requests from the kernel without reference to the second MMU.

It will be appreciated that the second MMU2170 can be configured to not include both the micro-TLB 2175 and the main TLB2180, in either case, the page table walk logic 2185 will be used for each request that needs to be processed by the second MMU. This may save the complexity and cost of the second MMU to an acceptable level, given that the second MMU is not required very frequently. Since the first MMU is required for each request, it is often advantageous to include micro-TLB 2155 and main TLB2160 in the first MMU2150 in order to increase the operating speed of the first MMU.

It should be noted that pages in the page table may change size, so the descriptors for the two halves of the translation are associated with pages of different sizes. Typically, the MMU1 page will be smaller than the MMU2 page but this is not necessarily so. For example:

table 1 maps 4Kb at 0x40003000 to 0x00081000

Table 2 maps 1Mb at 0x00000000 to 0x02000000

Where the smallest of the two sizes must be used for the combining transformation, the combination descriptor is therefore

Mapping 4Kb at 0x400030000 to 0x 02081000.

However, where data is exchanged between regions (as previously described with reference to FIG. 52), the reverse is possible, for example:

table 1 maps 1Mb at 0xc0003000 to 0x00000000

Table 2 maps 4Kb at 0x00042000 to 0x02042000

Now, the mapping is given from the kernel lookup at address 0xc 0042010:

mapping 4Kb at 0xc00420000 to 0x02042000

I.e. the smaller of the two sizes is always used for combining the mappings

Note that in the second case, the processing efficiency is low because the (1Mb) descriptor in table 1 will be repeatedly looked up and discarded because a different 4Kb region is accessed. However, in a typical system, the table 2 descriptor would be larger (as in the first example), and most of the time more efficient (1Mb mapping could be recycled for other 4Kb pages pointing to the appropriate IA space portion).

As an alternative to employing two separate MMUs, as shown in FIGS. 50A and 50B, a single MMU can be used, as shown in FIG. 53, where an exception is raised by the MMU upon a miss in the main TLB2420, and then software is run in the kernel 10 to generate the virtual to physical address translation based on a combination from two different sets of page tables. More specifically, as shown in FIG. 53, the core 10 is coupled to an MMU2400, which includes a micro TLB2410 and a main TLB 2420. When the core 10 issues a memory access request, the virtual address is provided on path 2430, and if a hit is found in the microTLB, the corresponding physical address is output directly on path 2440, so that the data is returned back into the core 10 on path 2450. However, if there is a miss in the microTLB 2410, the main TLB2420 is referenced and the associated virtual address portion and corresponding physical address portion are restored to the microTLB 2410 if the associated descriptor is contained in the main TLB, after which the physical address is sent on path 2440. However, if the main TLB also generates a miss, on path 2422 an exception is generated to the core. The process performed in the kernel from receiving this exception will now be described further in connection with FIG. 54.

As shown in FIG. 54, if a TLB miss is detected by the kernel in step 2500, then in step 2510, the kernel enters monitor mode with a predetermined vector for that exception. This will therefore result in the running of the page table merge code to perform the remaining steps shown at 54.

More specifically, the virtual address sent on path 2430 and causing the miss in the microTLB 2410 and main TLB2420 (hereinafter referred to as the faulting virtual address) is retrieved at step 2520, after which an intermediate address for the desired first descriptor is determined at step 2530 from the intermediate base address for the appropriate table within the first set of tables. Once the intermediate address has been determined (typically by some predetermined combination of virtual address and intermediate base address), the relevant tables within the second set of tables are consulted to obtain the corresponding physical address for the first descriptor. Thereafter, at step 2550, the first descriptor can be fetched from memory to allow determination of an intermediate address for the failed virtual address.

Then, at step 2560, the second table is referenced again for a second descriptor of the physical address giving the intermediate address for the failed virtual address. Thereafter, at step 2570, a second descriptor is extracted to obtain a physical address for the failed virtual address.

Once the above information has been obtained, the program merges the first and second descriptors to generate a new descriptor that provides the required virtual address to the physical address translation, which is performed at step 2580. In a similar manner as previously described with reference to FIG. 50B, merging is performed by software to reuse the minimum page table size for joint combining. Thereafter, at step 2590, the new descriptor is stored in the main TLB2420, after which the process returns due to an exception at step 2595.

Thereafter, the core 10 will be configured to reissue the virtual address for the memory access request on path 2430, which will still result in a miss in the main TLB2410, but now a hit in the main TLB 2420. Thus, the virtual address portion and corresponding physical address portion can be restored into the microTLB 2410, after which the microTLB 2410 can send the physical address on path 2440, producing the required data that is returned to the core 10 on path 2450.

It will be appreciated that as an alternative to the embodiments previously described with reference to figures 50A and 50B, one or both MMUs in those embodiments can be managed by software using the principles described with reference to figures 53 and 54.

Regardless of whether two MMUs are used, as shown in FIG. 50A or 50B, or one MMU is used, as shown in FIG. 53, the fact that the second set of page tables is managed by the processor when operating in monitor mode (or in privileged secure mode) ensures that those page tables are secure. Thus, when the processor is in the non-secure domain, only the non-secure memory is visible because when in the non-secure domain, it is only the intermediate addresses generated for the non-secure domain by the second set of page tables that the processor can see. Thus, there is no need to provide a partition checker as part of the memory management logic 30 shown in FIG. 1. However, a partition checker is still provided on the external bus to monitor accesses by other bus masters in the system.

In the previous embodiment with reference to FIGS. 37 and 38, a partition checker 222 is provided in connection with the MMU200, and therefore, when an access is performed in the cache 38, a lookup will have first been performed in the microTLB 206, and therefore, checking access permissions, particularly security and non-security permissions, may have been completed. Thus, in these embodiments, secure data cannot be stored in the cache 38 by non-secure applications. Access to the cache 38 is under control of the partition checks performed by the partition checker 222, and thus, in the non-secure mode, access to the secure data cannot be performed.

However, in an alternative embodiment of the present invention, the partition checker 222 for monitoring accesses on the system bus 40 is not provided, but rather the data processing apparatus has only a single partition checker coupled to the external bus 70 for monitoring accesses to memory units connected to that external bus. In these embodiments, this means that the processor core 10 can access any memory units directly coupled to the system 40, such as the TCM36 and the cache 38, while those accesses are not controlled by an external partition checker, and therefore some mechanism is required to ensure that the processor core 10 does not access secure data within the cache 38 or TCM36 when operating in a non-secure mode.

FIG. 55 illustrates a data processing apparatus according to one embodiment of the present invention, providing a mechanism to allow cache 38 and/or TCM36 to control access to them without the need to provide any partition checking logic associated with MMU 200. As shown in FIG. 55, core 10 is coupled to system bus 40 via MMU200, as well as cache 38 and TCM36 coupled to system bus 40. The core 10, cache 38 and TCM36 are coupled via an external bus interface 42 to an external bus 70, shown in FIG. 55, consisting of an address bus 2620, a control bus 2630 and a data bus 2640.

Core 10, MMU200, cache 38, TCM36, and external bus interface 42 can be viewed as constituting a single device connected to external bus 70, also referred to as a device bus, to which other devices may also be coupled, such as secure peripherals 470 or non-secure peripherals 472. Also connected to the device bus 70 are one or more memory units, such as an external memory 56. In addition, a bus control unit 2650 is also connected to the device bus 70 and generally includes an arbiter 2652, a decoder 2654, and a partition checker 2656. For a general discussion of the operation of the components connected to the device bus, reference should be made to FIG. 47, previously described. In the previously described FIG. 47, the arbiter, decoder, and partition checker are illustrated as separate modules, but these elements operate in the same manner when located in a single control block 2650.

In FIG. 56, the MMU200 of FIG. 55 is illustrated in greater detail. From a comparison of FIG. 56 and FIG. 37, it can be seen that the MMU200 is constructed in exactly the same manner as the MMU of FIG. 37, with the sole difference that no partition checker 222 is provided for monitoring data sent on path 242 between the main TLB208 and the microTLB 206. If the processor core 10 issues a memory access request specifying a virtual address, the memory request is routed via the MMU200, processed as described with reference to FIG. 37, to generate a physical address output on path 238 from the microTLB 206 on the system bus 40. Conversely, if the memory access request directly specifies a physical address, MMU200 is bypassed, via path 236, and the path is directed onto system bus 40. In one embodiment, a memory access request specifying a physical address directly is generated only when the processor is operating in the monitor mode.

As can be appreciated from the previous description of the MMU200, and in particular from the description of FIG. 43, the main TLB208 will contain a plurality of descriptors, and for each descriptor, a domain tag 425 will be provided to identify whether the corresponding description is from a secure page table or a non-secure page table. These descriptors 435 and associated domain labels 425 are schematically illustrated in the MMU200 of FIG. 55.

When a memory access request is issued by core 10, this will result in the physical address of that memory access request for output on system bus 40, and typically cache 38 will perform a lookup process to determine whether the data item specified by that address is stored in the cache. Whenever a miss occurs in the cache, i.e., it is determined that the data item subject to the access request is not stored in the cache, a linefill process is initiated by the cache to retrieve a data line including the data item of the subject of the memory access request from the external memory 56. In particular, the cache outputs linefill requests onto the control bus 2630 of the device bus 70 and start addresses onto the address bus 2620 via EBI 42. In addition, on path 2632, the HPROT signal is output onto control bus 2630, which will include a domain signal specifying the mode of operation of the core when a memory access request is issued. Thus, the linefill process can be viewed as propagating the original memory access request through the cache 38 onto the external bus.

This HPROT signal is received by the partition checker 2656, which therefore identifies whether the device requesting the specified data from the external memory 56 (in this case, the device containing the core 10 and cache 38) is operating in the secure domain or the non-secure domain when the memory access request is issued. The partition checker 2656 will also access partition information that identifies those areas of memory that are secure or unsecure, and thus can determine whether to allow the device to access the data it is requesting. Thus, the partition checker can be configured to only allow the device to access the secure portion of memory if a domain signal (also referred to herein as the S-bit) within the HPROT signal is asserted indicating that access to the data is requested by the device that is operating in the secure mode of operation.

If the partition checker determines that the kernel 10 is not allowed to access the requested data, for example, because the HPRTO signal indicates that the kernel is operating in an unsecure operating mode, but the linefill request is attempting to retrieve data from external memory located within a secure region of memory, the partition checker 2656 sends an abort signal onto the control bus 2630, on path 2636, which is passed back to the EBI42, and from there back to the cache 38, generating an abort signal that is sent to the kernel 10 on path 2670. However, if the partition checker 2656 determines that access is allowed, then an S tag signal indicating whether the data retrieved from external memory is secure or non-secure data will be output and passed back to EBI42 via path 2634 and thence to the cache 38 to allow the tag 2602 associated with cache line 2600, the subject of the linefill process, to be set.

At the same time, control logic 2650 will grant external memory 56 to output the requested linefill data, which is transferred back to cache 38 via EBI42 on path 2680 for storage in associated cache line 2600. Thus, as a result of this process, selected cache lines within cache 38 are populated with data items from external memory 56, including data items that were the subject of the original memory access request from core 10. The data item that is the subject of the memory access request from the core is then returned from the cache 38 to the core, or provided directly from the EBI to the core 10 on path 2660.

Since, in the preferred embodiment, the original stored data in the cache will result from the line fill process described above, the flag 2602 associated with that cache line will be set based on the value provided by the partition checker 2656, which is then used by the cache 38 to directly control any subsequent accesses to the data item in that cache line 2600. Thus, if the core 10 sequentially issues memory access requests that hit in a particular cache line 2600 of the cache 38, the cache 38 will preview the value of the relevant marker 2602 and compare the value to the current mode of operation of the core 10. In the preferred embodiment, the current mode of operation of the core 10 is represented by a field bit set by the monitor mode in the CP15 field status register. Thus, the cache 38 can be configured to only allow data items in the cache lines represented by respective markers 2602 to be secure data accessed by the processor core 10 when the processor core 10 is operating in a secure mode of operation. Any attempt by the core to access secure data within cache 38 while the core is in the non-secure mode will cause cache 38 to generate an abort signal on path 2670.

The TCM36 can be provided in various ways. In one embodiment, it can be arranged to operate like a cache, and in that embodiment, in the same manner as cache 38, will be configured to include a plurality of rows 2610, each having a tag 2612 associated therewith. Access to the TCM36 is then managed in exactly the same manner as described with reference to cache 38, and any TCM misses result in the line fill process being performed, as a result of which data is restored to the particular line 2610, and the partition checker 2656 will generate the required S tag value for storage in the tag 2612 associated with that line 2610.

In an alternative embodiment, the TCM36 can be provided as an extension of the external memory 56 and used to store data that is normally used by the processor, since accessing the TCM over the system bus is generally faster than accessing the external memory. In this embodiment, the TCM36 will not use the flag 2612, instead, a different mechanism will be used to control access to the TCM. In particular, as previously described, in these embodiments, a control flag is provided that is settable when operating in a privileged secure mode, indicating whether the tightly coupled memory is controllable by the processor only when executing in the privileged secure mode or when executing in at least one non-secure mode. The control flag is set by the secure operating system and, in effect, defines whether the TCM is controlled by the privileged secure mode or the non-secure mode. Thus, one architecture that can be defined is to control the TCM only when the processor is operating in a privileged secure operating mode. In these embodiments, any insecure access attempted to TCM control registers will cause an entry undefined instruction exception.

In an alternative configuration, the TCM can be controlled by the processor when operating in the unsecure operating mode. In these embodiments, the TCM is used only by non-secure applications. The secure data is not stored to or loaded from the TCM. Thus, when performing a secure access, no lookup is performed within the TCM to see if the address matches the TCM address range.

Fig. 57 is a flowchart illustrating a process performed by the apparatus of fig. 55 when a non-secure program operating on the processor core 10 generates a virtual address (step 2700). First, at step 2705, a lookup is performed in the microTLB 206, and if the result hits, the microTLB checks for access permissions at step 2730. Referring to FIG. 56, the process can be viewed as being performed by the access permission logic 202.

If at step 2705 a miss occurs in a microTLB lookup, then a lookup is performed in the main TLB208, in the non-secure descriptors stored therein (step 2710). If this results in a miss, then the page table walk process (already described with reference to FIG. 37) is performed at step 2715. after step 2720, it is determined that the main TLB contains a valid tagged non-secure descriptor. If the lookup yields a hit at step 2710, the process proceeds directly to step 2720.

Thereafter, at step 2725, the microTLB is loaded with the descriptor section containing the physical address, and then at step 2730, the microTLB checks for access permissions.

If at step 2730, it is determined that there is a violation of access permissions, then the process proceeds to step 2740, where an abort signal is issued to the processor core on path 230 (similar to path 2670 shown in FIG. 55). Assuming, however, that a violation is not detected, then at step 2745, a determination is made as to whether the access is related to a cacheable data item. If not, then an external access is initiated to attempt to retrieve the data item from external memory 56 at step 2790. At step 2795, the partition checker 25656 will determine if there is a security partition violation, i.e., if the processor core 10 is operating in a non-secure mode, an attempt is made to access a data item in secure memory, and if a violation is detected, the partition checker 5656 will generate an abort signal at step 5775. However, assuming there is no security partition violation, the processor proceeds to step 2785 and data access occurs at step 2785.

If, at step 2745, it is determined that the data item being requested can be cached, then, at step 2750, a cache lookup is performed in the cache, and if a hit is detected, then, at step 2755, the cache determines whether there is a security line tag violation. Thus, at this stage, the cache will view the value of the tag 2602 associated with the cache line containing the data item and compare that tag's value to the mode of operation of the core 10 to determine whether the core has access to the requested data item. If a security line tag violation is detected, the process proceeds to step 2760, where a security violation fault abort signal is generated by cache 38 and sent to core 10 on path 2670. However, assuming no security row tag violation is detected at step 2755, then a data access is performed at step 2785.

If a cache miss exists when the cache lookup is performed at step 2750, then a cache line fill is initiated at step 2765. At step 2770, partition checker 2656 checks for a security partition violation and, if so, issues an abort signal at step 2775. However, assuming no security partition violation is detected, at step 2780, the cache line fill process results in the end of the data access at step 2785.

As shown in FIG. 57, steps 2705, 2710, 2715, 2720, 2725, 2730, and 2735 are performed within the MMU, as well as steps 2745, 2750, 2755, 2765, 2780, and 2790 are performed by the cache, and steps 2770 and 2795 are performed by the partition checker.

Fig. 58 is a flowchart showing a similar process performed in the case where a secure program executing on the kernel generates a virtual address (step 2800). By comparing FIG. 58 with FIG. 57, it will be appreciated that steps 2805 through 2835 performed within the MMU are similar to steps 2705 through 2735 previously described with reference to FIG. 57. The only difference is that at step 2710, the lookup performed in the main TLB is performed based on any security descriptors stored in the main TLB, which, as a result, at step 2820 contains a validly tagged security descriptor.

Within the cache, the cache no longer needs to look for any security line tag violations, since in the embodiment illustrated with reference to FIG. 58, it is assumed that the security program has access to both secure and non-secure data. Thus, if at step 2850 a hit is generated during the cache lookup, then processing proceeds directly to data access step 2885.

Similarly, in the case where external access to external memory is required (i.e., at steps 3865 or 2890), the partition checker need not perform partition checks, again because it is assumed that the security program has access to either secure or non-secure data.

Steps 2845, 2850, 2865, 2880, and 2890 performed within the cache are similar to steps 2745, 2750, 2765, 2780, and 2790 described with reference to FIG. 57.

FIG. 59 illustrates different modes and applications running on a processor. The dashed lines represent how different modes and/or applications can be separated and isolated from one another during monitoring of a processor according to embodiments of the present invention.

Monitoring the processors to locate possible faults and to discover why applications do not perform as expected is extremely useful, and many processors provide these functions. Monitoring can be performed in a variety of ways, including debugging and tracing functions.

In a processor according to the current art, debugging can operate in several modes including a halt debugging mode and a monitor debugging mode. These modes are plug-in modes and result in the termination of the program running at this time. In a halted debug mode, when a breakpoint or watchpoint occurs, the kernel is halted and isolated from the rest of the system and enters a debug state. Upon entry, the core is halted, the pipeline is flushed, and instructions are not prefetched. Freeze PC and ignore any interrupts (IRQ and FIQ). The core internal state (via the JTAG serial interface) and memory system state may then be checked. This state insertion is performed because the current mode can be modified, register contents modified, and so forth. Once the debugging is terminated, the kernel exits from the debug state by scanning through the debug TAP (test access port) with a restart instruction. The program then resumes execution.

In monitor debug mode, a breakpoint or watchpoint causes the kernel to enter suspend mode, performing pre-fetch or data suspend vectors respectively. In this case, while in the halted debug mode, the kernel is still in functional mode and is not halted. The abort handler communicates with the debugger application to access the processor and processor state or dump memory. A debug monitor is coupled between the debug hardware and the software debugger. Interrupts (FIQ and IRQ) can be disabled if bit 11 of the debug status and control register DSCR is set (see later). In monitor debug mode, vector trapping is disabled to avoid bringing the processor into an unrecoverable state based on the abort result generated for monitor debug mode, at the time of data abort and prefetch abort. It should be noted that the monitor debug mode is a debug mode and is not associated with a monitor mode of the processor being a mode to supervise switching between secure and non-secure areas.

Debugging can provide snapshot printing of the state of the processor at a certain time. By noting that upon receiving a debug initiation request, the values in the different registers complete. These values are recorded on the scan chains (541, 544 of fig. 67), and then sequentially output using the JTAG controller (18 of fig. 1).

An alternative method of monitoring the kernel is through tracing. The trace is not an insert and a continue state is recorded as the kernel continues to operate. The traces run in the inline trace macrocell (ETM)22, 26 of fig. 1. The ETM has a trace port through which trace information is output and then analyzed by an external trace port analyzer.

The processor of embodiments of the present technology operates in two separate domains, in the described embodiment, these domains include a secure domain and a non-secure domain. However, for monitoring function purposes, these domains may be any two domains for which data should not leak to a technician. Embodiments of the present invention are directed to preventing data leakage between two domains and to allowing access to monitoring functions of the overall system in general, such as debugging and tracing, which are potential sources of inter-domain data leakage.

In the examples given above for secure and non-secure domains or areas, secure data must not be available for non-secure areas. In addition, if debugging is allowed, in the secure domain it is advantageous to restrict or hide some data within the secure domain. The dashed lines in FIG. 59 represent some examples of possible methods of segmented data access and providing different levels of granularity. In fig. 59, the monitoring mode and the safest of all modes, and the switching between safe and non-safe areas is indicated by block 500. In the monitor mode 500, there are supervisory modes, which include a secure supervisory mode 510 and an unsecure supervisory mode 520. There is then a non-secure user mode with applications 522 and 524 and a secure user mode with applications 512, 514, and 516. The monitor mode (debug and trace) can be controlled to monitor only the non-secure mode (left side of virtual 501). In addition, monitoring of non-secure domains or regions and secure user modes (to the left of 501 and to the right of 501 below 502) may be allowed. In another embodiment, insecure areas and certain applications running in the secure user domain may be allowed, in which case additional segmentation by dashed line 503 occurs. These partitions help prevent the leakage of security data between different users running different applications. In some controlled cases, it may allow monitoring of the entire system. Depending on the required granularity, the following parts of the kernel need to control their access during the monitoring function.

On a debug event, four registers can be set: an Instruction Fault Status Register (IFSR), a Data Fault Status Register (DFSR), a Fault Address Register (FAR), and an Instruction Fault Address Register (IFAR). In some embodiments, these registers should be flushed to avoid any leakage of data when entering the insecure area from the secure area.

PC sample register: the debug TAP can access the PC through the scan chain 7. When debugging in the secure enclave, that value can be masked, depending on the debug granularity selected in the secure enclave. When the kernel is operating in the secure domain, it is important that the insecure domain, or insecure domain plus secure user applications, cannot obtain any value of the PC.

TLB entries: using CP15, the microTLB entries may be read as well as the main TLB entries read and written. It can also control main TLB and micro LTB loading and matching. This operation must be tightly controlled, especially if the secure thread identification debug requires the assistance of an MMU/MPU.

Performance monitor control register: the performance control registers provide information about cache misses, microTLB misses, external memory requests, executed branch instructions, and so forth. The insecure area should not access the data even in the debug state. The counter should operate in the secure domain even if debugging is disabled in the secure domain.

Debugging in a cache system: in a cache system, debugging must be in non-intrusive mode. It is important to maintain coherency between the cache and the external memory. Using CP15, the cache can be invalidated, or the cache can be write-through in all regions. In any case, allowing cache behavior to be modified in debugging can be a security vulnerability and should be controlled.

Endianness (endianness): a non-secure area or secure user application that can access the debug should not be allowed to change byte order. Changing the byte order can cause the security kernel to malfunction. Depending on the granularity, byte-sequential access can be prohibited during debugging.

When the monitor function is started, access to the monitor function of the kernel portion can be controlled. Debugging and tracing are initiated in various ways. Embodiments of the present technology control access to the monitor function to certain secure portions of the kernel, allowing initialization only under certain conditions.

Embodiments of the present technology seek to limit items to a monitoring function by the following granularity:

insertion and observable (trace) debugging by individual control;

by allowing debug items only in secure user mode or in the entire secure region;

by allowing debugging only in secure user mode, furthermore, the thread ID (running application) is taken into account.

To control the activation of the monitoring function, it is important to know how the function can be activated. FIG. 60 shows a table that illustrates possible ways of activating the monitor function, the type of monitor function activated, and the way the activation instructions can be programmed.

These monitoring instructions are typically input via software or via hardware, i.e., via the JTAG controller. To control the start-up monitoring function, control values are used. These include an enable bit depending on the condition, so if a particular condition exists, if the enable bit is set, only enable monitoring is allowed. These bits are stored on a secure register CP14 (debug and status control register, DSCR) located in the ICE530 (see fig. 67).

In the preferred embodiment, there are four bits that enable/disable insertion and observable debug, these include a secure debug enable bit, a secure trace enable bit, a secure user mode enable bit, and a secure thread identification enable bit. These control values are used to provide controllable granularity for the monitoring function, and as such, can help prevent data leakage from a particular domain. Fig. 61 provides an overview of these bits and how they are accessed.

These control bits are stored in registers in the secure domain and access to the registers is limited to three possibilities. Software access is provided via the ARM coprocessor MRC/MCR instructions, and these are only allowed from the security supervision mode. In addition, software access is provided from any other mode through the use of a passcode. Another alternative involves more hardware access and calls for instructions written via input ports on JTAG. In addition to being used to input control values relating to the availability of the monitoring function, the input port can also be used to input control values relating to other functions of the processor.

Further description related to scan chain and JTAG is provided below.

Register logic unit

Each Integrated Circuit (IC) is composed of two types of logic:

● combinational logic cells like AND, OR, INV gates. These gates or combinations of these gates are used to compute the boolean expression from one or more input signals.

● register logic Unit: like latches, flip-flops. These cells are used to store any signal value. FIG. 62 shows a flip-flop view with positive edge triggering.

When a positive edge event occurs on the clock signal (CK), the output (Q) receives the value of the input (D), otherwise the output (Q) saves its value in memory.

Scan chain unit

It is desirable to ignore functional accesses of register logic units and to directly access the contents of register logic units for testing or debugging purposes. The register cells are integrated in the scan chain cells shown in fig. 63.

In functional mode, clear (SE) (scan enable) and register cells operate as a single register cell. In test or debug mode, the set SE and input data can come from the SI input (scan input), rather than the D input.

Scan chain

All scan chain cells are tied into a scan chain as shown in fig. 64.

In functional mode, the SE is cleared and all register cells can be accessed normally and interact with other logic of the circuit. In test or debug mode, the set SE and all registers are tied to each other in the scan chain. Data can come from a first scan chain cell and can be shifted through any other scan chain cell according to the lockstep signal per clock cycle. The data can be shifted out to view the contents of the register.

TAP controller

The debug TAP controller is used to process multiple scan chains. The TAP controller can select a particular scan chain: it connects the scan-in and scan-out signals to that particular scan chain. The data can then be scanned into the chain, shifted out, or scanned out. The TAP controller is externally controlled by the JTAG port microphone. Fig. 65 schematically illustrates a TAP controller.

JTAG scan chain unit with selective inhibition

For security reasons, some registers cannot be accessed by the scan chain even in debug or test mode. The new input, so-called JADI (JTAG access disable), can allow the scan chain cells to be dynamically and statically shifted out of the entire scan chain without modifying the scan chain structure of the integrated circuit. Fig. 66A and 66B schematically show this input.

If JADI is invalid (JADI 0), the scan chain operates normally whether in functional or test or debug mode. Some scan chain cells (selected by the designer) may be shifted out of the scan chain structure if JADI is active (JADI ═ 1), and if in test or debug mode. JTAG has the option of allowing scan chain cells to use bypass registers in order to maintain the same scan chain cell number. Note that Scan Out (SO) and scan chain cell output (Q) are now different.

FIG. 67 schematically illustrates a processor including a JTAG portion. In normal operation, instruction memory 550 communicates with the core and, in some circumstances, can also communicate with register CP14, as well as reset control values. This is normally only allowed in the safety supervision mode.

When debugging is initiated, instructions are input via the debug TAP580 as well as those instructions that it is controlling the core. The kernel in debug runs in a step-by-step mode. The debug TAP accesses CP14 via the kernel (as determined by the access control signal input on the JSDAEN pin, shown as the JADI pin, the JTAG access disable input in fig. 45) and resets the control values in this manner.

Access to the CP14 register via debug TAP580 is controlled by access control signal JSDAEN. This is configured so that for access and in particular write access, JSDAEN must be set high. In the board level phase, when the entire processor is being verified, JSDAEN is set high and debugging is allowed on the entire system. Once the system is verified, the JSDAEN pin can be tied to ground, which means that access to the control values that allow debugging in secure mode is now unavailable via debug TAP 580. Typically, a processor in production mode has a JSDAEN connected to ground. Access control values are only available via software routing via instruction memory 550. Access via this route is restricted to a security supervision mode or another mode in which it is assumed that a verification code is given (see fig. 68).

It should be noted that by default, debugging (insertion and observable-trace) can only be used in non-secure areas. To allow them to be used in the security area, a control value enable bit needs to be set.

This has the advantage that debugging can always be initiated by the user to run in an unsecured area. Thus, while in commissioning, access to the secure area is not always available to the user, in many cases this is not a problem as access to the area is restricted and the secure area is fully verified at the board level before being made available. Thus, it is foreseen that in many cases, debugging the secure enclave is unnecessary. The security supervisor still initiates debugging, if necessary, via the software route written to CP 14.

Fig. 68 schematically illustrates control of debug start. In this figure, the kernel portion 600 includes a storage element 601 (which may be a CP15 register as previously described) that stores a security status bit S indicating whether the system is a secure enclave, the kernel 600 also includes a register 602 consisting of bits indicating the mode, e.g., user mode, in which the processor is running, and a register 603 that provides a context identifier identifying the application or thread that is currently running on the kernel.

When the breakpoint reaches comparator 610, which compares the breakpoint stored on register 611 with the address of the core stored on register 612, a signal is sent to control logic 620. Control logic 620 looks at the security state S, mode 602, and thread (context identifier) 603 and compares it to the control values and condition indicators stored on register CP 14. If the system is not operating in the safe area, an "enter debug" signal will be output at 630. However, if the system is operating in a secure area, control logic 620 will look at mode 602 and, if in user mode, will check to see if the user mode enable and debug enable bits are set. If they are, then debugging will be initiated, assuming that the thread identification bit has not been initiated. The above illustrates the hierarchical nature of the control values.

Also illustrated schematically in fig. 68 is the thread identification portion of the supervisory control and how the control value stored in register CP14 can only be changed from the security supervisor mode (in this embodiment, the processor is at product level and JSDAEN is connected to ground). From the secure user mode, using the authentication code, a secure supervisory mode can be entered, and then control values can be set in CP 14.

Assuming that thread comparator 640 indicates that debugging is available for that thread, control logic 620 outputs an "enter debug" signal when address comparator 610 indicates that a breakpoint has been reached. This assumes that the thread identification initialization bit can be set in CP 14. If the thread identification initialization bit is set after the breakpoint, debugging or tracing can only be entered if the address and context identifiers match those represented in the breakpoint and allowable thread indicators. After the monitor function is initiated, only diagnostic data will continue to be captured while the context identifier is identified by comparator 640 as an allowed thread. When the context identifier indicates that the running application is not an allowed application, then trapping diagnostic data is suppressed.

It should be noted that in the preferred embodiment there are some levels within the granularity. In effect, the secure debug or trace enable bit is at the top, after and finally to the secure thread identification enable bit. This is illustrated in fig. 69A and 69B (see below).

The control values held in the "debug and status control" registers (CP14) control the security debug granularity according to domain, mode, and execution thread. Which is in the upper part of the safety supervision mode. Once the "debug and State control" register CP14 is constructed, it goes to a secure supervisor mode to program the corresponding breakpoints, watchpoints, etc. to bring the kernel into a debug state.

Fig. 69A illustrates an overview of security debug granularity for plug-in debug. The default values at reset are indicated in grey.

The same is true for the granularity of debugging with respect to observable tests. Fig. 69B shows an overview of the security debug granularity in this case, where the default values at reset are also shown in grey.

Note that the secure user mode debug enable bit and the secure thread identification debug enable bit are typically used for insertion and observable debug.

The thread identification initialization bit is stored in register CP14 and indicates whether granularity by the application is required. If the thread identification bit has been initialized, control logic will further verify that the application identifier or thread 603 is represented in the thread identification control bit, and if so, initiate debugging. If neither of the user mode or debug enable bits is set or the thread identification bit is set and the application is not the one represented in the thread identification control bits, then the breakpoint will be ignored and the kernel will continue the processing it performs and not initiate debugging.

In a similar manner, in addition to controlling the initialization of the monitoring function, the capture of diagnostic data during the monitoring mode can be controlled. To perform this operation, the kernel must continue to consider the control values, i.e., the enable bits stored in CP14 and the conditions associated with them during the monitoring function.

FIG. 70 schematically represents the granularity of monitoring functions at runtime. In this case, the area a is related to an area where capture of diagnostic data is permitted, and the area B is related to an area where capture of diagnostic data is impossible as indicated by the control value stored in the CP 14.

Thus, while the debugging is running and the program is operating in region a, during debugging, the diagnostic data is output in a step-wise fashion. When operation switches to region B, where capture of diagnostic data is not allowed, debugging no longer proceeds in a step-wise fashion, rather it processes data automatically and does not capture it. This continues until the operation of the program again enters region a, then the capture of diagnostic data begins again and debugging continues in a step-wise fashion.

In the above embodiment, if the security domain is not authorized, the SMI instruction is always treated as an atomic event and the trapping of diagnostic data is suppressed.

Furthermore, if the thread identification initialization bit is set, granularity of the monitoring function during operation also occurs with respect to the application.

With respect to observable debug or trace, this is accomplished by ETM, completely independent of debug. When tracking is enabled, the ETM works normally and when it is disabled, the ETM hides tracking in the safe area, or portion of the safe area depending on the selected granularity. When not allowed, one way to avoid the ETM from capturing and tracking diagnostic data in the security domain is to stop the ETM when the S bit is high. This can be accomplished by combining the S bits with the ETMPWRDOWN signal so that when the cores enter the secure enclave, the ETM values remain at their last values. Therefore, the ETM should track SMI instructions and then not stop until the kernel returns to the non-secure area. Thus, the ETM sees only insecure activity.

An overview of some of the different monitoring functions and their granularity is given below.

Board level plug-in debug

At the board level, when the JSDAEN pin is not connected, there is the ability to allow debugging anywhere before beginning any bootable christmas. Similarly, if in safety supervision mode, there are similar rights.

If debugging is initiated in the abort debug mode, all registers (non-secure and secure register sets) can be accessed, and the entire memory can be dumped, except for the bits dedicated to control debugging.

Debug abort mode can be entered from any mode and from any domain. Breakpoints and watchpoints can be set in secure or non-secure memory. In the debug state, the secure enclave may be entered via an MCR instruction by simply changing the S bit.

When a security exception occurs, the vector interrupt register can be extended by the following new bits when a debug mode can be entered:

SMI vector interrupt allowance

Secure data abort vector interrupt allowance

Secure prefetch abort vector interrupt allowance

Secure undefined vector interrupt allowance

In monitor debug mode, if debug is allowed anywhere, even when the SMI is debugged in the insecure area, the secure area can be entered in gradual debug. When a breakpoint occurs in the secure domain, the secure abort handler can be used to dump the secure register set and the secure memory.

The two abort handlers in the secure and non-secure areas provide their information to the debug application so that the debug program window (on the associated debug control PC) can represent the register state in the secure and non-secure areas.

Fig. 71A shows events that occur when a kernel is constructed in the monitor debug mode and debugging is permitted in the secure area. Fig. 71B shows events that occur when the kernel is constructed in the monitor debug mode and debugging is prohibited in the secure area. This latter process will be described below.

Plug-in debug at product level

At the production level, when JSDANS is connected and debugging is restricted to an insecure area, the table shown in FIG. 71B represents the events that occur unless determined by a security supervisor. In this case, the SMI should always be treated as an atomic instruction, so that the security function is always completed before entering the debug state.

Entering debug abort mode is subject to the following limitations:

external debug requests or internal debug requests are considered only in the non-secure region. If EDBGRQ (external debug request) is asserted while in the secure region, the kernel enters debug abort mode once the secure function is terminated and the kernel returns to the non-secure region.

Programming breakpoints or watchpoints on secure memory has no effect and the kernel is not halted when the programming addresses match.

The vector interrupt register (details of which are given below) is only concerned with non-secure enclave exceptions. All the extended interrupt enable bits previously described have no effect.

As long as in the break debug mode, the following restrictions apply:

forcing secure enclave input without changing the S bit unless secure debug is allowed

If debugging is allowed only in the safety supervision mode, the mode bit is not changed.

The dedicated bit controlling the secure debug is not changed.

If an SMI is loaded and executed (accessed through system speed), the kernel re-enters the debug state only when the security functions are fully executed.

In monitor debug mode, the secure abort handler does not need to support the debug monitor because monitoring does not occur in the secure region. In the non-secure area, stepping is possible, but as long as the SMI is executed, the secure function is performed in its entirety, in other words, the XWSI is allowed to step as "stepping" and "stepping out" are possible on all other instructions. Therefore, XWSI is considered an atomic instruction.

Once secure debug is disabled, the following limitations apply:

prior to entering the monitoring mode:

breakpoints and watchpoints are considered only in non-secure areas. If the S bit is set, the breakpoint/watchpoint is ignored. Note that the watchpoint unit can also be accessed through the MCR/MRC (CP14), since in secure memory the breakpoint/watchpoint has no effect and is therefore not a security issue.

BKPTs are typically used to replace instructions on which breakpoints are set. This assumes that this instruction in memory is overwritten with the BKPT instruction, which is only possible in the non-secure mode.

The vector interrupt register is only involved in non-secure exceptions. All extended interrupt enable bits as described previously have no effect. Data aborts and prefetch abort grant bits should be disabled to avoid the processor forcing an unrecoverable state.

JTAG, has the same restrictions as for abort mode (S bit cannot be modified, etc.).

Once in monitor mode (non-secure suspend mode)

The unsecure abort handler can dump the unsecure region and have no visibility over the secure banked registers and the secure memory.

Performing security functions via atomic SMI instructions

Can change S bit to force secure area items

Mode bits cannot be changed because debugging is only allowed in secure supervisor mode

Note that if an external debug request (EDBGRQ) occurs,

in the non-secure region, the kernel aborts the current instruction and then immediately enters the debug state (in abort mode)

In the secure region, the kernel aborts the current function and enters a debug state when it has returned to the non-secure region.

New debug requirements mean improvements in kernel hardware. The S bit must be carefully controlled and for security reasons the security bit must not be inserted into the scan chain.

In general, in debugging, the mode bit can be modified as long as debugging is allowed in the secure supervisor mode. Anyone will be prevented from entering the secure domain for debugging in order to enter all secure domains by modifying the system (modifying TBL entries waiting). In that way, each thread can debug its own code, as well as just its own code. The security kernel must be kept secure. Thus, when debugging is entered while the kernel is running in an unsecure region, only the mode bit is changed as before.

Embodiments of the technique use a new vector interrupt register. If a bit in the register is set high and the corresponding vector triggers, the processor enters a debug state as if a breakpoint had been set on the instruction fetched from the associated exception vector. The behavior of these bits may differ depending on the debug value in the secure enclave enable bit in the debug control register.

The new vector interrupt register includes the following bits: d _ S _ abort, P _ S _ abort, S _ Undef, SMI, FIQ, IRQ, Unaligned, D _ abort, P _ abort, SWI, and Undef.

● D _ s _ abort bit: the debug is set only when debug is allowed in the secure area, and when debug is configured in the break debug mode. In monitor debug mode, this bit should be a never set bit. If debug in the secure enclave is disabled, the bit has no effect regardless of its value.

● P _ s _ abort bit: the same as the D _ s _ abort bit.

● S _ undef bit: it is only set when debugging is allowed in the secure area. If debug in the secure enclave is disabled, the bit has no effect regardless of its value.

● SMI bit: it should be set only when debugging is allowed in the secure domain. If debug in the secure enclave is disabled, the bit has no effect regardless of its value.

● FIQ, IRQ, Unaligned, D _ abort, P _ abort, SWI, and Undef bits: corresponding to non-secure exceptions, and therefore, they are valid even if debugging in the secure domain is prohibited. Note that in monitor mode, D _ abort and P _ abort should not be asserted high.

● Reset bit: when entering the secure enclave when a reset occurs, the bit is valid only when debug in the secure enclave is enabled, otherwise there is no effect.

Although particular embodiments of the invention have been described herein, it will be obvious that the invention is not limited thereto and that many modifications and additions may be made within the scope of the invention. For example, various combinations of the features of the following dependent claims can be made according to the features of the independent claims without departing from the scope of the present invention.

Claims (46)

1. Apparatus for processing data, the apparatus comprising:

a processor (10) operable in a plurality of modes (1, 2, 3, 4; A, B, C) and a plurality of domains (S, NS), the plurality of domains including either a secure domain or a non-secure domain, the plurality of modes including:

at least one security mode (A, B, C) being a mode in said security domain (S);

at least one non-secure mode (1, 2, 3, 4) being a mode in the non-secure domain (NS);

it is characterized in that the preparation method is characterized in that,

when the processor (10) is executing a program (82, 84) in a secure mode, the program may use secure data that is not accessible when the processor is operating in a non-secure mode;

the processor is responsive to one or more exception conditions (RESET, UNDEF, …) for triggering exception handling using an exception handler, the processor being operable to select the exception handler from a plurality of possible exception handlers (VS0-7, VNS0-7) depending on whether the processor is operating in the secure domain or the non-secure domain.

2. The apparatus of claim 1, wherein at least one of the exception conditions is a selectable exception handled by a selected one of a non-secure exception handler operating in a non-secure mode or a secure exception handler operating in a secure mode; and

at least one of the exception conditions is a dedicated security exception that may be handled by a security exception handler operating in a secure mode.

3. The apparatus of claim 1, wherein the one or more exception conditions are programmably configurable to trigger a non-secure exception handler operating in a non-secure mode or a secure exception handler operating in a secure mode, wherein any required domain changes are also triggered.

4. Apparatus as claimed in any preceding claim, having a security exception triggered by a signal on a dedicated security exception signal input and a non-security exception signal input.

5. Apparatus as claimed in any one of claims 1, 2 and 3, having an exception signal input shared between secure and non-secure exceptions and a further input signal cooperating with said exception signal input to control whether a secure exception handler or a non-secure exception handler is triggered.

6. The apparatus of claim 1, wherein the security exception handler is part of a secure operating system operable in the secure mode.

7. The apparatus of claim 1, wherein the non-secure exception handler is part of a non-secure operating system operable in the non-secure mode.

8. The apparatus of claim 1, wherein the processor is also operable in a monitor mode and any switching between secure and non-secure modes required for handling exceptions is generated via the monitor mode, the processor being operable at least in part in the monitor mode to execute a monitor program that manages switching between the secure and non-secure modes.

9. The apparatus of claim 8, wherein the monitor is operable to save and restore context data defining a state of the processor to handle exceptions when switching between the secure mode and the non-secure mode.

10. Apparatus as claimed in any one of claims 8 and 9, wherein said processor includes a register bank and said monitor is operable when switching from said secure mode to said non-secure mode to flush at least a portion of said register bank shared between said secure mode and said non-secure mode, such that secure data held in said register bank is not passed from said secure mode to said non-secure mode other than as permitted by said monitor.

11. The apparatus of claim 1, wherein the exception condition comprises one or more of:

a safety interrupt signal is abnormal;

a mode switching software interrupt signal;

resetting the exception;

an interrupt signal is abnormal;

a software interrupt signal;

an undefined instruction exception;

a prefetch abort exception;

a data abort exception; and

the fast interrupt signal is abnormal.

12. Apparatus as claimed in claim 1, wherein said processor is responsive to an exception condition to select an exception handler in dependence upon an exception vector value associated with said exception condition and stored in an active exception vector table for said exception condition; and

the valid exception vector table is one of a plurality of exception vector tables.

13. Apparatus as claimed in claim 12, wherein said plurality of exception vector tables includes a secure exception vector table selectable in said secure mode and a non-secure exception vector table selectable in said non-secure mode.

14. Apparatus according to any one of claims 12 and 13, wherein said processor is also operable in a monitor mode and is operable for any switching between a secure mode and a non-secure mode, and wherein said plurality of exception vectors are executed via said monitor mode.

15. The apparatus as in claim 14 wherein said plurality of exception vector tables comprises a monitor mode exception vector table.

16. Apparatus as claimed in claim 15, wherein said processor is responsive to one or more parameters specifying which of said exceptions should be handled by said monitor mode exception vector table.

17. The apparatus of claim 13, wherein said processor is also operable in a monitor mode and is operable for any switching between a secure mode and a non-secure mode, and wherein said plurality of exception vectors are executed via said monitor mode; the plurality of exception vector tables includes a monitor mode exception vector table; said processor being responsive to one or more parameters specifying which of said exceptions should be handled by said monitor mode exception vector table; the secure vector table is the active vector table in the secure mode and the non-secure vector table is the active vector table in the non-secure mode unless the one or more parameters specify that the monitor mode vector table is the active vector table for the exception condition.

18. The apparatus of claim 16, wherein at least one of the parameters is stored in an exception trap mask register.

19. The apparatus of claim 18, wherein the exception trap mask register is writable when the processor is in the monitor mode and is not writable when the processor is not in the non-secure domain.

20. An apparatus as claimed in claim 13, wherein said security exception vector table is writable when said processor is in a secure mode and said security exception vector table is not writable when said processor is in a non-secure mode.

21. The apparatus of claim 13, wherein a secure exception handler that is part of a secure operating system is used by the secure mode.

22. The apparatus of claim 13, wherein a non-secure exception handler that is part of a non-secure operating system is used by the non-secure mode.

23. Apparatus as claimed in claim 12, comprising a plurality of vector table base address pointer registers, each storing a respective base address value for a respective one of said plurality of exception vector tables.

24. A method of processing data, the method comprising the steps of:

executing, by a processor operable in a plurality of modes and a plurality of domains, the plurality of domains including a secure domain or a non-secure domain, a program, the plurality of modes comprising:

at least one security mode that is a mode in the security domain;

at least one non-secure mode that is a mode in the non-secure domain;

wherein,

allowing access to secure data by the program when the processor is executing the program in a secure mode, and not allowing access to the secure data by the program when the processor is operating in a non-secure mode;

in response to one or more exception conditions, exception handling is triggered using an exception handler, the processor being operable to select the exception handler from a plurality of possible exception handlers depending on whether the processor is operating in the secure domain or the non-secure domain.

25. The method as in claim 24 wherein at least one of the exceptions is a selectable exception handled by a selected one of a non-secure exception handler operating in a non-secure mode or a secure exception handler operating in a secure mode; and

at least one of the exceptions is a dedicated security exception that may be handled by a security exception handler operating in secure mode.

26. The method as recited in claim 24, wherein the one or more exception conditions are programmably configurable to trigger either a non-secure exception handler operating in a non-secure mode or a secure exception handler operating in a secure mode, wherein any required domain changes are also triggered.

27. A method as claimed in any one of claims 24, 25 and 26, having a secure exception signal input and a non-secure exception signal input.

28. A method as claimed in any one of claims 24, 25 and 26, having an exception signal input shared between secure and non-secure exceptions and a further input signal cooperating with said exception signal input to control whether a secure exception handler or a non-secure exception handler is triggered.

29. The method of claim 24, wherein the security exception handler is part of a secure operating system operable in the secure mode.

30. A method as claimed in any one of claims 24 to 26, wherein said non-secure exception handler is part of a non-secure operating system operable in said non-secure mode.

31. A method as claimed in any one of claims 24 to 26, wherein said processor is also operable in a monitor mode and any switching between a secure mode and a non-secure mode required for handling an exception is made via said monitor mode, said processor being operable at least in part in said monitor mode to execute a monitor program which manages switching between said secure mode and said non-secure mode.

32. The method of claim 31, wherein the monitor is operable to save and restore context data defining a state of the processor to handle exceptions when switching between the secure mode and the non-secure mode.

33. A method as claimed in claim 31, wherein said processor includes a register bank and said monitor is operable, when switching from said secure mode to said non-secure mode, to flush at least the portion of said register bank shared between said secure mode and said non-secure mode, so that secure data held in said register bank is not passed from said secure mode to said non-secure mode, other than as permitted by said monitor.

34. The method of claim 24, wherein the at least one exception condition includes one or more of:

a safety interrupt signal is abnormal;

a mode switching software interrupt signal;

resetting the exception;

an interrupt signal is abnormal;

a software interrupt signal;

an undefined instruction exception;

a prefetch abort exception;

a data abort exception; and

the fast interrupt signal is abnormal.

35. A method as claimed in claim 24, wherein said processor is responsive to an exception condition to select an exception handler in dependence upon an exception vector value associated with said exception condition and stored in an active exception vector table for said exception condition; and

the valid exception vector table is one of a plurality of exception vector tables.

36. A method as claimed in claim 35, wherein said plurality of exception vector tables includes a secure exception vector table selectable in said secure mode and a non-secure exception vector table selectable in said non-secure mode.

37. A method as claimed in any one of claims 35 and 36, wherein said processor is also operable in a monitor mode and is operable for any switching between a secure mode and a non-secure mode, and wherein said plurality of exception vectors are executed via said monitor mode.

38. A method as claimed in claim 37, wherein said plurality of exception vector tables includes a monitor mode exception vector table.

39. A method as claimed in claim 37, wherein said processor is responsive to one or more parameters specifying which of said exceptions should be handled by said monitor mode exception vector table.

40. The method of claim 36, wherein said processor is also operable in a monitor mode and is operable for any switching between a secure mode and a non-secure mode, and wherein said plurality of exception vectors are executed via said monitor mode; said processor being responsive to one or more parameters specifying which of said exceptions should be handled by said monitor mode exception vector table; the secure vector table is the active vector table in the secure mode and the non-secure vector table is the active vector table in the non-secure mode unless the one or more parameters specify that the monitor mode vector table is the active vector table for the exception condition.

41. The method of claim 39, wherein at least one of the parameters is stored in an exception trap mask register.

42. A method as defined in claim 41, wherein the exception trap mask register is writable when the processor is in the monitor mode and is not writable when the processor is not in the monitor mode.

43. A method as claimed in claim 36, wherein said security exception vector table is writable when said processor is in a secure mode and said security exception vector table is not writable when said processor is in a non-secure mode.

44. The method of claim 36, wherein a secure exception handler that is part of a secure operating system is used by the secure mode.

45. The method of claim 36, wherein a non-secure exception handler that is part of a non-secure operating system is used by the non-secure mode.

46. A method as claimed in claim 35, comprising storing respective base address values for respective ones of said plurality of exception vector tables in a plurality of vector table base address registers.

Images