System register lockdown control register

The system register lockdown control register addresses vulnerabilities in lower exception level software by locking down critical system register states, enhancing security against attacks and maintaining secure operation.

GB2702303APending Publication Date: 2026-06-10ARM LTD

Patent Information

Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
ARM LTD
Filing Date
2024-11-01
Publication Date
2026-06-10

AI Technical Summary

Technical Problem

Software at a lower exception level, despite trusting its own code, is vulnerable to attacks such as return-oriented programming, which can cause system register updates at inappropriate times, compromising system security by allowing unauthorized access or incorrect operation.

Method used

Implementing a system register lockdown control register that allows instructions at a predetermined exception level to set lockdown control information, specifying whether system register state information is locked or unlocked, thereby suppressing unauthorized updates and enhancing security.

Benefits of technology

The system register lockdown control register prevents unauthorized updates to system register state information, thereby bolstering security against attacks and ensuring secure operation of software at lower exception levels.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

An apparatus comprises processing circuitry configured to perform data processing in response to instructions executed in one of a plurality of exception levels; system registers configured to store s
Need to check novelty before this filing date? Find Prior Art

Description

The present technique relates to the field of data processing. A data processing apparatus may have system registers which store system register state information. The system register state information can be used to control processor behaviour, such as memory management and exception handling, as well as defining which actions are permitted to be performed by software in a given state of the processing circuitry. At least some examples of the present technique provide an apparatus comprising: processing circuitry configured to perform data processing in response to instructions executed in one of a plurality of exception levels supported by the processing circuitry; a plurality of system registers configured to store system register state information; and at least one system register lockdown control register configured to store lockdown control information for controlling updates to a subset of the system register state information, wherein the at least one system register lockdown control register is writable in response to an instruction executed in a predetermined exception level other than a most privileged exception level and the lockdown control information specifies, for each item of system register state information in the subset, whether that item is in a locked state or an unlocked state; wherein: in response to a system register update instruction executed in the predetermined exception level and requesting an update to a target item of system register state information from said subset of system register state information, the processing circuitry is configured to: determine whether the lockdown control information specifies that the target item of system register state information is in the unlocked state or the locked state; and suppress the update to the target item of system register state information, in response to determining that the lockdown control information specifies that the target item of system register state information is in the locked state. At least some examples of the present technique provide computer-readable code for fabrication of the apparatus described above. The computer-readable code may be stored on a storage medium. The storage medium may be a non-transitory storage medium. At least some examples provide a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: processing program logic configured to simulate execution of instructions in one of a plurality of exception levels supported by the processing program logic; and system register simulating program logic configured to control access to simulated system register state information and lockdown control information for controlling updates to a subset of the simulated system register state information, the lockdown control information being writeable in response to an instruction simulated by the processing program logic as being executed in a predetermined exception level other than a most privileged exception level, and the lockdown control information specifying, for each item of simulated system register state information in the subset, whether that item is in a locked state or an unlocked state; wherein: in response to a system register update instruction simulated as being executed in the predetermined exception level and requesting an update to a target item of simulated system register state information from said subset of simulated system register state information, the processing program logic is configured to: determine whether the lockdown control information specifies that the target item of simulated system register state information is in an unlocked state or a locked state; and suppress the update to the target item of simulated system register state information, in response to determining that the lockdown control information specifies that the target item of simulated system register state information is in the locked state. The computer program may be stored on a storage medium. The storage medium may be a non-transitory storage medium. At least some examples of the present technique provide a method comprising: in response to a system register update instruction executed by processing circuitry in a predetermined exception level of a plurality of exception levels supported by the processing circuitry, the instruction requesting an update to a target item of system register state information from a subset of system register state information for which updates to the subset of the system register state information are controlled based on lockdown control information stored in at least one system register lockdown control register writeable in response to an instruction executed in the predetermined exception level, the lockdown control information specifying, for each item of system register state information in the subset, whether that item is in a locked state or an unlocked state: determining whether the lockdown control information specifies that the target item of system register state information is in the unlocked state or the locked state; and suppressing the update to the target item of system register state information, in response to determining that the lockdown control information specifies that the target item of system register state information is in the locked state. Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which: Figure 1 illustrates an example of an apparatus comprising processing circuitry and system registers, including a system register lockdown control register; Figure 2 illustrates steps for controlling a system register update based on lockdown control information specified in the system register lockdown control register; Figure 3 illustrates an example of a processor which may implement the system register lockdown control register; Figure 4 illustrates exception levels which may be supported by the processor; Figure 5 illustrates an example of system registers, including at least one instance of the system register lockdown control register associated with an exception level other than a most privileged exception level; Figure 6 illustrates an example of lockdown fields of the system register lockdown control register which control updates to corresponding items of system register state information; Figure 7 illustrates an example of steps for controlling a system register update based on the lockdown control information specified in the system register lockdown control register; Figure 8 illustrates an example of steps for controlling whether an update to the lockdown control information specified in the system register lockdown control register is permitted; and Figure 9 illustrates a simulation example. An apparatus comprises processing circuitry configured to perform data processing in response to instructions executed in one of a plurality of exception levels supported by the processing circuitry, and a plurality of system registers configured to store system register state information. At least one system register lockdown control register is provided, configured to store lockdown control information for controlling updates to a subset of the system register state information. The at least one system register lockdown control register is writable in response to an instruction executed in a predetermined exception level other than a most privileged exception level. The lockdown control information specifies, for each item of system register state information in the subset, whether that item is in a locked state or an unlocked state. In response to a system register update instruction executed in the predetermined exception level specifying that a target item of system register state information from said subset of system register state information is to be updated, the processing circuitry determines whether the lockdown control information specifies that the target item of system register state information is in the unlocked state or the locked state; and suppresses the requested update of the target item of system register state information, in response to determining that the lockdown control information specifies that the target item of system register state information is in the locked state. Hence, the system register lockdown control register specifies lockdown control information which is settable by instructions executed in a predetermined exception level (which is not the most privileged exception level), to control whether a system register update triggered by that predetermined exception level can be accepted or should be suppressed. This may be seen as counter-intuitive, since normally one would expect that system register update controls imposed on a given less privileged exception level would be set by instructions executed in a more privileged exception level (so not be writeable in the same exception level whose system register updates are to be policed based on the control). Such controls may be seen as security measures imposed by more privileged software to prevent misbehaviour of less privileged software. As the software executed at a given predetermined exception level may be expected to trust itself, it may be counter-intuitive why it would be useful for that software to set lockdown control information to a locked state to cause its own system register updates to be suppressed. However, a problem that has been identified is that software at a given lower exception level (less privileged than the exception level with maximum privilege) could, even if it trusts its own code, still be vulnerable to being compromised by an attacker, e.g. due to attacks based on return oriented programming which might cause the instructions of the software at the less privileged exception level to be executed in a different order to the one expected by the developer of that software. This might cause system register updates to be executed at the wrong time enabling a portion of the software to be executed with different system register settings to the settings expected for that portion of the software. Alternatively system register update instructions might specify operands set to the wrong value based on the attacker tampering with an earlier sequence of instructions. Executing a portion of the software with the wrong system register settings may be detrimental to system security as it may allow that portion of software to execute with greater privileges than it should have, access regions of memory which it should not access, or otherwise operate in an incorrect manner. Although some system register state information may legitimately need to be updated from time to time during the correct (non-compromised) running of the software executed at the predetermined exception level, there may be other system register state information which once set to a given control setting may not need to change for the remainder of the execution of that software. Hence, the software developer of program code responsible for controlling system register settings will know which items of system register state information need to vary from time to time and which items can remain static once initialised at a given setting. Hence, it can be useful to provide a system register lockdown control register which is settable by instructions executed in the predetermined exception level, to indicate for a subset of items of system register state information whether each item is in a locked state (in which attempts to update that item from the predetermined exception level will not be accepted) or an unlocked state (in which the item of system register state can be updated in response to instructions executed in the predetermined exception level). By providing software executed in the predetermined exception level with a control allowing its own system register updates to be prevented, this can be helpful to provide greater defence against attacks aimed at compromising system register state. Therefore, a processor providing the system register lockdown control register can offer greater security than a processor lacking this control register. In cases where the lockdown control information corresponding to a target item of system register state information sought to be updated by an instruction executed in the predetermined exception level indicates that the target item is in the locked state, the attempt to update the target item is suppressed, to prevent the update being implemented. In some examples, if the lockdown control information corresponding to the target item of system register state information is in the unlocked state, then the update to the target item of system register state information could be permitted. However, this is not essential. In some examples, the lockdown control information may not be the only system register update control provided. For example, there could be other system register state information which also provides further controls, e.g. controls set in a more privileged exception level for controlling whether system register state updates from the predetermined exception level are trapped to the more privileged exception level. In this case, whether or not an update is permitted to the target item of system register state information when the target item is in the unlocked state may depend on other system register state information. Hence, in general, the unlocked state indicates that the lockdown control information specified in the at least one system register lockdown control register is not a barrier to the attempted system register update from the predetermined exception level being permitted, but does not necessarily mean that the system register update can definitely be permitted, as there may be additional checks performed based on other system register state which also have an influence on whether the system register update can be accepted or should cause an exception to be taken. In cases when the update to the target item of system register state information is suppressed based on the lockdown control information being in the locked state, the suppression of the requested update can be handled in different ways. In some examples, the update could be suppressed simply by ignoring the requested update, without taking an exception or otherwise preventing continued execution of the program that included the system register update instruction whose update was suppressed. However, in some examples, in response to determining that the lockdown control information specifies that the target item of system register state information is in the locked state, the processing circuitry may take an exception in the predetermined exception level. By taking an exception to the predetermined exception level if an attempt is made to update locked down system register state information while in the predetermined exception level, the program code operating in the predetermined exception level can be given warning of a potential attack or error that could compromise system security, so that the attack or error can be logged or a response action can be taken. The exception may cause an exception handler to execute which can review the update being requested and decide how to proceed. In some examples, the processing circuitry may permit an instruction (e.g. a system register update instruction) executed in the predetermined exception level to cause an update to the lockdown control information that transitions a given item of system register state information of said subset of system register state information from the unlocked state to the locked state. Hence, the software executing in the predetermined exception level may generally be able to cause items of system register state in the subset controlled by the lockdown control information to be locked down to cause subsequent updates to that state to be prevented. However, the processing circuitry may prohibit an instruction executed in the predetermined exception level from causing an update to the lockdown control information that transitions a given item of system register state information of said subset of system register state information from the locked state to the unlocked state. There could be various ways in which an instruction could be prohibited from causing transitions of a given item of system register state information from the locked state to the unlocked state. For example, an instruction which attempts to cause such a transition could simply be ignored without performing any update, or could cause an exception to be generated. Also, it is possible to provide this limitation on updates to the lockdown control information by masking the attempted update using the old value currently stored in the system register lockdown control register, to ensure that only fields of the system register lockdown control register previously set to the unlocked state can remain in the unlocked state following the update. Regardless of the precise mechanism used to prohibit a given item of system register state from transitioning from the locked state to the unlocked, it can be useful for security reasons to ensure that writes to the lockdown control information are “sticky” such that once a given item of system register state has been locked down by the software executing at the predetermined exception level to cause future updates to be suppressed, it is not possible forthat lockdown setting to be reversed by the software executing at the predetermined exception level. Hence, even if an attacker manages to compromise the software executing at the predetermined exception level, the attacker would not be able to undo the lockdown of the items of system register state that were selected to be locked down by that software executing at the predetermined exception level. Hence, this improves security by reducing vulnerability to attack. On the other hand, the processing circuitry may permit an instruction executed in a more privileged exception level than the predetermined exception level to cause an update to the lockdown control information that transitions a given item of system register state information of said subset of system register state information from the locked state to the unlocked state. This recognises that the more privileged software executing in the more privileged exception level than the predetermined exception level could be managing context switches between two or more different software processes which need to be executed at the predetermined exception level (e.g. different hypervisors or operating systems). As the different processes at the predetermined exception level may desire to impose different settings for the lockdown control information in the system register lockdown control register, it can be useful for the more privileged software to be able to freely update the lockdown control information to any arbitrary setting when context switching between processes which execute at the predetermined exception level. Therefore, the “sticky write” restriction, which prevents items of state transitioning from locked to unlocked during updates of the lockdown control information made from the predetermined exception level, does not apply to updates to the lockdown control information made from the more privileged exception level than the predetermined exception level. Allowing more privileged software to unlock register state can also enable a mechanism to be provided (supported in software by providing an appropriate application programming interface (API) governing interaction between less privileged software and more privileged software) by which software at the predetermined exception level can, on the rare occasions where having locked down an item of system register state it later determines that that system register state needs to be unlocked again, make a supervisor call to the more privileged exception level to request that the more privileged software updates the lockdown control information to transition a particular item of system register state to the unlocked state. The apparatus may comprise reset circuitry responsive to a processor reset event to reset the lockdown control information to specify that each item of said subset of the system register state information is in the unlocked state. Hence, another way in which items of system register state can become unlocked is on a processor reset (an event which resets each storage element of the processor, including the system registers and system register lockdown control register, to a known initial state). In other examples, the lockdown control information could, in response to the processor reset event, be reset to the locked state for each item of the subset of the system register state information. In this case, software executing at the more privileged exception level may, during a boot process to initialize the processor, clear the lockdown control information to indicate that each item of register state is unlocked, before handing control over to the software executing at the predetermined exception level. In other examples, the lockdown control information could, in response to the processor reset event, be reset to any arbitrary combination of locked state and unlocked state for the respective items of system register state in the subset controlled based on the lockdown control information. The lockdown control information controls updates to a subset of system register state information. That subset of system register state information may be information for which the predetermined exception level is the least privileged exception level allowed to update the subset of system register state information. Hence, the lockdown control information in the system register lockdown control register associated with the predetermined exception level may, in some implementations, not influence updates to system register state for which the least privileged exception level allowed to update that system register state is an exception level other than the predetermined exception level. In response to an instruction executed in a less privileged exception level than the predetermined exception level specifying that a selected item of system register state information from said subset of system register state information is to be updated, the processing circuitry may reject the update requested by that instruction irrespective of whether the lockdown control information specifies that the selected item of system register state information is in the locked state or the unlocked state. The update requested by the instruction at the less privileged exception level may be rejected by simply being ignored, or by taking an exception (e.g. to the predetermined exception level). It is not essential for the subset of system register state information (for which updates are controlled based on the at least one system register lockdown control register) to include all items of system register state for which the least privileged exception level allowed to update that item is the predetermined exception level. There can be many different items of system register state information updatable from the predetermined exception level, which would require many bits of lockdown control information to enable full specification of whether each of those items is in the locked or unlocked state, so to limit the total amount of control state required to be provided, architecture designers may make a restricted choice of which items support lockdown controls using the lockdown control register. For example, there may be some items of system register state where the consequences of that item of state being set to the wrong value may be less severe so that there is considered low risk if an attacker manages to cause an incorrect setting to that state, and in that case it may not be necessary for such items of system register state to be part of the subset of system register state for which updates are controlled based on the lockdown control information. The types of system register state information which can be protected based on the lockdown control information can vary, and will depend on the particular instruction set architecture (ISA) implemented by the processing circuitry. Different ISAs require different combination of system register state. However, it can be particularly useful for the subset of system register state information to at least comprise translation table configuration information for defining a configuration of a translation table structure for providing address translation mappings. The translation table structures used to control address translation may also define permissions and attributes used to control secure access to resources in memory, and if an attacker was able to compromise the translation tables by causing translation table configuration information (such as a base address of the translation tables or information defining the way in which translation table walks are performed) to be set incorrectly, the attacker may be able to substitute false translation table data for the correct translation table data to give itself greater memory access privileges, which may have serious consequences for security. Therefore, it can be useful to at least offer the lockdown controls associated with the translation table configuration information, so that once software at the predetermined exception level determines that no further change to the translation table configuration information will be required, the items of system register state providing the translation table configuration information can be locked down to enforce a static translation table configuration and reduce risk of an attacker compromising system security by tampering with translation table settings. Of course, the items of system register state within the subset may also include many other types of system register state, other than the translation table configuration information. The predetermined exception level may be an intermediate exception level less privileged than the most privileged exception level supported by the processing circuitry and more privileged than a least privileged exception level supported by the processing circuitry. The least privileged exception level may be intended for running application software which should not be allowed to update system register state at all, so it may not be needed to provide a system register lockdown control register corresponding to the least privileged exception level. Some exception models may support more than one intermediate exception level and the predetermined exception level may be any of those intermediate exception levels. For example, in some examples the predetermined exception level comprises an exception level with hypervisor-level privilege. A hypervisor is a piece of software responsible for managing virtualisation, which may be responsible for managing two or more guest operating systems running on the same physical platform. Providing at least one system register lockdown control register associated with the exception level having hypervisor-level privilege can be helpful to offer greater defence against attacks aimed at compromising the hypervisor. In some examples, the predetermined exception level comprises an exception level with operating-system-level privilege. The operating system is a piece of software responsible for managing one or more applications running under the control of the operating system. Providing at least one system register lockdown control register associated with the exception level having operating-system-level privilege can be helpful to offer greater defence against attacks aimed at compromising the operating system. In some examples, the at least one system register lockdown control register may be provided only for one particular exception level as the predetermined exception level (e.g. only for one of the exception levels with hypervisor-level privilege or operating-system-level privilege, not both). However, in other examples, respective instances of the at least one system register lockdown control register may be provided, each instance associated with a different exception level as the predetermined exception level (e.g. one instance where the predetermined exception level is the exception level with hypervisor-level privilege, and another instance where the predetermined exception level is the exception level with operating-system-level privilege). This may help to offer defence against attack at multiple exception levels. For the lockdown controls offered at a particular exception level as the predetermined exception level, in some examples there may be only one system register lockdown control register associated with that exception level, if the number of items of system register state in the subset to be protected by lockdown at that exception level is small enough that the bits of control state information to define whether each item is locked or unlocked can fit within a single register. However, in other examples the lockdown control information associated with the predetermined exception level may be distributed across two or more system register lockdown control registers corresponding to the same predetermined exception level. This provides additional storage capacity for specifying lockdown information for a greater number of items of system register state. The lockdown control information may comprise a plurality of lockdown fields each indicating whether a corresponding item of system register state information is in the locked state or the unlocked state. The lockdown fields could be stored within a single system register lockdown control register or within multiple system register lockdown control registers corresponding to the same predetermined exception level. By providing lockdown fields per item of system register state information, fine-grained control is provided allowing any arbitrary setting of whether each individual item of system register state information in the subset is in the locked state or unlocked state. Each lockdown field could, for example, comprise a single bit of control state indicating whether the corresponding item of system register state information is in the locked state or unlocked state, or could comprise a multi-bit value which in addition to indicating whether the item is locked / unlocked could also provide other information using a common encoding that also provides the lockdown control information. Providing separate fields for each item of system register state information can give maximum flexibility for the supported combinations of whether each item of system register state information in the subset is locked or unlocked. However, other encodings are also possible, some of which may restrict which particular combinations of locked / unlocked settings are possible for the respective items of system register state information in the subset. For example, a single control field of the lockdown control information might control whether two or more items of system register state information are in the locked state or unlocked state, with each encoding of that control field corresponding to a different combination of locked / unlocked status for the corresponding two or more items. In examples where lockdown fields are provided as discussed above, the lockdown fields could offer different options for the granularity of control over whether corresponding system register state information is in the locked state or unlocked state. In some examples, for at least one of the lockdown fields, the corresponding item of system register state information comprises contents of at least one entire system register. In some examples, for at least one of the lockdown fields, the corresponding item of system register state information comprises a portion of a given system register for which another portion of the given system register corresponds to a different item of system register state information or is not within the subset of system register state information for which lockdown control information is specified by said at least one system register lockdown control register. Hence, some lockdown fields could control locking down of one or more entire system registers, while other lockdown fields may control locking down of only a sub-portion of a system register without influencing whether other portions of the same system register are also locked down (in that case, those other portions could either have separate lockdown fields offering separate lockdown control, or those other portions may not have any lockdown controls if those other portions correspond to items of system register state not in the subset protected by the lockdown control information). Some examples may support only lockdown fields which lockdown entire system registers. Other examples may support only lockdown fields which lockdown specific sub-portions of system registers. Other examples may support both types of lockdown fields (one or more whole-register lockdown fields in combination with one or more lockdown fields which control locking down of specific sub-portions of system registers). Specific examples are now described with reference to the drawings. Figure 1 schematically illustrates an example of an apparatus 2 comprising processing circuitry 4 and system registers 15. For example, the apparatus 2 may be a portion of a processor such as a central processing unit (CPU). The processing circuitry 4 performs data processing in response to instructions defined according to a given instruction set architecture (ISA) supported by the processing circuitry 4. The ISA defines an exception model in which the processing circuitry is able to execute instructions in one of a set (e.g. a hierarchy) of exception levels associated with different levels of privilege. The ISA also defines the system register control state provided by the system registers 15 for controlling aspects of operation of the processing circuitry 4 when executing instructions. For example, various system registers may be provided to control functions such as operating modes, security state, which instruction set is being executed, whether certain processing operations can be permitted, exception handling, address translation, etc. At least one system register 42 stores system register state information defining the current exception level at which the processing circuitry 4 is executing instructions. Transitions of exception level may occur when the processor takes an exception or returns from processing of a previously taken exception. The system registers 15 also include at least one system register lockdown control register 40 associated with a predetermined exception level, which is used to control whether an update to a given item of system register state information stored in the system registers 15 is allowed when triggered by an instruction executed in the predetermined exception level. The system register lockdown control register(s) 40 can be regarded as a subset of the system registers 15. Figure 2 illustrates steps for controlling an update to system register state information based on lockdown control information stored in the at least one system register lockdown control register 40. At step 100, the processing circuitry 4 executes a system register update instruction at a predetermined exception level (the predetermined exception level being an exception level other than a most privileged exception level supported by the processing circuitry 4). The system register update instruction may be an instruction of the ISA which has an opcode indicating that the type of instruction is a system register update instruction. The system register update instruction may specify one or more operands indicating which particular system register is the target system register to be updated by the instruction and indicating the updated value to be written to that system register. In general, the updated value may define a new setting for at least one target item of system register state information. That target item could be the contents of an entire system register or could be a specific sub-portion of a system register (with other portions of the same system register remaining unchanged). For a subset of system register state information for which the least privileged exception level allowed to update that subset of system register state information is the predetermined exception level, updates to that subset of system register state information are controlled based on lockdown control information specified in the at least one system register lockdown control register 40, which identifies for each item of system register state information in the subset whether that item is a locked state or unlocked state. Items of system register state information not in the subset controlled based on the lockdown control information may by default be considered in the unlocked state. Each system register lockdown control register 40 is writable by system register update instructions executed in the predetermined exception level. Hence, in response the system register updating instruction, at step 102 the processing circuitry 4 determines whether the lockdown control information specified in the at least one system register lockdown control register 40 specifies that the target item of system register state information is in the locked state or the unlocked state. If the target item of system register state information is in the locked state then at step 104 the processing circuitry 4 suppresses the requested update to the target item of system register state information, for example by ignoring the requested update or by taking an exception in the predetermined exception level. If an exception is taken, the processing circuitry 4 interrupts the software routine which comprises the system register updating instruction (without carrying out the update to the target item of system register state requested by the system register updating instruction), and branches to an exception handler executed in the predetermined exception level. The exception handler (implemented in software, so not a required feature of the underlying hardware platform, as the exception handler code may be installed post-manufacture) may for example carry out additional checks to determine whether the update to the target item of system register state information can be permitted. Hence, by suppressing the update or trapping the update to the predetermined exception level, a defence is provided against an attack aimed at compromising the operation of the software running at the predetermined exception level so as to trick the software into executing an inappropriate update to system register state information. The software executing at the predetermined exception level may update the lockdown control information to ensure that items of system register state information not expected to change are set to the locked state to reduce the attack surface available to the attacker and hence increase security against attack. On the other hand, if at step 102 the target item of system register state information is determined to be in the unlocked state (either based on the lockdown control information, or by default if the target item of system register state information is outside the subset of system register state information controlled based on lockdown control information), then at step 106 the processing circuitry 4 permits the requested update to the target item of system register state information, or takes another action depending on other system register state information. For example, in some implementations there may also be additional system register controls which can be set by software executing at a more privileged exception level than the predetermined exception level, which if set may cause the update to the target item of system register state information to be trapped to the more privileged exception level. Hence, if the lockdown control information associated with the predetermined exception level indicates the unlocked state, this indicates that the software executing at the predetermined exception level does not require the update to be rejected as described above for step 104, but it is not necessarily guaranteed that the target item of system register state information can be updated as requested. It may be that more privileged software has set further system register state information which indicates that the update cannot be performed. Figure 3 illustrates a more detailed example of a data processing apparatus 2. Parts of the apparatus 2 of Figure 3 which correspond to similar parts of the apparatus 2 in Figure 1 are shown with the same reference numeral, and so behave as described above for Figures 1 and 2. The data processing apparatus has a processing pipeline 4 (an example of processing circuitry, which could for example form part of a CPU (Central Processing Unit)). The processing circuitry 4 is for executing instructions defined in an instruction set architecture (ISA) to carry out data processing operations represented by the instructions. The processing pipeline 4 includes a number of pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8; a decode stage 10 for decoding the fetched program instructions to generate micro-operations (decoded instructions) to be processed by remaining stages of the pipeline; an issue stage 12 for checking whether operands required for the microoperations are available in a register file 14 and issuing micro-operations for execution once the required operands for a given micro-operation are available; an execute stage 16 for executing data processing operations corresponding to the micro-operations, by processing operands read from the register file 14 to generate result values; and a writeback stage 18 for writing the results of the processing back to the register file 14. It will be appreciated that this is merely one example of possible pipeline arrangement, and other systems may have additional stages or a different configuration of stages. For example in an out-of-order processor a register renaming stage could be included for mapping architectural registers specified by program instructions or microoperations to physical register specifiers identifying physical registers in the register file 14. In some examples, there may be a one-to-one relationship between program instructions defined in the ISA that are decoded by the decode stage 10 and the corresponding micro-operations processed by the execute stage. It is also possible for there to be a one-to-many or many-to-one relationship between program instructions and micro-operations, so that, for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused to be processed as a single micro-operation. The execute stage 16 includes a number of processing units, for executing different classes of processing operation. For example the execution units may include a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from the registers 14; a floating point unit 22 for performing operations on floating-point values; a branch unit 24 for evaluating the outcome of branch operations and adjusting the program counter which represents the current point of execution accordingly; and a load / store unit 26 for performing load / store operations to access data in a memory system 8, 30, 32, 34. A memory management unit (MMU) 28 is provided for controlling memory access permission checks and performing address translations between virtual addresses specified by the load / store unit 26 based on operands of data access instructions and physical addresses identifying storage locations of data in the memory system. The MMU has a translation lookaside buffer (TLB) 29 for caching address translation data from page tables stored in the memory system, where the page table entries of the page tables define the address translation mappings and may also specify access permissions which govern whether a given process executing on the pipeline is allowed to read, write or execute instructions from a given memory region. While the MMU 28 is shown as associated with the load / store unit 26, the MMU 28 may also be looked up on instruction fetches triggered by the fetch stage 6 (or a separate instruction-side MMU may be implemented to handle instruction fetches, separate from the data-side MMU used by the load / store unit 26 for data accesses - in this case both MMUs can cache in their TLBs 29 information from a shared set of page tables). In this example, the memory system includes a level one data cache 30, the level one instruction cache 8, a shared level two cache 32 and main system memory 34. It will be appreciated that this is just one example of a possible memory hierarchy and other arrangements of caches can be provided. The specific types of processing unit 20 to 26 shown in the execute stage 16 are just one example, and other implementations may have a different set of processing units or could include multiple instances of the same type of processing unit so that multiple microoperations of the same type can be handled in parallel. It will be appreciated that Figure 1 is merely a simplified representation of some components of a possible processor pipeline implementation, and the processor may include many other elements not illustrated for conciseness. The registers 14 include general purpose registers 13 and system registers 15. The general purpose registers 13 are used for general purpose operands for instructions and for storing results of instructions, and may be referenced using register fields in instructions which specify a register identifier of the corresponding general purpose register 13. The system registers 15 define system register state information which is used to control the behaviour of the processor 2. For example, system register state information may control address translation by the MMU 28, exception handling by exception control circuitry 36 associated with the processing circuitry 4, caching by caches 8, 30, 32, etc., and may also influence which instruction types and operations are allowed to be performed by the processing circuitry 4 in a particular operating state. Exception control circuitry 36 is provided for controlling exception handling for the processing apparatus 2. Exception signals may be received by the exception control circuitry, to indicate when one of a number of exception conditions has occurred. The exceptions may include a number of types of exception. For example, the decode stage 10 could generate an undefined instruction exception when encountering a fetched instruction which corresponds to an undefined instruction encoding not supported by the apparatus 2 in its current operating state. Also, the MMU 28 could generate an address fault exception if a load / store instruction specifies a target address which either does not have an address mapping defined in the page table structures, or which does have an address mapping defined but for which the corresponding address mapping specifies access permissions which are not satisfied by the software process which issued the load / store instruction. Also, exception signals could be received indicating whether an external interrupt has occurred, for example due to receiving a message from an external device or peripheral, such as a message indicating that a user has pressed a button on the device in which the processing apparatus 2 is included, or that a network controller communicating with an outside network has received a message. The memory system may also generate an exception signal if a memory system error is detected, such as a failure of a check of a parity code or error correction code used to detect errors in stored data caused by events such as random bit flips due to particle strikes, ionising radiation or electronic component aging effects, bus errors due to incorrect control settings on a memory system bus, or other conditions which mean a requested memory system operation cannot be performed correctly. As described in more detail below, another type of exception may be a trap exception triggered when the program executed by the processing circuitry 4 attempts to update system register state in the system registers 15 that, given the current configuration of other system register state which controls which system registers can be updated at a given time, cannot currently be updated. It will be appreciated that many different types of exceptions may be defined and the examples above are not exhaustive. When an exception occurs, the exception control circuitry may use register state in the system registers 15 to determine whether to take the exception, and if the exception should be taken, what operating state the processing circuitry should be in when taking the exception. If an exception is taken then the exception control circuitry 36 interrupts the processing currently being performed by the processing pipeline 4 and controls the pipeline to take an exception, which involves the processing pipeline 4 switching to executing an exception handler which may provide software instructions for responding to the event indicated by the exception type that occurred. Figure 4 is a diagram illustrating different exception levels in which the processing circuitry 4 can operate when executing instructions. In this example there are four exception levels ELO, EL1, EL2, EL3, where exception level ELO is the least privileged exception level and exception level EL3 is the most privileged exception level. In general, when executing in a more privileged exception level, the processing circuitry may have access to some memory locations or registers 14 which are inaccessible to lower, less privileged, exception levels. In this example, exception level ELO is for executing applications which are managed by corresponding operating systems or virtual machines executing at exception level EL1. Where multiple virtual machines coexist on the same physical platform then a hypervisor may be provided operating at EL2, to manage the respective virtual machines. Although Figure 4 shows examples where the hypervisor manages the virtual machines and the virtual machines manage applications, it is also possible for a hypervisor to directly manage applications at ELO (in this case exception level EL1 may be disabled). Although not essential, some implementations may implement separate hardware-partitioned secure and non-secure domains of operation for the processing circuitry. The data processing system 2 may have hardware features implemented within the processor and the memory system to ensure that data and code associated with software processes operating in the secure domain are isolated from access by processes operating in the non-secure domain. For example, a hardware architecture such as the TrustZone® architecture provided by Arm® Limited of Cambridge, UK may be used. Alternatively other hardware enforced security partitioning architectures could be used. Secure applications (trusted services) may operate in exception level ELO in the secure domain and secure (trusted) operating systems or virtual machines may operate in exception level EL1 in the secure domain. In some implementations, there is no support for EL2 in the secure state and the hypervisor may execute solely in non-secure EL2. In other implementations, there may be support for a secure hypervisor executing in secure EL2 as indicated by the asterisk in Figure 2. In some examples, a secure monitor program for managing transitions between the non-secure domain and the secure domain may be provided executing in exception level EL3. Other implementations could police transitions between the security domains in hardware so that the secure monitor program may not be needed. Hence, in summary a number of exception levels are supported, associated with different levels of privilege. Transitions between exception levels occur when an exception is taken or an exception return is performed. Figure 5 shows a subset of system registers 15 supported by the processing circuitry 4. For each system register 15, updates to that register are restricted so that only instructions executed with a given minimum level of privilege are allowed to update that register. The given minimum level of privilege may differ for different system registers 15. A naming convention is shown in Figure 5 in which a suffix _ELx (where x = 1, 2 or 3) in the register name indicates that the least privileged exception level allowed to update that register is ELx. Hence, the system registers 15 may include an “EL3” group of system registers 50 for which only the most privileged exception level EL3 is allowed to update these registers (no updates to those registers being allowed from EL0-EL2); an “EL2” group of system registers 52 for which updates are allowed from either EL2 or EL3 but not ELO or EL1; and an “EL1” group of system registers 54 for which updates are allowed from any of EL1, EL2 or EL3 but not ELO. For ease of explanation, and purely by way of example, each of these groups 50, 52, 54 are shown in Figure 5 as including: a translation table base address register TTBR*_ELx for specifying translation table configuration information (e.g. a base address and / or table format defining information) of a translation table structure used by the MMU 28 to control address translation and to determine access permissions associated with respective regions of memory. While Figure 5 shows a single translation table base address register per exception level, it is possible to provide more than one translation table base address register associated with the same exception level, for defining alternative translation table structures used for translations of different classes of memory access requests; a memory attribute indirection register MAIR_ELx used to define additional memory attributes which can be referenced by translation table entries of the translation tables referenced by TTBR*_ELx; an exception link register ELR_ELx used to store an exception return address to which the processing circuitry 4 should return having completed handling of an exception taken in exception level ELx; a vector base address register VBAR_ELx used to provide a base address of an exception vector table which specifies the addresses of exception handlers to which processing should branch to when various types of exceptions are taken. It will be appreciated that this is just a small fraction of the overall set of system registers that may be provided in practice. Also, while the example of Figure 5 shows the same types of register TTBR, MAIR, ELR, VBAR appearing in each of the EL1, EL2, EL3 groups 54, 52, 50 respectively, it is also possible to provide certain types of system register 15 which are only provided within one or two of the groups 54, 52, 50 (e.g. dedicated EL3 controls not available to EL1 or EL2). As shown in Figure 5, the system registers 50 also include one or more instances of a system register lockdown control register 40 as mentioned earlier. Each system register lockdown control register 40 is associated with a corresponding exception level, referred to as the “predetermined” exception level for a particular instance of the system register lockdown control register, which is the least privileged exception level able towrite to that system register lockdown control register 40. The predetermined exception level is an exception level (e.g. EL1 or EL2) which is less privileged than the most privileged exception level supported by the processing circuitry (e.g. EL3 in the exception model shown in Figure 4, although other ISAs may support additional more privileged exception levels that are more privileged than EL3). In the particular example of Figure 5, there are two instances of system register lockdown control registers 40: an EL2 lockdown control register 40_2, for which the predetermined exception level is the exception level EL2 with hypervisor-level privilege; and an EL1 lockdown control register 40_1, for which the predetermined exception level is the exception level EL1 with operating-system-level privilege. It is not essential to provide both of the EL1 and EL2 versions of the system register lockdown control register 40_1 and 40_2, and other examples may only have one of these control registers 40_1 and 40_2. Each lockdown control register 40 includes a number of lockdown fields 41 each specifying whether a corresponding item of system register state information (selected from the group of system register state 52, 54 for which the least privileged exception level able to write to that system register state information is the predetermined exception level for that lockdown control register 40) is in a locked state or unlocked state. For example, Figure 6 illustrates an example of correspondence between lockdown fields 41 of the EL2 lockdown control register 40_2 and corresponding items of system register state within the group of EL2 system register state 52 for which the least privileged exception level able to write to that state 52 is EL2. As shown in Figure 6, for at least one lockdown field 41, the corresponding item of system register state information may correspond to an entire system register (e.g. the contents of an entire one of the TTBR, MAIR, ELR, VBAR registers shown in Figure 5, or any other system register within the set of register state 52 associated with EL2). On the other hand, it is also possible for some lockdown fields 41 to be provided which correspond to a specified sub-portion of an individual register, not the entire contents of that register. As shown in Figure 6, one system register could include two or more sub-portions of register state which correspond to two or more separate lockdown fields 41. There can also be portions of system register state which do not correspond to any of the lockdown fields 41 (e.g. the portions of system register state shown unshaded in the example of Figure 6) and so are by default considered to be in the unlocked state regardless of the lockdown control information specified by register 40_2. Hence, it is not essential for all of the system register state information within the set of registers 52 designated for update by EL2 to be provided with corresponding lockdown fields 41. In some examples, the lockdown control information provided by system register lockdown control register 40_2 may correspond to only a subset of the system register state that is updatable at the predetermined exception level (EL2 for the specific instance of register 40_2). If a system register lockdown control register is provided for EL1, then it can similarly provide lockdown fields 41 similar to those shown for EL2 in Figure 6, which designate whether corresponding items of state information in the EL1 system registers 54 are either locked or unlocked. In one example, the encoding of each lockdown field 41 may be as follows (although other encodings are also possible): lockdown field = 0: unlocked state. The system register lockdown control register 40 does not require updates to the corresponding item of system register state to be suppressed (although other controls may still cause such updates to be rejected or trapped) lockdown field = 1: locked state. Write accesses to the corresponding item of system register state are prevented, e.g. by being trapped by taking an exception in the predetermined exception level. The system register lockdown control register 40_y associated with a given exception level ELy (y = 1 or 2 in this example) as the predetermined exception level is itself part of the “ELy” group of system registers (e.g. 52 or 54), so that register 40_y can be updated by system instructions executed at the predetermined exception level ELy or a more privileged exception level than ELy. Hence, the register 40_2 is updatable at EL2 or EL3 and the register 40_1 is updatable at EL1, EL2, or EL3. However, write accesses to the lockdown control register 40_y triggered by a system register updating instruction executed at the predetermined exception level ELy itself are “sticky” in the sense that they can only cause a transition of a given lockdown field 41 from the unlocked states to the locked state, but cannot cause any transition of any lockdown field 41 from the locked state to the unlocked state. This provides added security because it means that an attacker compromising the software code running at exception level ELy cannot circumvent the protection provided by the system register lockdown control register 40_y by triggering an update to that register 40_y which unlocks previously locked system register state. However, while writes to the lockdown control register 40_y from ELy are sticky, non-sticky writes (permitting transitions of lockdown fields 41 either from unlocked to locked or from locked to unlocked) are still possible in response to system register updating instructions executed at an exception level more privileged than the predetermined exception level ELy. Hence, any arbitrary update to the EL1 system register lockdown control register 40_1 is allowed when the current exception level is EL2 or EL3, and any arbitrary update to the EL2 system register lockdown control register 40_2 is allowed when the current exception level is EL3. This allows more privileged software to switch between different settings of the lockdown control register 40y when performing context switching between different software processes operating at the predetermined exception level ELy. In summary, the system register lockdown control registers 40_1, 40_2 enable locking down access to other system registers 52, 54 associated with an intermediate exception level ELy, to provide greater defence in depth against runtime compromises to software operating at that exception level ELy. If an attempt is made by an instruction executed at ELy to update an item of system register state for which the corresponding lockdown control information indicates that the item is in the locked state, the update attempt is rejected, e.g. by taking an exception in ELy, allowing an exception handler to review whether the update should be permitted. This may not be the only defence measure against runtime compromises, but may contribute to a set of protection measures that provide defence in depth. Given the sticky write functionality associated with registers 40_1, 40_2, once a given lockdown field is set to the locked state to prevent further updates to the corresponding item of system register state, then that system register state remains locked down (static) unless either: reset circuitry 38 (shown in Figure 3) triggers, in response to an external reset signal, a processor reset event which causes the processor 2 to be reset to a predefined reset state. In some example, the reset state may comprise the lockdown control registers 40_1, 40_2 being set so that each lockdown field 41 is in the unlocked state; or a system register updating instruction is executed in a more privileged exception level which updates the corresponding lockdown field 41 to return the corresponding item of system register state to the unlocked state. Hence, if the software executing at the predetermined exception level ELy needs to cause a particular item of system register state to be updated having already set the corresponding lockdown field 41 to indicate the locked state, then the software at ELy can raise a supervisor call exception (voluntary calling of an exception to request that more privileged software carries out an action), and request that the software at a more privileged exception level either updates the lockdown field 41 corresponding to the item of system register state information to return that item to the unlocked state, or that the more privileged software directly updates the item of system register state information that needs to be updated while retaining that item in the locked state with no change to the corresponding lockdown field 41 of register 40_y. In practice, this scenario is expected to be rare as the software executing at the predetermined exception level ELy would be unlikely to set the lockdown field 41 to the locked state for system register state which is expected to need updating from time to time. While the example of Figure 5 shows a single system register lockdown control register 40 per exception level EL1, EL2, in other examples multiple system register lockdown control registers could be provided for the same exception level EL1 or EL2, to support additional lockdown fields 41 so that the subset of system register state for which lockdown controls are offered can be expanded. The system register lockdown control registers 40 associated with EL1 or EL2 may not be the only form of exception trap controls supported in the system register state 15 for trapping updates to system registers 15. As shown in Figure 5, there can also be an EL3 lockdown control register 44 associated with the most privileged exception level EL3, which provides further lockdown control fields 45 enabling fine grained control over whether system register updating instructions executed in EL3 are allowed to update corresponding items of EL3 register state from the set of EL3 system registers 50 for which the least privileged exception level allowed to update those registers is EL3. Unlike lockdown control registers 40 associated with EL1 or EL2, for the most privileged exception level EL3 there is no need to support context switching by software at a more privileged exception level, so there is no support for “non-sticky” writes to the EL3 lockdown control register 44 which allow updates from the unlocked state to the locked state to be triggered by system register updating instructions. Hence, for the EL3 lockdown control register 44, once a given lockdown field 45 is set to the locked state, the only mechanism to return that field to the unlocked state may be by triggering a processing reset event using the reset circuitry 38. Also, Figure 5 shows an EL1 trap control register 46 for which the least privileged exception level allowed to write to that register 46 is EL2, but which has fields 47 for controlling trapping of updates to items of register state in the EL1 group of registers 54 allowed to be updated by instructions executed at EL1. If a system register updating instruction executed at EL1 attempts to update a given EL1 system register 54 for which the corresponding field 47 in the EL1 trap control register 46 is set to indicate that updates should be trapped, then the processing circuitry 4 takes an exception in EL2. Hence, in contrast to lockdown control registers 40, 44 which, when an update to an item of system register state currently indicated by the register 40, 44 as being in the locked state is attempted, trigger an exception to be taken in the same exception level which attempted the update, the trap control register 46 triggers an exception to be taken in a more privileged exception level than the exception level attempting to update the system register state. Figure 7 illustrates steps for controlling system register updates based on a given instance of the system register lockdown control register 40_y for which the predetermined exception level is ELy (e.g. y = 1 or 2 so that ELy can be either EL1 or EL2). It will be appreciated that some implementations may only support the system register lockdown control register 40 associated with one of exception levels EL1 and EL2. At step 200, a system register updating instruction is executed at a current exception level ELx which attempts to update a target item of system register state information in the set of system registers for which the least privileged exception level allowed to the update the system register is ELy. Current exception level ELx could be any of the exception levels supported by the processing circuitry 4 (i.e. x = 0, 1, 2 or 3). The system register updating instruction specifies an operand identifying which system register is to be updated, and an operand identifying the new value to be updated. In response, at step 202, the processing circuitry 4 determines whether the current exception level ELx is less privileged than the predetermined exception level ELy which defines the minimum level of privilege allowed to update the target item of system register state information. If ELx is less privileged than ELy, then at step 204 the attempted update is rejected irrespective of the current settings for the lockdown control information in the system register lockdown control register 40_y associated with ELy. For example, the update could simply be ignored, or an exception could be taken to ELy or a more privileged exception level. On the other hand, if it is determined at step 206 that ELx is more privileged than the predetermined exception level ELy, then at step 208 the processing circuitry 4 determines whether the update is permitted independent of the lockdown control information defined in the system register lockdown control register 40_y associated with ELy. For example, in some cases the update made at an exception level more privileged than ELy could be always permitted by default. In other cases, other system register controls (separate from system register lockdown control register 40_y) could determine whether at step 208 the update to the target system register is allowed from an exception level more privileged than ELy. If it is determined that the current exception level ELx is ELy (i.e. the system register updating instruction is executed at the predetermined exception level itself), then at step 210 the processing circuitry 4 determines whether the target item of system register state information is in a lockdown-controlled subset of system register state for which trap controls are provided by the lockdown information in the system register lockdown control register 40_y. If not, then at step 212 whether the update is permitted can be determined irrespective of the lockdown control information stored in system register lockdown control register 40_y (as at step 208, whether the update is actually permitted could in some cases depend on other control registers, e.g. on trap controls set by software at an exception level more privileged than ELy). If the target item of system register state information is in the lockdown-controlled subset of system register state (the subset of state for which the lockdown control information 41 in register 40_y is relevant to determining whether to trap the update), then at step 214 the processing circuitry 4 determines whether the lockdown control information specifies that the target item system register state information is in the locked state or the unlocked state. If the target item is in the locked state, then at step 216 the requested update to the target item of system register state information is suppressed. In some examples, the requested update is simply ignored without writing updated information to the target item of system register state information. In other examples, the requested update is trapped and an exception is taken in the predetermined exception level ELy by the processing circuitry 4. If an exception is taken, exception control circuitry 36 causes the processing circuitry 4 to branch to an exception handler which can review the attempted update and determine how to proceed. If the target item of system register state is determined to be unlocked, then while the lockdown control register 40_y does not require any trapping of the update, there could still be other controls (e.g. a control from a more privileged state, such as controls provided by trap control register 46 described earlier) that could require a trap. Hence, if the processing circuitry 4 determines at step 218 that another trap control (e.g. 46) is set to cause the update to the target item system register state information to be trapped to a more privileged exception level, then at step 222 the exception control circuitry 36 controls the processing circuitry 4 to take an exception at the more privileged exception level. If no such trap control exists, or the trap control is currently set not to trap the requested update, then at step 220 the update to system register state requested by the instruction executed at step 200 is permitted, and the register state is updated to the new value specified by the system register updating instruction. It will be appreciated that Figure 7 shows one particular example of operations which could be performed to control the update to system register state. However, the same result could be obtained in other ways. For example, some steps could be reordered or performed at least partially in parallel, rather than sequentially in the particular order shown in Figure 7. Also, in cases where the target item of system register state information is a specific subportion of a register having a separate lockdown field 41 from other portions in the same register, it may be that the encoding of the system register updating instruction encountered at step 200 does not explicitly identify the particular portion of the target system register that is being updated, but merely identifies the target system register and provides a new value for the entire register state in that register (some fields of which may be the same as the previous setting for those fields of that register). In some cases, the processing circuitry 4 could compare the old value currently stored in the target system register with the new updated value specified as an operand of the instruction, to identify which specific target item of system register state is being updated. However, in practice it may not actually be necessary to explicitly identify which particular items of system register state are to be updated within a given register, for the purpose of controlling whether the exception is to be taken at step 216 of Figure 7. In some cases, the circuit logic for determining whether the exception should be taken could, for each item of system register state having a corresponding lockdown field 41, simply generate a logical combination of the old and new values of that item of system register state with the current value of the lockdown field 41, without explicitly comparing the old and new values of that item of system register state. If there is any item of system register state for which the corresponding lockdown field 41 has been set to the locked state and the old and new values for that item of system register state differ, then a signal may be asserted causing the exception to be taken in the predetermined exception level. Hence, it will be appreciated that there are a number of ways in which the processing circuitry could ensure that, if an attempt is made to update a target item of system register state and the corresponding lockdown control information 41 indicates that the target item is in the locked state, an exception is taken in the predetermined exception level ELy. Figure 8 illustrates steps for controlling updates to the system register lockdown control register 40_y associated with the predetermined exception level ELy. At step 300 a system register updating instruction is executed at a current exception level ELx, requesting an update to the ELy variant of the system register lockdown control register 40_y. The system register updating instruction at step 300 of Figure 8 may have the same opcode as the system register updating instruction at step 200 of Figure 7, but may specify a different value for the operand that identifies which system register is to be updated. In general, ELy is the exception level with the minimum privilege allowed to write to system register lockdown control register 40_y. Hence, if the current exception level ELx is determined at step 302 to be less privileged than ELy, then at step 303 the requested update to register 40_y is rejected (either by simply ignoring the update and not writing to the register, or by raising an exception). If the current exception level ELx is determined at step 304 to be more privileged than ELy, then at step 306 the update can be permitted regardless of whether the update causes a transition of an item of ELy’s system register state from the locked state to the unlocked state or from the unlocked state to the locked state. Hence, writes to register 40_y from an exception level more privileged than ELy are non-sticky, and can cause register 40_y to be set to any value. If it is determined that the current exception level ELx is the predetermined exception level ELy associated with register 40_y, then at step 308 it is determined whether the requested update is transitioning a given item of ELy system register state information from the locked state to the unlocked state. If so, then the update is prohibited at step 310 (at least for the given item attempted to be transitioned from locked to unlocked, although in practice it may be simpler and more secure to prohibit the entire update to register 40_y if any field 41 of the register is being updated to the unlocked state having previously been in the locked state, even if there are also fields 41 which are retaining their previous value or being transitioned from unlocked to locked). If the ELy-triggered update to system register lockdown control register 40_y does not cause any item of ELy system register state to transition from the locked state to the unlocked state, then at step 312 the update can be permitted. As for Figure 7, there is flexibility to achieve the same outcome as shown in Figure 8 by a different sequence of operations. For example, rather than an explicit determination of whether a given item of system register state is being transitioned from locked to unlocked, it may be sufficient to mask the requested update so that any fields of the register 40_y which are already set to the locked state are not updated as a result of executing the system register updating instruction in the predetermined exception level ELy. This may be simpler than reviewing the old and new values for each respective field 41 to determine which items are being transitioned from locked to unlocked. For example, for the particular encoding described earlier (0 = unlocked, 1 = locked), the updated value for a given lockdown field 41 of register 40_y can be determined as a logical OR of the old value previously stored in the given lockdown field 41 and the new value for that lockdown field specified as an operand of the system register updating instruction, which will have the effect of ensuring that once locked it is not possible to unlock an item of system register state using a system register updating instruction executed at ELy. On the other hand, for system register updating instructions executed in a more privileged state than ELy, there is no need to mask the update based on the old value of the contents of the register 40_y, and instead the new value specified by the system register updating instruction can simply be written to the register 40_y without being masked. Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein. For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts. Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly. The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated. Such computer-readable code can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept. Figure 9 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 730, optionally running a host operating system 720, supporting the simulator program 710. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 IISENIX Conference, Pages 53 - 63. To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 730), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 710. Thus, the program instructions of the target code 700 described above, may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features. Hence, the simulator program 710 may include processing program logic 712 and system register simulating program logic 714, which emulate functions of the processing circuitry 4 and system registers 15 respectively as described above. The system register simulating program logic 714 controls the host apparatus 730 to emulate within its host storage (e.g. registers or host memory) data structures which correspond to the system registers 15 expected to be provided within a processor supporting the ISA for which the target code 700 is written. In response to an instruction which would require access to a given system register (including the system register lockdown control register 40 described earlier), the system register simulating program logic 714 generates instructions which cause the host hardware 730 to access the corresponding location at which the required item of system register state is stored. The processing program logic 712 includes instructions for decoding instructions of the target code 700 and mapping them to corresponding sequences of instructions defined in the native ISA supported by the host hardware 730, to cause the functionality of each instruction of the target code to be emulated by the host hardware 730. The processing program logic 712 can also simulate processing of these instructions in different exception levels according to the exception model defined for the target ISA for which the target code 700 was written. Hence, in response to a system register update instruction simulated as being executed in the predetermined exception level and requesting an update to a target item of simulated system register state information from said subset of simulated system register state information, the processing program logic 712 may determine whether the lockdown control information (provided by a simulated system register lockdown control register simulated by the system register simulating program logic 714) specifies that the target item of simulated system register state information is in an unlocked state or a locked state; and suppress the requested update in response to determining that the lockdown control information specifies that the target item of simulated system register state information is in the locked state. Such a simulator program 710 can be useful to support development of software for a new ISA before a hardware implementation of a processor supporting that new ISA is actually ready yet. In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. In the present application, lists of features preceded with the phrase “at least one of” mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination. Although illustrative embodiments of the invention have been described in detail herein 5 with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. An apparatus comprising:processing circuitry configured to perform data processing in response to instructions executed in one of a plurality of exception levels supported by the processing circuitry;a plurality of system registers configured to store system register state information; andat least one system register lockdown control register configured to store lockdown control information for controlling updates to a subset of the system register state information, wherein the at least one system register lockdown control register is writable in response to an instruction executed in a predetermined exception level other than a most privileged exception level and the lockdown control information specifies, for each item of system register state information in the subset, whether that item is in a locked state or an unlocked state; wherein:in response to a system register update instruction executed in the predetermined exception level and requesting an update to a target item of system register state information from said subset of system register state information, the processing circuitry is configured to:determine whether the lockdown control information specifies that the target item of system register state information is in the unlocked state or the locked state; andsuppress the update to the target item of system register state information, in response to determining that the lockdown control information specifies that the target item of system register state information is in the locked state.

