WO2017137713A1 - An apparatus and method for controlling use of bounded pointers - Google Patents
An apparatus and method for controlling use of bounded pointers Download PDFInfo
- Publication number
- WO2017137713A1 WO2017137713A1 PCT/GB2016/054054 GB2016054054W WO2017137713A1 WO 2017137713 A1 WO2017137713 A1 WO 2017137713A1 GB 2016054054 W GB2016054054 W GB 2016054054W WO 2017137713 A1 WO2017137713 A1 WO 2017137713A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- pointer
- capability
- bounded
- bounded pointer
- signing
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 88
- 238000012545 processing Methods 0.000 claims abstract description 82
- 238000013475 authorization Methods 0.000 claims description 64
- 230000008859 change Effects 0.000 claims description 20
- 230000001419 dependent effect Effects 0.000 claims description 19
- 230000004048 modification Effects 0.000 claims description 14
- 238000012986 modification Methods 0.000 claims description 14
- 230000004044 response Effects 0.000 claims description 5
- 230000004075 alteration Effects 0.000 claims description 3
- 238000013459 approach Methods 0.000 abstract description 23
- 230000008569 process Effects 0.000 description 77
- 230000006870 function Effects 0.000 description 28
- 230000009471 action Effects 0.000 description 21
- 238000010586 diagram Methods 0.000 description 18
- 150000003839 salts Chemical class 0.000 description 12
- 230000001960 triggered effect Effects 0.000 description 7
- 238000013519 translation Methods 0.000 description 6
- 238000003780 insertion Methods 0.000 description 5
- 230000037431 insertion Effects 0.000 description 5
- 238000012360 testing method Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 4
- 230000000717 retained effect Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 238000007792 addition Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 230000006266 hibernation Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000003334 potential effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 201000009032 substance abuse Diseases 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/12—Protecting executable software
- G06F21/121—Restricting unauthorised execution of programs
- G06F21/125—Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
- G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
- G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/12—Protecting executable software
- G06F21/121—Restricting unauthorised execution of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/10—Providing a specific technical effect
- G06F2212/1052—Security improvement
Definitions
- the present technique relates to the field of data processing.
- Some data processing apparatuses may support bounded pointers where a pointer indicating a particular address is associated with range information indicating an allowable range of addresses for the pointer.
- pointers may be referred to as "fat pointers”.
- CFI control flow integrity
- an apparatus comprising: storage to store bounded pointers, each bounded pointer comprising a pointer value and associated attributes, the associated attributes including range information indicative of an allowable range of addresses when using said pointer value; and processing circuitry to perform a signing operation on an input bounded pointer in order to generate an output bounded pointer in which a signature generated by the signing operation is contained within the output bounded pointer in place of specified bits of the input bounded pointer; the associated attributes including signing information which is set by the processing circuitry within the output bounded pointer to identify that the output bounded pointer has been signed.
- a method of controlling use of bounded pointers comprising: storing bounded pointers in a storage, each bounded pointer comprising a pointer value and associated attributes, the associated attributes including range information indicative of an allowable range of addresses when using said pointer value; performing a signing operation on an input bounded pointer in order to generate an output bounded pointer in which a signature generated by the signing operation is contained within the output bounded pointer in place of specified bits of the input bounded pointer; and setting signing information within the associated attributes of the output bounded pointer to identify that the output bounded pointer has been signed.
- an apparatus comprising: storage means for storing bounded pointers, each bounded pointer comprising a pointer value and associated attributes, the associated attributes including range information indicative of an allowable range of addresses when using said pointer value; and processing means for performing a signing operation on an input bounded pointer in order to generate an output bounded pointer in which a signature generated by the signing operation is contained within the output bounded pointer in place of specified bits of the input bounded pointer; the processing means further for setting signing information within the associated attributes of the output bounded pointer to identify that the output bounded pointer has been signed.
- FIG. 1 is a block diagram of an apparatus in accordance with one embodiment
- Figure 2 shows examples of types of instruction for which an error may be triggered if there is an attempt to set or access a pointer value within the set of bounded pointer storage elements, where that pointer value is used to specify an address outside the range indicated by the associated range information;
- FIG. 3 illustrates the use of a tag bit in association with bounded pointers, in accordance with one embodiment
- Figure 4 schematically illustrates a signing operation and a subsequent authorisation operation in accordance with one embodiment
- Figure 5 illustrates the use of signing information within the associated attributes of a bounded pointer in accordance with one embodiment
- Figure 6 is a flow diagram illustrating a signing operation in accordance with one embodiment
- Figure 7 is a flow diagram illustrating an authorisation operation in accordance with one embodiment
- Figure 8 illustrates an example arrangement where the range information of a bounded pointer is stored relative to the pointer value of that bounded pointer
- Figure 9 is a flow diagram illustrating an operation performed to ensure the immutability of a signed capability (also referred to as a signed bounded pointer) in accordance with one embodiment
- Figure 10 is a flow diagram illustrating a sequence of operations that may be performed when modifications to the pointer value of a signed capability are permitted, in accordance with one embodiment
- Figure 11 is a flow diagram illustrating a dereferencing operation performed in accordance with one embodiment
- Figure 12 is a flow diagram illustrating how a capability signing operation may be limited to situations where the input capability is not yet already signed, in accordance with one embodiment
- Figure 13 is a flow diagram illustrating a stripping operation performed in accordance with one embodiment
- Figures 14A to 14C illustrate various example checks that may be performed in some embodiments in order to determine whether stripping is permitted
- Figure 15 illustrates an alternative signed capability encoding in accordance with one embodiment
- Figures 16A and 16B are flow diagrams illustrating a signing operation and an authorisation operation, respectively, in embodiments where the signature is added to the bound information in accordance with the approach of Figure 15;
- Figure 17 is a diagram schematically illustrating a reconstruction process that may be used to reconstruct capabilities from data held in a backing store, in accordance with one embodiment
- Figure 18 is a flow diagram illustrating the capability reconstruction process that may be performed in accordance with one embodiment.
- Figures 19A to 19C illustrate various checks that may be performed in some embodiments in order to determine whether signing is permitting during such a capability reconstruction process.
- Some processing apparatuses may support the use of bounded pointers.
- the pointer itself may point to, or be used to determine, the address of a data value to be accessed or an instruction to be executed, for example.
- the pointer may also have associated range information which indicates an allowable range of addresses when using the pointer. This can be useful for example for ensuring that the address determined from the pointer remains within certain bounds to maintain security or functional correctness of behaviour. For example, there is increasing interest in capability-based architectures in which certain capabilities are defined for a given process, and an error can be triggered if there is an attempt to carry out operations outside the defined capabilities.
- the range information for a bounded pointer may be part of the capability information defined for such an architecture, and within a capability-based architecture such a bounded pointer (including its associated capability information) may be referred to as a capability.
- an apparatus may have bounded pointer storage elements used to store a pointer having associated range information indicative of an allowable range of addresses when using the pointer.
- Each bounded pointer storage element could be a register, or a memory location in general purpose memory, for example a location on a stack memory.
- Certain instructions can be used to reference such a bounded pointer storage element in order to obtain a pointer which is then used to derive an address in memory required during operation of the instruction.
- the pointer may be used directly to identify the memory address, or may be used to derive the memory address, for example by the addition of an offset to the pointer value.
- the associated range information can limit the range of addresses that may be targeted by a branch instruction when deriving the target address from the pointer stored in a bounded pointer storage element.
- capability-based architectures it is also known to provide mechanisms that prevent generic data being used as a capability to derive branch target addresses, and further the locations in which certain capabilities can be maintained may be restricted.
- a rogue process it is still possible for a rogue process to manipulate bounded pointers in a manner that can give rise to the intended flow of control through a computer program being subverted, for example by enabling control to be transferred to an unexpected program address.
- an apparatus has storage used to store bounded pointers, where each bounded pointer comprises a pointer value and associated attributes, and where the associated attributes include range information indicative of an allowable range of addresses when using the pointer value.
- a mechanism is provided to allow bounded pointers to be signed.
- processing circuitry within the apparatus is arranged to perform a signing operation on an input bounded pointer in order to generate an output bounded pointer in which a signature generated by the signing operation is contained within the output bounded pointer in place of specified bits of the input bounded pointer.
- the associated attributes of the bounded pointer are arranged to include signing information, and the processing circuitry sets the signing information within the output bounded pointer to identify that the output bounded pointer has been signed.
- task A signs a bounded pointer that it is later to use as a return address
- another task B seeks to modify that bounded pointer with the aim of seeking to modify the return address to be used by task A, even if task B can bring about a modification to the pointer it is extremely likely that the modified bounded pointer will later fail the authorisation process performed by task A since task B will not typically be privy to the information used by task A when performing the signing operation.
- the associated attributes of the bounded pointer are used to identify whether the bounded pointer has been signed or not.
- a check can be made with reference to the associated attributes to determine whether the input bounded pointer is signed or not, and the actions performed can be modified dependent on whether the input bounded pointer is signed or not.
- the apparatus can be readily arranged to prevent certain actions being performed in respect of signed bounded pointers, thereby providing further enhanced security.
- the processing circuitry is arranged, for at least one requested operation requiring use of a bounded pointer within the storage, to determine from the signing information within the associated attributes whether that bounded pointer is signed or unsigned, and to determine processing steps to be taken in response to the requested operation dependent on whether the bounded pointer is identified by the signing information as being signed or unsigned.
- the processing circuitry is able to control the extent to which operations which may be performed on unsigned bounded pointers are allowed to be performed on signed bounded pointers.
- the processing circuitry can prohibit signed bounded pointers from being modified, may prohibit the use of a signed bounded pointer during a dereferencing operation, i.e. where the pointer value of the bounded pointer is to be used to identify an address in memory, to prohibit signing of a bounded pointer that is already signed, etc.
- the operation is not prohibited, there may still be placed some constraints on the operation once it is known that the input bounded pointer is a signed bounded pointer.
- some constraints on the operation may be placed, in some embodiments it may be possible to perform some modifications to a signed bounded pointer, but not necessarily all possible modifications that could be performed on an unsigned bounded pointer, and by using the signing information of the input bounded pointer to determine whether it is signed or unsigned, the requested operation can be controlled accordingly.
- the signing information can take a variety of forms.
- the signing information is a signing bit which is set within the associated attributes to indicate that the bounded pointer is signed, and which is cleared within the associated attributes to indicate that the bounded pointer is unsigned. Accordingly, in such an embodiment a dedicated signing bit is included within the associated attributes to be set or cleared dependent on whether the associated bounded pointer is signed or unsigned.
- the value of the signing bit used to indicate a set state and the value used to indicate a cleared state can vary dependent on embodiments, and hence whilst in one implementation a value of 1 may indicate a set state and a value of 0 may indicate a cleared state, in an alternative embodiment a value of 0 may indicate a set state and a value of 1 may indicate a cleared state.
- the signing information may be encoded within a multi-bit field also used to identify at least one other property of the bounded pointer. In some instances this may provide a more efficient use of the available attribute space.
- the processing circuitry may be arranged to prevent the signing operation being performed unless a specified condition is met.
- the specified condition may take a variety of forms, but in one embodiment is arranged to ensure that a subsequent unsigning of the output bounded pointer will not generate a bounded pointer that differs from the original input bounded pointer.
- the bounded pointer effectively having sufficient free space within the encoding to allow the signature to be inserted.
- the specified condition may be such that it is met when the specified bits of the input bounded pointer (i.e. the bits used to accommodate the signature in the signed version) comprise information that is reproducible from other bits of the input bounded pointer.
- the specified bits may contain actual information defining a part of the bounded pointer, such as part of the pointer value or part of the range information
- the values within those specified bits are directly reproducible from a knowledge of remaining bits of the input bounded pointer, and accordingly are effectively redundant and can be overwritten by the signature without loss of that information.
- the processing circuitry may be arranged to prevent the input bounded pointer from being signed, and instead to take a predetermined action.
- the predetermined action can take a variety of forms, but may for example involve invalidating the input bounded pointer, or raising a processor fault in order to take an exception.
- the processing circuitry is arranged to prohibit a bounded pointer from being used to determine an address to be accessed in memory whilst the bounded pointer is signed.
- the processing circuitry can refer to the signing information in the associated attributes to determine whether the bounded pointer is signed or unsigned, and then prevent the bounded pointer being used if it is a signed bounded pointer. This provides enhanced security, without needing to rely on the form of the signed bounded pointer itself preventing the generation of an accessible memory address.
- the processing circuitry is arranged to generate the signature using at least a portion of the pointer value. In some embodiments, the entirety of the pointer value is used when generating the signature. In addition to using at least a portion of the pointer value, the processing circuitry is arranged in one embodiment to also use a signing key and an item of contextual data when generating the signature.
- the signing key may be known by a number of entities within the apparatus, for example a number of different tasks
- the item of contextual data is intended to be data known only by the entity causing the signing to take place, and optionally by one or more other related entities, and as a result this significantly reduces the probability that an entity that is not in possession of that item of contextual data could successfully unsign such a signed bounded pointer.
- a signed bounded pointer may be arranged to be unsigned.
- the processing circuitry is responsive to an authorisation request to perform an authorisation operation on an input signed bounded pointer in order to generate an output unsigned bounded pointer provided a signature match is detected between the signature contained within the input signed bounded pointer and an authorisation signature generated by the processing circuitry using at least a portion of the pointer value provided within the signed bounded pointer.
- the processing circuitry is arranged to generate the authorisation signature using a signing key and an item of contextual data, in addition to the earlier-mentioned at least a portion of the pointer value that is provided within the signed bounded pointer.
- the item of contextual data in both the signing and the authorisation process, this significantly reduces the probability of an unauthorised entity performing a successful authorisation of a signed bounded pointer.
- the processing circuitry when the signature match is detected, is arranged to generate the output unsigned bounded pointer by replacing the signature with data determined from one or more bits of the input signed bounded pointer, and clearing the signing information within the associated attributes to identify that the output bounded pointer is unsigned.
- the processing circuitry when a bounded pointer is unsigned the processing circuitry is arranged to interpret the pointer value as being specified by a default plurality of bits of the bounded pointer that includes said specified bits, and when a bounded pointer is signed the processing circuitry is arranged to interpret the pointer value as being specified by a reduced plurality of bits that excludes said specified bits.
- the range information may be specified relative to the pointer value.
- the encoding space for the bounded pointer is quite limited, and a more efficient encoding of the range information can be achieved by specifying the range relative to the pointer value, rather than providing absolute range information.
- the processing circuitry may need to be responsive to an operation that causes the pointer value to be altered, to also adjust the range information to ensure that the range specified by the range information is not changed as a result of the alteration to the pointer value.
- the range information of a bounded pointer can only be changed under certain, very controlled, situations, and that general changes to the pointer value should not cause any change to the range information.
- a signed bounded pointer may only be converted back into an unsigned state by the earlier mentioned authorisation operation
- the processing circuitry is arranged to be responsive to a strip request to perform a strip operation on an input signed bounded pointer in order to generate an output unsigned bounded pointer provided a strip condition is met, the processing circuitry being arranged, when the strip condition is met, to generate the output unsigned bounded pointer by replacing the signature with data determined from one or more bits of the input signed bounded pointer, and clearing the signing information within the associated attributes to identify that the output bounded pointer is unsigned.
- strip operation is potentially a quite powerful mechanism, since it does not require the signature match that is required when performing the earlier- mentioned authorisation operation. Accordingly, in one embodiment, use of the strip operation is restricted to situations where a strip condition is met.
- the strip condition can take a variety of forms.
- the strip condition is determined to be met if the processing circuitry is operating in a predetermined privileged state. Accordingly, the use of the strip operation is restricted to certain privileged code executed by the processing circuitry.
- a configuration storage element for example a configuration register
- the strip condition is determined to be met if that configuration storage element has a value indicating that the strip operation is permitted.
- the strip request may itself identify a strip capability stored within the storage.
- the strip request may take the form of a strip instruction that identifies the strip capability as one of the input operands, another operand identifying the signed bounded pointer that is to be subjected to the strip operation.
- the identified strip capability is then retrieved from the storage, and the strip operation is only permitted to proceed if the strip capability indicates that performance of the strip operation is permitted.
- strip condition Whilst the above three options for the strip condition may be used in three different embodiments, in one embodiment multiple of them may be employed together, such that the strip condition is determined to be met if any one or more of those conditions is met.
- the processing circuitry may be arranged to be responsive to determining, from the signing information of the input bounded pointer, that the input bounded pointer is already signed, to prevent the signing operation from being performed.
- the signing information is itself used to control instances in which the signing operation can be performed.
- the processing circuitry is arranged to perform the signing operation when executing a signing instruction within a set of instructions.
- the processing circuitry may be arranged to perform an authorisation operation to unsign a signed bounded pointer when executing an authorisation instruction within the set of instructions.
- a specific strip instruction may be provided within the instruction set for execution by the processing circuitry to implement such a strip operation.
- Additional instructions may be arranged purely to perform the signing or unsigning operations, or alternatively may be arranged to perform at least one further operation in addition to the signing or unsigning operation.
- the specified bits of the input bounded pointer that are replaced with the signature contain a portion of the pointer value.
- those specified bits contain a portion of the range information.
- the processing circuitry may be arranged to determine that the specified condition is met when a range specified by the range information is representable within a remaining portion of the range information. This may be due to a determination that there is sufficient redundancy in the range information as originally specified to accommodate a signature without any loss of information. Alternatively, it may be decided that whilst there is not initially sufficient redundancy, it is possible to reduce the precision of the range information in order to create sufficient redundancy, and in that instance the range information is then specified with the reduced precision within the signed bounded pointer.
- Figure 1 schematically illustrates an example of a data processing apparatus 2 comprising a processing pipeline 4 for processing instructions.
- the processing pipeline 4 includes a number of pipeline stages including a fetch stage 6, a decode stage 8, an issue stage 10, an execute stage 12, and a write back stage 14, but it will be appreciated that other types or combinations of stages may be provided.
- a rename stage for performing register renaming could be included in some embodiments. Instructions to be processed move from stage to stage, and while an instruction is pending at one stage another instruction may be pending at a different stage of the pipeline 4.
- the fetch stage 6 fetches instructions from a level 1 (LI) instruction cache 20.
- the fetch stage 6 may usually fetch instructions sequentially from successive instruction addresses.
- the fetch stage may also have a branch predictor 22 for predicting the outcome of branch instructions, and the fetch stage 6 can fetch instructions from a (non- sequential) branch target address if the branch is predicted taken, or from the next sequential address if the branch is predicted not taken.
- the branch predictor 22 may include one or more branch history tables for storing information for predicting whether certain branches are likely to be taken or not.
- the branch history tables may include counters for tracking the actual outcomes of previously executed branches or representing confidence in predictions made for branches.
- the branch predictor 22 may also include a branch target address cache (BTAC) 24 for caching previous target addresses of branch instructions so that these can be predicted on subsequent encounters of the same branch instructions.
- BTAC branch target address cache
- the fetched instructions are passed to the decode stage 8 which decodes the instructions to generate decoded instructions.
- the decoded instructions may comprise control information for controlling the execute stage 12 to execute the appropriate processing operations.
- the decode stage 8 may map those instructions to multiple decoded instructions, which may be known as micro-operations ( ⁇ 8 or uops). Hence, there may not be a one-to-one relationship between the instructions fetched from the LI instruction cache 20 and instructions as seen by later stages of the pipeline.
- references to "instructions" in the present application should be interpreted as including micro-operations.
- the decoded instructions are passed to the issue stage 10, which determines whether operands required for execution of the instructions are available and issues the instructions for execution when the operands are available.
- Some embodiments may support in-order processing so that instructions are issued for execution in an order corresponding to the program order in which instructions were fetched from the LI instruction cache 20.
- Other embodiments may support out- of-order execution, so that instructions can be issued to the execute stage 12 in a different order from the program order. Out-of-order processing can be useful for improving performance because while an earlier instruction is stalled while awaiting operands, a later instruction in the program order whose operands are available can be executed first.
- the issue stage 10 issues the instructions to the execute stage 12 where the instructions are executed to carry out various data processing operations.
- the execute stage may include a number of execute units 30, 32, 34 including an arithmetic/logic unit (ALU) 30 for carrying out arithmetic or logical operations on integer values, a floating-point (FP) unit 32 for carrying out operations on values represented in floating-point form, and a load/store unit 34 for carrying out load operations for loading a data value from a level 1 (LI) data cache 36 to a register 40 or store operations for storing a data value from a register 40 to the LI data cache 36.
- ALU arithmetic/logic unit
- FP floating-point
- load/store unit 34 for carrying out load operations for loading a data value from a level 1 (LI) data cache 36 to a register 40 or store operations for storing a data value from a register 40 to the LI data cache 36.
- the execute stage 12 may read data values from a set of registers 40. Results of the executed instructions may then
- the LI instruction cache 20 and LI data cache 36 may be part of a cache hierarchy including multiple levels of caches.
- a level two (L2) cache 44 may also be provided and optionally further levels of cache could be provided.
- the L2 cache 44 is shared between the LI instruction cache 20 and LI data cache 36 but other examples may have separate L2 instruction and data caches.
- L2 cache 44 When an instruction to be fetched is not in the LI instruction cache 20 then it can be fetched from the L2 cache 44 and similarly if the instruction is not in the L2 cache 44 then it can be fetched from main memory 50.
- data can be fetched from the L2 cache 44 if it is not in the LI data cache 36 and fetched from memory 50 if required. Any known scheme may be used for managing the cache hierarchy.
- the addresses used by the pipeline 4 to refer to program instructions and data values may be virtual addresses, but at least the main memory 50, and optionally also at least some levels of the cache hierarchy, may be physically addressed.
- a translation lookaside buffer 52 may be provided for translating the virtual addresses used by the pipeline 4 into physical addresses used for accessing the cache or memory.
- the TLB 52 may include a number of entries each specifying a virtual page address of a corresponding page of the virtual address space and a corresponding physical page address to which the virtual page address should be mapped in order to translate the virtual addresses within the corresponding page to physical addresses.
- each TLB entry may also include some information specifying access permissions such as indicating whether certain pages of addresses are accessible in certain modes of the pipeline 4.
- the TLB entries could also define other properties of the corresponding page of addresses, such as cache policy information defining which levels of the cache hierarchy are updated in response to read or write operations (e.g. whether the cache should operate in a write back or write through mode), or information defining whether data accesses to addresses in the corresponding page can be reordered by the memory system compared to the order in which the data accesses were issued by the pipeline 4.
- FIG. 1 shows a single level TLB 52
- a hierarchy of TLBs may be provided so that a level one (LI) TLB 52 may include TLB entries for translating addresses in a number of recently accessed pages and a level two (L2) TLB may be provided for storing entries for a larger number of pages.
- LI TLB level one
- L2 TLB level two
- a required entry is not present in the LI TLB then it can be fetched from the L2 TLB, or from further TLBs in the hierarchy. If a required entry for a page to be accessed is not in any of the TLBs then a page table walk can be performed to access page tables in the memory 50. Any known TLB management scheme can be used in the present technique.
- some systems may support multiple levels of address translation so that, for example, a first TLB (or hierarchy of TLBs) may be used to translate virtual addresses into intermediate addresses, and a second level of address translation using one or more further TLB(s) may then translate the intermediate addresses into physical addresses used to access a cache or memory.
- a first TLB or hierarchy of TLBs
- a second level of address translation using one or more further TLB(s) may then translate the intermediate addresses into physical addresses used to access a cache or memory.
- This can be useful for supporting virtualisation where the first level of address translation may be managed by the operating system and the second level of address translation may be managed by the hypervisor, for example.
- the apparatus 2 may have a set of bounded pointer registers 60. Whilst the set of bounded pointer registers is shown in Figure 1 as being physically separate to the set of general purpose data registers 40, in one embodiment the same physical storage may be used to provide both the general purpose data registers and the bounded pointer registers.
- Each bounded pointer register 60 includes a pointer value 62 that may be used to determine an address of a data value to be accessed, and range information 64 specifying an allowable range of addresses when using the corresponding pointer 62.
- the bounded pointer register 60 may also include restrictions information 66 (also referred to herein as permissions information) which may define one or more restrictions/permissions on the use of the pointer.
- restrictions information 66 also referred to herein as permissions information
- the restriction 66 could be used to restrict the types of instructions which may use the pointer 62, or the modes of the pipeline 4 in which the pointer can be used.
- the range information 64 and restriction information 66 may be considered to define capabilities within which the pointer 62 is allowed to be used.
- the range information 64 can be useful for example for ensuring that pointers remain within certain known bounds and do not stray to other areas of the memory address space which might contain sensitive or secure information.
- the pointer value 62 may for example be stored within the same storage location as used for a corresponding general purpose register.
- Figure 2 shows an example of types of instructions for which the allowable range is used to protect against unauthorised access to data or instructions.
- a particular bounded pointer register PR1 includes a given pointer value 62 and range information 64, which in this example is specified using a lower bound address 68 defining the lower bound of the allowable range and an upper bound address 69 defining the upper bound of the allowable range.
- the bounds 68, 69 are set to define a range of addresses 80000 to 81000. Errors may be triggered when certain instructions reference the bounded pointer register PR1 and the address determined from the pointer 62 is outside this range.
- an error may be triggered if there is an attempt to set the value of the pointer 62 in the pointer register 60 to a value lying outside the range specified by the range information 64 (here it being assumed that the pointer directly specifies an address). This avoids the pointer 62 taking any value outside the specified range so that any accesses using the pointer can be ensured to lie safely within the allowed range.
- an error can be triggered when an instruction attempts to access a location identified by the address of the pointer 62 when that address lies outside the specified range.
- the range information 64 could be set in different ways.
- secure code or an operating system or hypervisor, may specify the range allowed for a given pointer.
- the instruction set architecture may include a number of instructions for setting or modifying the range information 64 for a given pointer 62, and execution of these instructions could be restricted to certain software or certain modes or exception states of the processor 4. Any known technique for setting or modifying the range information 64 could be used.
- a program counter capability (PCC) register 80 may also be used to provide similar functionality at the fetch stage 6 when instructions are being fetched from the level one instruction cache 20.
- a program counter pointer may be stored in a field 82, with the PCC 80 also providing range information 84 and any appropriate restriction information 86, similar to the range and restriction information provided with each of the pointers in the set of bounded pointer storage elements 60.
- FIG. 3 schematically illustrates how a tag bit is used in association with individual data blocks to identify whether those data blocks represent a capability (i.e. a bounded pointer and associated restrictions information), or represent normal data.
- the memory address space 110 will store a series of data blocks 115, which typically will have a specified size.
- each data block comprises 128 bits.
- a tag field 120 which in one example is a single bit field referred to as the tag bit, which is set to identify that the associated data block represents a capability, and is cleared to indicate that the associated data block represents normal data, and hence cannot be treated as a capability.
- the tag bit moves with the capability information. Accordingly, when a capability is loaded into the capability register 100, the pointer 102, range information 104 and restrictions information 106 (hereafter referred to as the permissions information) will be loaded into the capability register. In addition, in association with that capability register, or as a specific bit field within it, the tag bit 108 will be set to identify that the contents represent a capability. Similarly, when a capability is stored back out to memory, the relevant tag bit 120 will be set in association with the data block in which the capability is stored. By such an approach, it is possible to distinguish between a capability and normal data, and hence ensure that normal data cannot be used as a capability.
- Figure 4 is a diagram schematically illustrating a signing operation that may be used to convert an unsigned capability into a signed capability, and a corresponding authorisation operation that may subsequently be used to convert the signed capability back into an unsigned capability.
- An unsigned capability 150 (also referred to as an unsigned bounded pointer) is provided as an input operand for the signing operation, the capability 150 comprising a pointer portion 155 and an attributes portion 160. Within the pointer portion 155 a pointer value is specified, and within the attribute portion 160 range information is specified, along with various permissions information indicative of allowed uses of the pointer value provided within the unsigned capability.
- the permissions information may identify for which type of operations the pointer is allowed to be referenced, and hence for example whether the pointer can be used to identify data to load or store, to identify instructions to be fetched, etc.
- a tag bit 165 is provided, which is set to identify that the associated block of information represents a capability.
- the size of the capabilities may be varied dependent on implementation, but consistent with the earlier-described example where a capability comprises 128 bits then in one embodiment the pointer portion 155 may comprise 64 bits, and the attributes portion 160 may also comprise 64 bits.
- the cryptographic signing function 170 used to convert the unsigned capability into a signed capability receives a number of inputs that are used to derive the signature to be added to form the signed capability.
- the function 170 has access to a cryptographic signing key, and in addition has access to a salt value.
- the salt value can take a variety of forms, but in one embodiment represents contextual information that will only be available to a task or tasks that will legitimately need to unsign the signed capability, and hence which should be able to successfully perform an authorisation operation in respect of the signed capability.
- the contextual information can take a variety of forms, but in one embodiment may for example be a stack pointer location that will only be known to the task or tasks that will legitimately want to authorise the signed capability.
- the function 170 receives at least a portion of the pointer value stored within the pointer portion 155.
- the pointer value will comprise a certain number of unique pointer bits, with the remaining most significant bits being either a sign- extended version of the unique pointer bits (hence being all ones or all zeros depending on the most significant bit of the unique pointer bits), or a zero-extended version of the unique pointer bits (i.e. all zeros).
- this essentially redundant information in a certain number of the most significant bits of the pointer value is used as a location in which to insert the signature once generated, thereby enabling the signature to be incorporated within the signed capability without any loss of information.
- the process may be arranged to insert the signature into another part of the capability, for example within a number of the bits of the attribute portion 160, as for example will be discussed later with reference to the embodiment of Figure 15.
- it may be the case that there are sufficient unused bits within the unsigned capability encoding that those unused bits can be used within the signed capability to hold the signature value.
- the process may be arranged so that only the unique pointer bits are used as an input to the cryptographic signing function 170 rather than the entire pointer value. Irrespective of which approach is taken, if the signature is to be added in the upper portion of the pointer value within the signed capability, the process of the described embodiment will perform a check to ensure that the pointer is "canonical" such that the signing field (i.e. the portion of the pointer value that is to be overwritten with the signature) contains a sign-extended or zero- extended version of the unique pointer bits.
- this check can be performed. For example, in one embodiment a check is performed to ensure that this condition is true before signing, as will be discussed later with reference to the example of Figure 6.
- a test authentication after signing process could be incorporated within the function 170 in order to compare the original capability against the authorised capability (i.e. the capability created after authenticating the signed capability).
- a signing field 182 is provided, which is set to identify that the capability 175 is a signed capability, and in addition the tag bit 185 is retained in the set state to indicate that the associated 128 bits of data represent a capability.
- an authorisation function 190 can be invoked in order to seek to unsign the signed capability 175. Firstly the unique pointer bits 177 are identified, and then subjected to a sign-extending operation 192 in order to generate the original pointer value that was used at the time the signing function 170 was performed. If the original pointer value was expressed in a zero-extended format, then at step 192 a zero-extending operation would instead be performed. Furthermore, if only the unique pointer bits had been used as an input to the signing function 170 then no sign-extension or zero-extension operation is required at step 192, and instead the unique pointer bits can be provided directly to the authorisation signature generation function 195.
- the authorisation signature generation function 195 also has access to the cryptographic signing key and to a salt value. It will be appreciated that unless the authorisation signature generation function 195 has access to the same salt value (i.e. the same item of contextual information) as was used by the cryptographic signing function 170, then it is highly unlikely that it will generate an authorisation signature that will match the signature inserted in the section 179 of the signed capability.
- the authorisation signature generated by the authorisation signature generation function 195 using the relevant pointer bits, the cryptographic signing key and the salt value, is then input to a comparison block 198, where it is compared with the signature held in the section 179 of the signed capability. In the event of a match, then authorisation is said to have been passed, and an unsigned version of the signed capability 175 is generated. Otherwise, a fail condition is identified, causing predetermined actions to be taken, as will be discussed by way of example later with reference to Figure 7.
- the unsigned capability is created by removing the signature from the section 179, and replacing it with a sign-extended (or zero- extended depending on implementation) version of the unique pointer bits in the section 177, in order to recreate the initial pointer value. Furthermore, the signing information 182 is cleared to identify that the capability is now unsigned.
- a multi-bit type field may be provided so that at least one other property of the bounded pointer may be identified in addition to whether it is signed or not.
- Some possible encodings are shown in Figure 5. The other types of capability that it may be desired to represent will clearly vary dependent on embodiment. Purely by way of illustration, the multi-bit type field may be used to identify when a capability is a sealed capability. As discussed for example in Technical Report No.
- a seal may be used as a lock on a capability in order to prevent it being used. Only the entity that has the right key (the one that locked it, and generally implemented as a capability itself) can unlock it.
- a multi-bit type field in situations where there are more than two different types of capability that may be represented, this can lead to a more efficient encoding within the available attributes space of the capability.
- FIG. 6 is a flow diagram illustrating the signing operation in accordance with one embodiment.
- the signing of a capability is requested, for example by the processor executing a signing instruction.
- the bits of the pointer to be overwritten by the signature are identified. As per the example of Figure 4, the identified bits would be the upper bits of the pointer value that are a sign-extended version of the unique pointer bits.
- step 210 it is then determined whether all of the identified bits have the same value as the most significant bit of the remaining portion of the pointer, i.e. whether they truly are a sign- extended version of the unique pointer bits.
- a zero-extended format may be used, and in that case at step 210 it will be determined whether all of the identified bits are zero.
- step 210 If it is determined at step 210 that all of the identified bits do not meet the required condition, i.e. in the example of Figure 6 are bits that do not have the same value as the most significant bit of the remaining portion of the pointer, then the process proceeds to step 235 where a predetermined action is taken.
- the predetermined action can take a variety of forms, but in one embodiment may involve raising a processor fault, in order to cause an exception to be taken to handle further processing.
- the identified input capability may be invalidated, for example by clearing the tag bit so that effectively the capability is converted into general purpose data, and can no longer be used as a capability.
- step 210 By performing the step 210 and proceeding to the step 235 when the condition is not met, this protects against the possibility that the acts of signing an unsigned capability, and subsequently authorising the signed capability, could give rise to a resultant unsigned capability that does not match the original unsigned capability, i.e. in the example of Figure 4 due to the process of signing and unsigning potentially creating a different pointer value.
- the act of signing and subsequently authorising does not change the pointer value
- it is also important that the act of signing and authorisation cannot change the rights associated with the capability for example change the range specified by the range information, or change the permissions specified for the capability.
- the range information is specified relative to the pointer value, and as a result, when the pointer value is legitimately changed a process needs to be performed to re-encode the range information appropriately.
- step 210 Assuming the check at step 210 is passed, and hence it is determined that all of the identified bits have the same value as the most significant bit of the remaining portion of the pointer value, then the process proceeds to step 215, where a signature is created from the pointer value, the signing key and the salt value. Thereafter, at step 220, the identified bits of the pointer are replaced with the signature, as discussed earlier with reference to Figure 4, and at step 225 the signing attribute field 182 is set to indicate that the capability has been signed. Thereafter, at step 230, the signed capability can be output, for example for storing in one of the capability registers 60.
- Figure 7 is a flow diagram illustrating the authorisation process performed in accordance with one embodiment.
- authorisation of a signed capability is requested, for example by the processor executing an authorisation instruction.
- the unique pointer bits size is then identified. This is important to ensure that the correct bits are used for performing the authorisation process.
- the size of the unique pointer bits portion may be fixed, and hence will not change.
- the size of the unique pointer bits portion within the pointer value may be globally configured under software control, for example by software executing at a predetermined privileged level.
- the size of the unique pointer bits portion may be context sensitive, and again may be set under software control, with the value being dependent on the current context.
- Authorisation will typically be performed in the same context as was used for the associated signing operation. If necessary, a check could be performed to confirm that this condition is met, in order to allow authorisation to proceed.
- the authorisation signature generation function 195 is performed in order to create an authorisation signature from the pointer value, the signing key and the salt value. Thereafter, at step 275 it is determined whether the authorisation signature matches the signature provided within the signed capability, and if not the process proceeds to step 295 where a predetermined action is taken.
- the predetermined action can take a variety of forms. For example, a processor fault may be raised in order to take an exception, or the signed capability may be invalidated, for example by clearing the tag bit. In a yet further example arrangement, it may be decided to leave the capability as signed, and hence not complete the authorisation process. It will then be expected that any subsequent use of the capability will fail since that subsequent use will be expecting to use an unsigned capability, and the capability will at that point still be signed.
- the range information may be specified in absolute terms, and hence any change to the pointer value does not itself change the range
- the range information may be specified relative to the pointer in order to reduce the amount of information to be stored within the capability to specify the range.
- Such an arrangement is shown for example in Figure 8.
- two offsets 305, 310 may be specified to form the range information, these identifying the offset from the pointer to the base and the offset from the pointer to the limit, hence enabling an identification of the two ends of the range 315.
- Limit determination processes 307, 312 can then be performed using the pointer value 300 and the relevant offset information in order to identify the extent of the range 315. Whilst this can provide a reduction in the number of bits required to specify the range information, it does give rise to a need to adjust the range information when the pointer value is changed, in order to ensure that the range is not altered as a result of an adjustment to the pointer.
- FIG. 9 illustrates one example option where immutability of the signed capability is enforced. Accordingly, at step 350, it is assumed that a modification to request some aspect of a specified input capability is requested. This may for example take the form of an instruction specifying an input capability, for example with reference to one of the capability registers 60, and being a type of instruction that causes part of the capability to be modified.
- Figure 10 illustrates an alternative option to Figure 9, where changes to the signed capability, and in particular to the pointer value, are allowed.
- a change to the pointer value is requested.
- a bounds adjustment operation is performed to adjust the bounds information (i.e. the range attributes) to take account of the change in the full size pointer.
- the pointer value is interpreted as having a reduced size, i.e. the full size minus the size of the signature that has been inserted.
- this enables the processor to adjust other types of operation dependent on whether the specified input capability is signed or unsigned. For example, in one embodiment as shown in figure 11, the dereferencing of a signed capability is prohibited, thus ensuring that a signed capability cannot be used to identify a memory address to be accessed.
- a request is received to dereference a capability. This for example may arise by virtue of executing a load instruction or a store instruction identifying a specified input capability to derive the memory address to be accessed.
- it is determined from the signing attribute information whether the specified capability is signed or unsigned.
- step 415 it may be deemed appropriate to allow the memory address to be derived from the entire pointer value field, which due to the incorporation of the signature within the most significant bits may be arranged to ensure that the pointer will identify a faulting address in memory, hence causing the memory access to fail.
- Figure 12 is a flow diagram illustrating another type of operation where the processing performed may be dependent on whether the specified input capability is signed or unsigned.
- a capability signing process is invoked, for example by a signing instruction being executed identifying an input capability.
- it is determined whether the input capability is already signed by referring to the signing attribute information. If it is not, then the normal capability signing process may be performed at step 430, for example using the earlier described approach of Figure 6.
- a predetermined action can be taken at step 435, for example by triggering a fault condition, or invalidating the capability.
- Another alternative option may be to retain the capability as a signed capability with the original signing information.
- the only way to unsign a signed capability may be to use an authorisation process such as that discussed earlier with reference to figure 7, where a signature match checking process is required before allowing the capability to be unsigned
- an additional function may be provided for allowing signed capabilities to be unsigned in certain situations.
- a strip function may be provided that permits, under certain conditions, a signed capability to be converted into an unsigned capability without performing the signature match check. Such a process is illustrated by way of example in Figure 13.
- a stripping of a signed capability is requested, for example by executing a strip instruction specifying an input capability.
- Steps 475, 480 and 485 then correspond to steps 280, 285 and 290 of Figure 7, causing the signature in the capability to be replaced with the sign-extended bits, the signing attribute information to be cleared, and the resultant unsigned capability to be output.
- Steps 475, 480 and 485 then correspond to steps 280, 285 and 290 of Figure 7, causing the signature in the capability to be replaced with the sign-extended bits, the signing attribute information to be cleared, and the resultant unsigned capability to be output.
- Steps 475, 480 and 485 then correspond to steps 280, 285 and 290 of Figure 7, causing the signature in the capability to be replaced with the sign-extended bits, the signing attribute information to be cleared, and the resultant unsigned capability to be output.
- the strip functionality is a potentially powerful tool, and accordingly in one embodiment it is considered appropriate to restrict use of the strip functionality to certain predetermined situations.
- Some example restrictions that may be placed on use on the stripping functionality are set out in figures 14A to 14C.
- FIG. 14 A it is assumed at step 500 that stripping of a signed capability is requested.
- the predetermined elevated privileged state may take a variety of forms depending on embodiment, but considering for example a virtual machine type environment, the predetermined elevated privileged state may be the hypervisor level.
- step 515 a fault occurs, i.e. one of the predetermined actions identified in step 490 of Figure 13 is performed.
- the stripping function is performed at step 510, by following the "yes" path from step 455 of Figure 13.
- Figure 14B illustrates an alternative approach, where steps 520, 530 and 535 correspond to steps 500, 510 and 515 of figure 14A, but where the test 505 is replaced by the test 525, and in particular it is determined whether a privileged configuration register has been set to allow stripping.
- the privileged configuration register may for example be a register that is settable by the processor when operating in a predetermined privileged state, and accordingly its value can only be modified by the processor operating in that predetermined privileged state. Assuming the contents of the configuration register indicate that stripping is allowed, then the stripping function is performed at step 530, but otherwise a fault is raised at step 535.
- the strip capability identified by the strip instruction is retrieved from the relevant capability register at step 545 and then analysed to determine its contents. Then, at step 550 it is determined whether the strip capability allows the identified signed pointer to be stripped. If it does, then the stripping function is performed at step 555, whereas otherwise a fault is raised at step 560.
- the strip capability may be a capability dedicated solely to identifying whether stripping is permitted
- a single capability held within the capability register 60 may identify a number of permissions, one of which is a stripping permission.
- the instruction set that is executable by the processor may include a number of capability instructions, i.e. instructions that specifically identify as one or more operands capabilities. For example, to support the earlier described signing, authorisation and stripping functions, the following three instructions may be provided:
- CAUTH Convert signed capability to unsigned capability subject to successful authorisation (capability register(s) as source and destination, and optional contextual information, e.g. salt value)
- the source and destination capability registers may be two different capability registers, or alternatively the same register may be specified as the source and destination, hence causing an unsigned capability to be overwritten with a signed capability, or vice versa.
- CLDR A Convert signed capability (from capability register) into unsigned capability subject to successful authorisation (may leave signed capability unchanged in capability register), and use pointer to identify memory address from which to load an item (capability or data) into a register
- CBR A Convert signed capability (from capability register) into unsigned capability subject to successful authorisation (may leave signed capability unchanged in capability register), and use pointer to determine an update to the program counter value
- the signature was added in to a certain number of the most significant bits of the pointer value.
- the signature may instead be added into a portion of the attributes field, for example within the bounds information.
- the unsigned capability includes a pointer portion 600, and an attributes portion including the bounds section 605 and the permissions section 610.
- a tag bit 615 is also provided, which is set to identify that the associated contents represent a capability rather than general purpose data.
- the capability is signed, then in this example the pointer value remains unchanged, and instead the signature is inserted within a part of the available space for the bounds information, as shown by the hash field 625.
- a signing attribute field 632 is also provided and is set to indicate that the capability has been signed, resulting in a modified permissions section 630.
- the tag bit 615 is retained set to identify that the associated information is still a capability.
- Figure 16A is a flow diagram illustrating the signing process in situations where the signature is added to the bounds information.
- signing of a capability is requested, for example by execution of a signing instruction, whereafter at step 655 it is determined if there is sufficient redundancy in the bounds information bits to accommodate the signature.
- the bounds information comprises a specification of a base value and a limit value, and both of those values have a certain amount of redundant information in their upper bits. If those upper bits are sufficient to incorporate the signature without any loss of information, then it will be determined that there is sufficient redundancy in the bounds information to accommodate the signature.
- step 655 If at step 655 it is determined that there is insufficient redundancy in the bounds information to accommodate the signature, then the process proceeds to step 680 where a predetermined action is taken, for example raising a processor fault or invalidating the input capability.
- the signature is created from the pointer value, the signing key and the salt value, whereafter at step 665 the identified redundant bits in the bounds information are replaced with the signature.
- the signing attribute information is set to indicate that the capability has been signed, and then at step 675 the signed capability is output, for example for storage in one of the capability registers 60.
- Figure 16B is a flow diagram illustrating a corresponding authorisation process that is performed if the signature is added to the bounds information.
- a request to authorise a signed capability is received, whereafter at step 705 an authorisation signature is created from the pointer, the signing key and the salt value.
- an authorisation signature is created from the pointer, the signing key and the salt value.
- step 710 it is determined whether the authorisation signature matches the signature in the signed capability, and if not a predetermined action is taken at step 730, these corresponding to the predetermined actions discussed earlier with reference to step 295 of Figure 7.
- step 720 the signing attribute information is cleared to identify that the capability is now unsigned, and then the unsigned capability is output at step 725.
- the tag bit moves with the capability to identify that the associated block of data stored in memory is in fact a capability.
- a backing store such as a disk
- this involves decomposing each capability into separate data and tag portions, and treating the tag as data within the backing store. This is illustrated schematically in Figure 17, where, as per the approach described earlier with reference to Figure 3, when capabilities are moved between the capability registers 800 and memory 805, then the tag bit 815 moves with each data block 810.
- each block of data in memory 805 can be identified as representing either a capability or general purpose data.
- a decomposition process 820 is used to decompose the capability into data 824 and tag information 822, the tag information being treated as data. Accordingly, within the backing store the information merely persists as data, and the backing store is capability unaware.
- the process used to reconstruct capabilities may take a variety of forms, but in one embodiment the processor is arranged to perform a refinement process on the general capability with reference to the specified data retrieved from the backing store 825.
- a capability reconstruction operation may be invoked, identifying a block of data and an associated item of tag data within the backing store 825 (which may in one embodiment at that point be moved from the backing store into one or more registers to allow the data to then be manipulated by the processor), and using that information the operation 830 can seek to refine the master capability so that the resultant capability matches that identified data. If this is possible, then this indicates that the identified data can indeed represent a capability, and accordingly the process 830 can set the tag bit in association with that data and output it as a capability for storing in memory 805.
- the data used at this point to generate the capability from may in one embodiment be the refined version of the master capability, or alternatively may be the data retrieved from the backing store. In either event, at this stage the relevant data will typically be held in register, and so a store operation can for example be used to store the capability from a register into the memory 805.
- the master capability 835 can be used to effectively represent a super-set of all of the available permissions and ranges that could be associated with a valid capability, when the issue of signed capabilities is considered, it will be appreciated that it is not possible to derive a signature from a refinement of a master capability. In one embodiment, this issue is addressed by allowing, under certain controlled conditions, the use of data from the backing store to form a signature within a reconstructed capability, hence allowing the reconstruction process 830 to also recreate signed capabilities. This process is discussed in more detail with reference to the flow diagram of Figure 18.
- the data identified for that reconstruction process is retrieved from the backing store.
- the data retrieved is stored in one or more working registers.
- the data block portion i.e. the 128 bits of data in the earlier discussed embodiment
- the bit of data retrieved from the backing store that is indicative of the tag bit can be stored in a general purpose register.
- step 855 it is determined whether the data bit that forms the tag information (i.e. the bit now stored in the general purpose register) indicates that the data is to form a capability. If not, the process merely proceeds to step 857 where the retrieved data may be output from the capability register to the memory 805 with the tag bit cleared to identify that the data block is general purpose data.
- a refinement process is invoked to seek to refine a copy of the master capability using the retrieved data to narrow the permissions and bounds of the master capability, and also to set the pointer value. It will be appreciated that this refinement process can be implemented in a variety of ways, but in one embodiment could be an iterative process (for example by executing a sequence of refinement instructions).
- step 865 it is determined whether the original data retrieved from the backing store indicates that the capability is to be signed. For example, the relevant field in the data that would represent the signing information within the associated attributes of a capability may be reviewed in order to see if it is set or cleared, and hence whether the data, were it converted into a capability, would represent a signed capability or an unsigned capability. If, as a result of step 865, it is determined that the capability to be created is unsigned, the process proceeds to step 867, where it is determined whether the required capability could be successfully created by refinement of the master capability 835.
- this condition will be considered to be passed if a refinement process performed with respect of the master capability results in a sequence of bits having the same value as the bits retrieved from the backing store, hence indicating that the data retrieved from the backing store can represent a valid capability.
- the process proceeds to step 895 where the capability is created by setting the tag bit in association with the refined version of the master capability (which will typically at this point reside within a register), and then the capability is output to memory 805 (maintaining the tag bit set to identify that the data block is in fact a capability), for example by performing a suitable store operation.
- the capability may be generated at this point from the copy of the data retrieved from the backing store, with the tag bit being set prior to output to the memory 805.
- step 895 could be implemented in a variety of ways.
- a "SetTag" instruction could be executed to identify the source (capability) register in which the data being used to form the capability is temporarily stored, and a destination capability register into which the generated capability is to be stored and for which the tag bit is to be set to identify it as a capability.
- the source and destination registers could be the same register.
- there could effectively be two source registers namely the register containing the refined version of the master capability resulting from step 860, and the register containing the raw data retrieved from the backing store, since both of these registers may be referred to when generating the resultant capability (as for example will be discussed below with reference to steps 885, 890).
- a separate store instruction could then be executed to store the capability from the register to memory.
- step 867 If it is determined at step 867 that the capability cannot successfully be created by refinement of the master capability, then instead the process proceeds to step 870 where a fault occurs.
- a processor fault could be raised in order to cause an exception to be taken.
- the data could be retained in the capability register 800 to which it was temporarily retrieved, but with the tag bit maintained in the cleared state to identify the data as general purpose data rather than a capability.
- Another alternative would be to set an efficiently testable processor condition, e.g. by setting a condition flag, or by placing a value in a general purpose register that can be checked with a test and branch instruction.
- step 865 it is determined that the original data indicates that the capability is to be signed, then as mentioned earlier, it will not be possible to generate the signature by refinement of the master capability. Accordingly, if a signed capability is to be reconstructed, it will be necessary to allow at least the data representing the signature to be copied directly into the capability.
- step 867 the process proceeds to step 869, where it is determined whether all parts of the capability other than those relating to the signed nature of the capability, in particular the signature and the signing attribute information, can successfully be created by refinement of the master capability. If not, then a fault is raised at step 870. However, otherwise the process proceeds to step 875, where it is determined whether signing is permitted during reconstruction. As will be discussed later with reference to Figures 19A to 19C, there are a number of possible checks that could be performed at this stage, but it is envisaged that generally some constraint will be placed on situations where it is allowed to sign a capability directly using the data retrieved from the backing store. If it is determined at step 875 that signing is not permitted during reconstruction, then a fault is raised at step 880.
- the options available at step 880 may for example correspond to the options available at step 870. Alternatively, the capability may be generated as an unsigned capability if step 880 is reached, instead of generating a fault.
- the signature is identified to correspond to a sequence of the bits retrieved from the backing store and is inserted at step 885 in an identified portion of the data that is to form the generated capability, for example in a certain number of most significant bits of the pointer value if the approach of the earlier-discussed Figure 4 is used.
- step 890 that signing attribute information is set within a further identified portion of the data that is to form the generated capability, and will indicate that the capability is a signed capability when that capability is generated. Thereafter, the process proceeds to step 895, where the capability is generated and output to memory, with the tag bit being set to identify the associated data block as being a capability.
- the register temporarily holding that refined version will be updated with the relevant parts of the raw data retrieved from the backing store. If instead the capability is generated from the copy of the data retrieved from the backing store, then it is steps 885 and 890 that effectively allow those relevant parts of the raw data to deviate from the refined version of the master capability and hence implement the insertion and setting functions defined by steps 885 and 890.
- a signed capability includes a signing attribute field to identify the associated capability as either being signed or unsigned
- the general reconstruction process discussed with reference to Figures 17 and 18 can be implemented irrespective of whether such additional signing information is provided within the attributes field.
- the described process can still be used to generate a signed capability by insertion of the relevant signature using the data retrieved from the backing store when reconstructing a capability from data held in the backing store.
- Figures 19A to 19C illustrate various checks that could be performed to determine whether signing is permitted during reconstruction at step 875 of Figure 18. As will be apparent from a comparison of Figures 19A to 19C with Figures 14A to 14C, these checks are in one embodiment analogous to the checks that could be performed to decide whether to allow a signed capability to be stripped. Accordingly, considering Figure 19A, when signing during reconstruction is requested at step 900, it may be determined at step 905 whether the processor is currently operating in a predetermined elevated privileged state, and if so to allow the signature to be inserted at step 910, whereas otherwise a fault is raised at step 915 (step 915 corresponding to step 880 of Figure 18).
- steps 920, 930 and 935 correspond to steps 900, 910 and 915 of Figure 19A, but the decision 905 is replaced by the decision 925, where it is checked whether a privileged configuration register has been set to allow a signature be inserted. That privileged configuration register will typically only be writeable to by the processor when the processor is operating in at least one predetermined privileged state.
- a signing capability is provided which may for example be stored within one of the capability registers 60.
- This signing capability provides information identifying whether signing is permitted during reconstruction of a capability from data held in the backing store.
- a related signing capability will be identified, and that signing capability will be retrieved at step 955 in order to allow its contents to be analysed.
- an insert signature instruction may be used to initiate the insertion of a signature during reconstruction of a capability from general purpose data, and the signing capability may be identified as an operand of that insert signature instruction.
- step 960 it is then determined at step 960 whether the signing capability allows a signature to be inserted, and if so then the process proceeds to step 965 where the signature is inserted using the data held in the backing store. Otherwise, a fault is raised at step 970.
- Figures 19A to 19C may be considered alternatives, in some embodiments they may be used in combination so that if any one test is met, then insertion of a signature is deemed to be allowed.
- the process of Figure 18 can be implemented in a variety of ways. For example, it could be implemented in hardware, where the hardware responds to a single instruction initiating the reconstruction process to perform all of the steps identified in Figure 18. Alternatively, the process could be implemented in software by using a sequence of instructions to implement the reconstruction process of Figure 18. In accordance with the latter approach, a series of instructions may for example be executed to examine the relevant data fields of the retrieved raw data from the backing store one by one, to refine the master capability in order to set bounds, permissions, etc, and to write the refined master capability to memory.
- the reconstruction process of Figures 17 to 19 can be used in a variety of situations.
- a task A such as a paging system task may have sufficient capability (by virtue of its access to the general capability 835) to set up capabilities for a further task (task B), prior to passing over control to task B.
- the paging system task can, through the adoption of the process of Figures 17 to 19, create the required capabilities, and store them in shared memory, whereafter those capabilities can then be allocated to task B. It will be appreciated that this is just one example scenario of how the capability reconstruction process may be used, and it will be appreciated that there are also other scenarios where the ability to reconstruct capabilities from data in the backing store will be useful.
- the strong security afforded by the use of capabilities can be further enhanced through the use of a signing operation to generate signed capabilities.
- the inherent security afforded by capabilities is further enhanced in order to further reduce the prospect of a rogue entity seeking to circumvent control flow integrity.
- the words “configured to" are used to mean that an element of an apparatus has a configuration able to carry out the defined operation.
- a “configuration” means an arrangement or manner of interconnection of hardware or software.
- 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.
Abstract
Description
Claims
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201680081078.8A CN108604271B (en) | 2016-02-12 | 2016-12-23 | Apparatus and method for controlling use of bounded pointer |
US16/073,497 US11030344B2 (en) | 2016-02-12 | 2016-12-23 | Apparatus and method for controlling use of bounded pointers |
EP16822254.5A EP3414700B1 (en) | 2016-02-12 | 2016-12-23 | An apparatus and method for controlling use of bounded pointers |
KR1020187025530A KR102649092B1 (en) | 2016-02-12 | 2016-12-23 | Apparatus and method for controlling use of bound pointers |
JP2018540724A JP6893216B2 (en) | 2016-02-12 | 2016-12-23 | Devices and methods for controlling the use of bounded pointers |
IL260458A IL260458B (en) | 2016-02-12 | 2018-07-08 | An apparatus and method for controlling use of bounded pointers |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB1602539.7A GB2547247B (en) | 2016-02-12 | 2016-02-12 | An apparatus and method for controlling use of bounded pointers |
GB1602539.7 | 2016-02-12 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2017137713A1 true WO2017137713A1 (en) | 2017-08-17 |
Family
ID=55697613
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/GB2016/054054 WO2017137713A1 (en) | 2016-02-12 | 2016-12-23 | An apparatus and method for controlling use of bounded pointers |
Country Status (9)
Country | Link |
---|---|
US (1) | US11030344B2 (en) |
EP (1) | EP3414700B1 (en) |
JP (1) | JP6893216B2 (en) |
KR (1) | KR102649092B1 (en) |
CN (1) | CN108604271B (en) |
GB (1) | GB2547247B (en) |
IL (1) | IL260458B (en) |
TW (1) | TWI745333B (en) |
WO (1) | WO2017137713A1 (en) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2547247B (en) * | 2016-02-12 | 2019-09-11 | Advanced Risc Mach Ltd | An apparatus and method for controlling use of bounded pointers |
US10795997B2 (en) * | 2017-06-21 | 2020-10-06 | Intel Corporation | Hardened safe stack for return oriented programming attack mitigation |
US10387335B2 (en) * | 2017-09-28 | 2019-08-20 | Hewlett Packard Enterprise Development Lp | Memory system and handles to master capabilities |
US11250133B2 (en) | 2018-01-12 | 2022-02-15 | Arris Enterprises Llc | Configurable code signing system and method |
US11860996B1 (en) * | 2018-04-06 | 2024-01-02 | Apple Inc. | Security concepts for web frameworks |
US11144631B2 (en) | 2018-09-11 | 2021-10-12 | Apple Inc. | Dynamic switching between pointer authentication regimes |
GB2578158B (en) * | 2018-10-19 | 2021-02-17 | Advanced Risc Mach Ltd | Parameter signature for realm security configuration parameters |
US11741196B2 (en) | 2018-11-15 | 2023-08-29 | The Research Foundation For The State University Of New York | Detecting and preventing exploits of software vulnerability using instruction tags |
WO2021162439A1 (en) * | 2020-02-14 | 2021-08-19 | Samsung Electronics Co., Ltd. | Electronic device performing restoration on basis of comparison of constant value and control method thereof |
GB2592069B (en) * | 2020-02-17 | 2022-04-27 | Advanced Risc Mach Ltd | Address calculating instruction |
US11711201B2 (en) * | 2020-08-14 | 2023-07-25 | Intel Corporation | Encoded stack pointers |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080060077A1 (en) * | 2001-12-06 | 2008-03-06 | Novell, Inc. | Pointguard: method and system for protecting programs against pointer corruption attacks |
US20140173293A1 (en) * | 2012-12-17 | 2014-06-19 | Advanced Micro Devices, Inc. | Hardware Based Return Pointer Encryption |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5845331A (en) | 1994-09-28 | 1998-12-01 | Massachusetts Institute Of Technology | Memory system including guarded pointers |
US6826672B1 (en) * | 2000-05-16 | 2004-11-30 | Massachusetts Institute Of Technology | Capability addressing with tight object bounds |
US7441116B2 (en) * | 2002-12-30 | 2008-10-21 | International Business Machines Corporation | Secure resource distribution through encrypted pointers |
GB2402236B (en) * | 2003-05-27 | 2005-04-27 | Simon Alan Spacey | A method and apparatus for securing a computer system |
WO2009075116A1 (en) * | 2007-12-12 | 2009-06-18 | Nec Corporation | Program debug method, program conversion method, and program debug device and program conversion device using the method, and storage medium |
US8156385B2 (en) * | 2009-10-28 | 2012-04-10 | International Business Machines Corporation | Systems and methods for backward-compatible constant-time exception-protection memory |
CN101833631B (en) * | 2010-02-09 | 2011-04-13 | 北京理工大学 | Pointer analysis-combined software security hole dynamic detection method |
WO2012025793A1 (en) * | 2010-08-26 | 2012-03-01 | Freescale Semiconductor, Inc. | Memory management unit for a microprocessor system, microprocessor system and method for managing memory |
US8732430B2 (en) * | 2011-03-22 | 2014-05-20 | Oracle International Corporation | Method and apparatus for using unused bits in a memory pointer |
US20130013895A1 (en) * | 2011-07-06 | 2013-01-10 | Fs-Semi Co., Ltd. | Byte-oriented microcontroller having wider program memory bus supporting macro instruction execution, accessing return address in one clock cycle, storage accessing operation via pointer combination, and increased pointer adjustment amount |
US9081657B2 (en) * | 2011-10-13 | 2015-07-14 | Conexant Systems, Inc. | Apparatus and method for abstract memory addressing |
US10038550B2 (en) * | 2013-08-08 | 2018-07-31 | Intel Corporation | Instruction and logic to provide a secure cipher hash round functionality |
US9530006B2 (en) | 2014-04-11 | 2016-12-27 | Oracle International Corporation | Method and system for performing a memory safety check of a program written in an unmanaged programming language |
US9804891B1 (en) | 2015-03-20 | 2017-10-31 | Antara Teknik LLC | Parallelizing multiple signing and verifying operations within a secure routing context |
GB2544996B (en) * | 2015-12-02 | 2017-12-06 | Advanced Risc Mach Ltd | An apparatus and method for managing bounded pointers |
GB2547247B (en) * | 2016-02-12 | 2019-09-11 | Advanced Risc Mach Ltd | An apparatus and method for controlling use of bounded pointers |
-
2016
- 2016-02-12 GB GB1602539.7A patent/GB2547247B/en active Active
- 2016-12-23 KR KR1020187025530A patent/KR102649092B1/en active IP Right Grant
- 2016-12-23 WO PCT/GB2016/054054 patent/WO2017137713A1/en active Application Filing
- 2016-12-23 JP JP2018540724A patent/JP6893216B2/en active Active
- 2016-12-23 CN CN201680081078.8A patent/CN108604271B/en active Active
- 2016-12-23 EP EP16822254.5A patent/EP3414700B1/en active Active
- 2016-12-23 US US16/073,497 patent/US11030344B2/en active Active
-
2017
- 2017-01-10 TW TW106100667A patent/TWI745333B/en active
-
2018
- 2018-07-08 IL IL260458A patent/IL260458B/en active IP Right Grant
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080060077A1 (en) * | 2001-12-06 | 2008-03-06 | Novell, Inc. | Pointguard: method and system for protecting programs against pointer corruption attacks |
US20140173293A1 (en) * | 2012-12-17 | 2014-06-19 | Advanced Micro Devices, Inc. | Hardware Based Return Pointer Encryption |
Non-Patent Citations (3)
Title |
---|
ALI JOSE MASHTIZADEH ET AL: "CCFI", PROCEEDINGS OF THE 22ND ACM SIGSAC CONFERENCE ON COMPUTER AND COMMUNICATIONS SECURITY, CCS '15, 12 October 2015 (2015-10-12), New York, New York, USA, pages 941 - 951, XP055340240, ISBN: 978-1-4503-3832-5, DOI: 10.1145/2810103.2813676 * |
CRISPIN COWAN ET AL: "PointGuard TM: Protecting Pointers From Buffer Overflow Vulnerabilities", USENIX,, 29 July 2003 (2003-07-29), pages 1 - 15, XP061011042 * |
LASZLO SZEKERES ET AL: "SoK: Eternal War in Memory", SECURITY AND PRIVACY (SP), 2013 IEEE SYMPOSIUM ON, IEEE, 19 May 2013 (2013-05-19), pages 48 - 62, XP032431315, ISBN: 978-1-4673-6166-8, DOI: 10.1109/SP.2013.13 * |
Also Published As
Publication number | Publication date |
---|---|
CN108604271A (en) | 2018-09-28 |
JP6893216B2 (en) | 2021-06-23 |
US20190034664A1 (en) | 2019-01-31 |
CN108604271B (en) | 2021-08-10 |
EP3414700A1 (en) | 2018-12-19 |
GB201602539D0 (en) | 2016-03-30 |
US11030344B2 (en) | 2021-06-08 |
GB2547247B (en) | 2019-09-11 |
TWI745333B (en) | 2021-11-11 |
KR102649092B1 (en) | 2024-03-20 |
GB2547247A (en) | 2017-08-16 |
TW201732576A (en) | 2017-09-16 |
EP3414700B1 (en) | 2021-01-27 |
KR20180111919A (en) | 2018-10-11 |
IL260458B (en) | 2020-06-30 |
JP2019505052A (en) | 2019-02-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10838878B2 (en) | Apparatus and method for generating signed bounded pointers | |
US11030344B2 (en) | Apparatus and method for controlling use of bounded pointers | |
US11249912B2 (en) | Apparatus and method for storing bounded pointers | |
EP3374919B1 (en) | An apparatus and method for controlling use of bounded pointers | |
JP7280196B2 (en) | Apparatus and method for managing functional domains | |
EP4334819A1 (en) | Technique for constraining access to memory using capabilities |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16822254 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 260458 Country of ref document: IL |
|
ENP | Entry into the national phase |
Ref document number: 2018540724 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 20187025530 Country of ref document: KR Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020187025530 Country of ref document: KR |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2016822254 Country of ref document: EP |
|
ENP | Entry into the national phase |
Ref document number: 2016822254 Country of ref document: EP Effective date: 20180912 |