2. The apparatus according to claim 1, in which the processing circuitry is configured to take an exception in the predetermined exception level, in response to determining that the lockdown control information specifies that the target item of system register state information is in the locked state.

3. The apparatus according to any of claims 1 and 2, in which the processing circuitry is configured to permit an instruction executed in the predetermined exception level to cause an update to the lockdown control information that transitions a given item of system register state information of said subset of system register state information from the unlocked state to the locked state.

4. The apparatus according to any preceding claim, in which the processing circuitry is configured to prohibit an instruction executed in the predetermined exception level from causing an update to the lockdown control information that transitions a given item of system register state information of said subset of system register state information from the locked state to the unlocked state.

5. The apparatus according to any preceding claim, in which the processing circuitry is configured to permit an instruction executed in a more privileged exception level than the predetermined exception level to cause an update to the lockdown control information that transitions a given item of system register state information of said subset of system register state information from the locked state to the unlocked state.

6. The apparatus according to any preceding claim, comprising reset circuitry responsive to a processor reset event to reset the lockdown control information to specify that each item of said subset of the system register state information is in the unlocked state.

7. The apparatus according to any preceding claim, in which the subset of system register state information comprises system register state information for which a least privileged exception level allowed to update the subset of system register state information is the predetermined exception level.

8. The apparatus according to any preceding claim, in which in response to an instruction executed in a less privileged exception level than the predetermined exception level specifying that a selected item of system register state information from said subset of system register state information is to be updated, the processing circuitry is configured to reject the update requested by that instruction irrespective of whether the lockdown control information specifies that the selected item of system register state information is in the locked state or the unlocked state.

9. The apparatus according to any preceding claim, in which the subset of system register state information comprises translation table configuration information for defining a configuration of a translation table structure for providing address translation mappings.

10. The apparatus according to any preceding claim, in which the predetermined exception level comprises an exception level with hypervisor-level privilege.

11. The apparatus according to any of claims 1 to 9, in which the predetermined exception level comprises an exception level with operating-system-level privilege.

12. The apparatus according to any preceding claim, in which the lockdown control information comprises a plurality of lockdown fields each indicating whether a corresponding item of system register state information is in the locked state or the unlocked state.

13. The apparatus according to claim 12, in which for at least one of the lockdown fields, the corresponding item of system register state information comprises contents of at least one entire system register.

14. The apparatus according to any of claims 12 and 13, in which for at least one of the lockdown fields, the corresponding item of system register state information comprises a portion of a given system register for which another portion of the given system register corresponds to a different item of system register state information or is not within the subset of system register state information for which lockdown control information is specified by said at least one system register lockdown control register.

15. Computer-readable code for fabrication of the apparatus of any preceding claim.

16. A storage medium storing the computer-readable code of claim 15.

17. A computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising:processing program logic configured to simulate execution of instructions in one of a plurality of exception levels supported by the processing program logic; andsystem register simulating program logic configured to control access to simulated system register state information and lockdown control information for controlling updates to a subset of the simulated system register state information, the lockdown control information being writeable in response to an instruction simulated by the processing program logic as being executed in a predetermined exception level other than a most privileged exception level, and the lockdown control information specifying, for each item of simulated system register state information in the subset, whether that item is in a locked state or an unlocked state; wherein:in response to a system register update instruction simulated as being executed in the predetermined exception level and requesting an update to a target item of simulated system register state information from said subset of simulated system register state information, the processing program logic is configured to:determine whether the lockdown control information specifies that the target item of simulated system register state information is in an unlocked state or a locked state; andsuppress the update to the target item of simulated system register state information, in response to determining that the lockdown control information specifies that the target item of simulated system register state information is in the locked state.

18. A storage medium storing the computer program of claim 17.

19. A method comprising:in response to a system register update instruction executed by processing circuitry in a predetermined exception level of a plurality of exception levels supported by the processing circuitry, the instruction requesting an update to a target item of system register state information from a subset of system register state information for which updates to the subset of the system register state information are controlled based on lockdown control information stored in at least one system register lockdown control register writeable in response to an instruction executed in the predetermined exception level, the lockdown control information specifying, for each item of system register state information in the subset, whether that item is in a locked state or an unlocked state:determining whether the lockdown control information specifies that the target itemof system register state information is in the unlocked state or the locked state; andsuppressing the update to the target item of system register state information, in response to determining that the lockdown control information specifies that the target item of system register state information is in the locked state.