WO2023169654A1

WO2023169654A1 - Control flow integrity

Info

Publication number: WO2023169654A1
Application number: PCT/EP2022/055825
Authority: WO
Inventors: Rémi Robert Michel DENIS-COURMONT
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-03-08
Filing date: 2022-03-08
Publication date: 2023-09-14

Abstract

In some examples, a computing system comprises a processor, a memory coupled to the processor, configured to store program code executable by the processor, the program code comprising one or more branch instructions, a stack data structure accessible to the processor, and a stack pointer associated to the stack data structure, the stack pointer identifying an address in the stack data structure during execution of the program code by the processor, and a compiler unit coupled to the memory and processor, configured to access the program code from the memory, and generate, for each of the one or more branch instructions, a data value based on an output of a cryptographically secure function, wherein data values for respective branch instructions are generated based on a first input identifying the address of the stack pointer prior to an evaluation of the branch instruction, a second input encoding information indicative of a target address in the memory subsequent to evaluation of the branch instruction, and a third input comprising a cryptographically secure key.

Description

CONTROL FLOW INTEGRITY

Technical Field

The present disclosure relates, in general, to prevention of memory corruption vulnerabilities. Aspects of the disclosure relate to forward edge control flow integrity.

In computer programming, the control flow of a program refers to the order in which statements and function calls are executed by the computing system. Modern computing systems implement programs with highly complex control flows. Controls flows may present a security risk if an attacker can hijack the control flow and force the computing system to execute malicious code. As such, computing systems may implement measures to protect the integrity of control flows.

Forward-edge Control Flow Integrity (CFI) of a software program refers to the security property that only intended functions are called during program execution, and attackers cannot force the program to call an unintended function supplied by the attacker. Such an attack is possible when functions are not called directly, but via function pointers stored in writable memory. In this case, an attacker may utilize a vulnerability that allows modifications to such functions pointers and make them point to carefully selected locations in the code to achieve a malicious purpose, e.g., to gain privileges in the system that are not supposed to be granted.

Most effective defenses to such attacks are hardware-assisted approaches. For example, the ARMv8.3 Instruction Set Architecture (ISA) provides a Pointer Authentication (PAuth) security extension to allow programs to insert a Pointer Authentication Code (PAC) in the pointers when they are stored in writable memory, and validate the PAC when the signed pointers and later loaded and used. If the check fails, an exception is generated when the address is used for a branch. Summary

An objective of the present disclosure is to provide protection against code reuse attacks in a computing environment.

The foregoing and other objectives are achieved by the features of the independent claims.

Further implementation forms are apparent from the dependent claims, the description and the Figures.

A first aspect of the present disclosure provides a computing system, comprising a processor, a memory coupled to the processor, the memory configured to store, program code executable by the processor, the program code comprising one or more branch instructions, a stack data structure accessible to the processor, and a stack pointer associated to the stack data structure, the stack pointer identifying an address in the stack data structure during execution of the program code by the processor, and a compiler unit coupled to the memory and processor, configured to access the program code from the memory, and generate, for each of the one or more branch instructions, a data value based on an output of a cryptographically secure function, wherein data values for respective branch instructions are generated based on a first input identifying the address of the stack pointer prior to an evaluation of the branch instruction, a second input encoding information indicative of a target address in the memory subsequent to evaluation of the branch instruction, and a third input comprising a cryptographically secure key.

Accordingly, program code output by a compiler unit provides forward-edge code flow integrity, which allows protection against, e.g., jump oriented programming attacks. A machine code output can be modified by the compiler unit to achieve such forward-edge code flow integrity whilst not requiring any changes to source program code. As such, a representation (as defined by, e.g., ISO C and ISO C++) of pointers is not affected, enabling a system as described herein to be deployed at low cost by software and embedded software vendors.

In an implementation of the first aspect, the compiler unit can generate data values for memory access operations and/or function calls between branch instructions in the control flow of the program code, based on an output of the cryptographically secure function. The cryptographically secure function can be implemented using an instruction set extension. The instruction set extension can comprise a pointer authentication (PAuth) security extension. During execution of the program code the processor can validate the one or more data values based on the stack pointer and the cryptographically secure key. The processor can generate a fault exception in response to the compiler unit determining that one or more data values are invalid.

A second aspect of the present disclosure provides a method comprising accessing, from a memory of a computing system, program code executable by a processor of the computing system, the program code comprising one or more branch instructions, a stack data structure accessible to the processor, and a stack pointer associated to the stack data structure, the stack pointer identifying an address in the stack data structure during execution of the program code by the processor, and generating, for each of the one or more branch instructions, a data value based on an output of a cryptographically secure function, wherein data values for respective branch instructions are generated based on a first input identifying the address of the stack pointer prior to an evaluation of the branch instruction, a second input encoding information indicative of a target address in memory subsequent to evaluation of the branch instruction, and a third input comprising a cryptographically secure key.

In an implementation of the second aspect, data values for memory access operations and/or function calls between branch instructions in the control flow of the program code can be generated based on an output of the cryptographically secure function. The cryptographically secure function can be implemented using an instruction set extension. The instruction set extension can comprise a pointer authentication (PAuth) security extension. During execution of the program code by the processor, the one or more data values can be validated based on the stack pointer and the cryptographically secure key. A fault exception can be generated in response to determining that one or more data values are invalid.

A third aspect of the present disclosure provides a network device, comprising a processor, a memory coupled to the processor, the memory configured to store program code executable by the processor, the program code comprising one or more branch instructions, a stack data structure accessible to the processor, and a stack pointer associated to the stack data structure, the stack pointer identifying an address in the stack data structure during execution of the program code by the processor, and a compiler unit coupled to the memory and processor, configured to access the program code from the memory, and generate, for each of the one or more branch instructions, a data value based on an output of a cryptographically secure function, wherein data values for respective branch instructions are generated based on a first input identifying the address of the stack pointer prior to an evaluation of the branch instruction, a second input encoding information indicative of a target address in the memory subsequent to evaluation of the branch instruction, and a third input comprising a cryptographically secure key.

In an implementation of the third aspect, the compiler unit can generate data values for memory access operations and/or function calls between branch instructions in the control flow of the program code, based on an output of the cryptographically secure function. The cryptographically secure function can be implemented using an instruction set extension. The instruction set extension can comprise a pointer authentication (PAuth) security extension. During execution of the program code the processor can validate the one or more data values based on the stack pointer and the cryptographically secure key. The processor can generate a fault exception in response to the compiler unit determining that one or more data values are invalid.

These and other aspects of the invention will be apparent from the embodiment(s) described below.

Brief Description of the Drawings

In order that the present invention may be more readily understood, embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic representation of a system according to an example;

Figure 2 is a flow chart of a method for providing forward edge CFI according to an example;

Figure 3 is a flow chart of a method for providing forward edge CFI according to an example; and Figure 4 is a flow chart of a method for providing forward edge CFI according to an example.

Detailed Description

Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.

Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.

The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and “the” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and/or groups thereof.

Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.

Source code written in languages such as C and C++ can comprise memory corruption vulnerabilities which can lead to execution of arbitrary (attacker) code. Data execution prevention (DEP) technologies have made direct code injection by attackers essentially impossible, which in turn has led attackers to concentrate on so-called code reuse attacks (CRA) in which an attacker can direct control flow through existing code with a malicious result. In general, CRAs are classified in three broad categories: jump-oriented (JOP), return-oriented (ROP) and data-oriented (DOP) programming. For example, return- oriented programming is a code -reuse attack in which short code sequences ending in a return instruction are found. In order to mitigate against such CRAs, dynamic control transfers can be constrained to protect return addresses and stack data.

Other mechanisms exist to subvert a forward edge (an indirect jump or call) in a controlflow graph (CFG). However, forward edges can be protected using Control-Flow Integrity (CFI), which provides a security policy used to ensure that an execution flow in program code comprising one or more branch instructions executable by a processor is valid when calling or returning from functions during runtime. That is, CFI can prevent such control-flow attacks by verifying that indirect control flow instructions target only functions in a program’s CFG. Forward-edge CFI refers to the security property that only the intended functions are called during program execution. In particular, attackers cannot force the program to call an unintended function supplied by the attacker. Such an attack is possible when functions are not called directly, but via function pointers stored in writable memory. In this case, an attacker may utilize a vulnerability that allows modifications to such functions pointers and make them point to carefully selected locations in the code to achieve a malicious purpose such as gaining privileges in the system that should not be granted to the attacker.

In the context of ROP attacks for example, pointer authentication can be provided by way of an extension to certain processor architectures and can provide statistical protection against ROP through the use of a dedicated “pass” in the source code compiler. Generally speaking, on a typical 64-bit microprocessor, memory addresses have fewer than 64 meaningful bits (e.g., only 48). This therefore leaves some unused bits in pointer values which can be used to carry a Message Authentication Code (MAC), called a Pointer Authentication Code (PAC). Such pointer authentication adds three types of instructions to the processor: PAC “signing” instructions to insert a PAC, and AUT “authentication” instructions to check the PAC, and generate hardware faults (exceptions) when verification of the PAC fails. In this case, there is no need to wait for the corrupted pointers to be used for hardware faults to occur. Another set instructions can be provided to strip the PAC. Thus, when a ROP attack is attempted the tampered return address will not authenticate, and the program encounters a fault. Accordingly, its execution can be ended immediately, thereby thwarting the attack. However, the pointer authentication extension does not typically support mitigation against other types of CRAs.

More specifically, during signing, the PAC operation takes a pointer value stored in a CPU register as input, optionally with another register that contains a 64-bit modifier. A cryptographically secure message authentication code (MAC) is computed from the pointer and the modifier, and the result (PAC) is inserted into the unused high bits in the pointer. During an AUT operation, such a signed pointer is verified against a modifier. If the signed pointer has not been tampered with, the AUT operation will succeed, and the PAC is removed from the signed pointer stored in a CPU register, and the pointer can then be used to call functions or load data from memory as usual. If the signed pointer has been tampered with, or the modifier is different from the one used during signing, the AUT operation will fail and the pointer is left corrupted, so that subsequent use of the pointer will cause a memory error. The cryptographic keys used by these operations are managed usually by a more privileged component in the system, such as the operating system, a hypervisor, or a trusted execution environment (TEE).

According to an example, there is provided a mechanism to provide protection against certain types of CRAs, such as JOP attacks for example. More specifically, aspects relate to pointer authentication extensions to protect against potential attacks. For example, a pointer authentication extension can be leveraged when executing program instructions on a processor that supports the extension. The mechanism provided advantageously preserves the official semantics of programming languages and does not require any change to source code. In particular, the representation (as defined by, e.g., ISO C and ISO C++) of pointers is not affected. Thus, in an example, instead of, e.g., signing a code address (such as return addresses, dispatch table label addresses and function pointers) or signing data pointers, forward-edge CFI can be provided by signing a stack pointer. In an example, a stack pointer comprises a pointer that is used to manage the stack of a system. Specifically, it can be used to point to a highest address previously used in the stack. When something new is pushed onto the stack, the stack pointer is decremented down to point at an address one below, and data to be written onto the stack is written to the address pointed at by the stack pointer. Conversely, a ‘pop off’ the stack provides data at the address of the stack pointer, which is then incremented to point to the next stack address.

In some implementations, the address of the stack pointer can be signed before a branch, and authenticated after the branch compared to the case the address is signed before storing it to memory and authenticated after reading back.

Examples in the present disclosure can be provided as methods, systems or machine- readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon.

The present disclosure is described with reference to flow charts and/or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and/or additional blocks may be added. It shall be understood that each flow and/or block in the flow charts and/or block diagrams, as well as combinations of the flows and/or diagrams in the flow charts and/or block diagrams can be realized by machine readable instructions.

The machine-readable instructions may, for example, be executed by a machine such as a general -purpose computer, user equipment such as a smart device, e.g., a smart phone, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing apparatus may execute the machine -readable instructions. Thus, modules of apparatus (for example, a module implementing a comparator unit, or a firewall structure and so on) may be implemented by a processor executing machine readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate set etc. The methods and modules may all be performed by a single processor or divided amongst several processors.

Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode. For example, the instructions may be provided on a non-transitory computer readable storage medium encoded with instructions, executable by a processor.

Figure 1 is a schematic representation of a system according to an example. The system 100 can be, e.g., a computing system or apparatus, user equipment, a network device (physical or virtual), or part thereof. The system 100 comprises a processor 103, and a memory 105 coupled to the processor 103 and configured to store instructions or program code 107, executable by the processor 103. In an example, the program code 107 comprises one or more branch instructions 109. A stack data structure 111 is accessible to the processor 103, and a stack pointer 113 is associated to the stack data structure 111. The stack pointer 113 identifies an address 115 in the stack data structure 111 during execution of the program code 107 by the processor 103. A mass storage 104 can be provided and may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via a bus 150. The mass storage 104 may comprise, for example, one or more of a solid state drive, hard disk drive, a magnetic disk drive, or an optical disk drive. In some example, the mass storage device can store data representing any one or more of the stack data structure 111, stack pointer 113, and address 115.

The bus 150 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus. The processor 103 may comprise any type of electronic data processors. The memory 105 may comprise any type of non-transitory system memory such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In an embodiment, the memory 105 may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs. According to an example, a compiler unit 117 is coupled to the memory 105 and the processor 103. The compiler unit 117 is configured to access the program code 107 from the memory 105 and generate, for each of the one or more branch instructions 109, a data value 119 based on an output 121 of a cryptographically secure function 123. Data values 119 for respective branch instructions 109 are generated based on a first input 125 identifying the address 115 prior to an evaluation of the branch instruction 109, a second input 127 encoding information indicative of a target address 129 in the memory 105 subsequent to evaluation of the branch instruction 109, and a third input 131 comprising a cryptographically secure key 133. In some examples code compilation may happen during the execution of a program. In this case, the program may be executed by an interpreter which translates source code into native instructions on-the-fly, or perform Just-in-Time (JIT) compilation on part of the program. In this case an interpreter or the JIT compiler may sign pointers and/or data, provided that they run in the same process space as the compiled code.

According to an example, the compiler unit 117 can generate data values 135 for memory access operations and/or function calls between branch instructions 109 in the control flow of the program code, based on an output of the cryptographically secure function 123, such as a message authentication code (MAC). In some cases such a MAC may be implemented in hardware using an instruction set extension. For example, the ARMv8.3 ISA provides an instruction set extension referred to as Pointer Authentication (PAuth).

Although PAuth provides many instructions, according to an example, two types of operations are provided by these instructions that are of interest, a signing operation, which can be denoted as: p <- PAC(p, modifier) and a verification (authentication) operation, which can be denoted as:

AUT(p, modifier)

In examples, during signing, the PAC operation takes a pointer value stored in a CPU register as input, optionally with another register that contains a 64-bit modifier. A cryptographically secure message authentication code (MAC) is computed from the pointer and the modifier, and the result (PAC) is inserted into the unused high bits in the pointer. During an AUT operation, such a signed pointer is verified against a modifier. If the signed pointer has not been tampered with, the AUT operation will succeed, and the PAC is removed from the signed pointer stored in a CPU register, and the pointer can then be used to call functions or load data from memory as usual. If the signed pointer has been tampered with, or the modifier is different from the one used during signing, the AUT operation will fail and the pointer is left corrupted, so that subsequent use of the pointer will cause a memory error. The cryptographic keys used by these operations are managed usually by a more privileged component in the system, such as the operating system, a hypervisor, or TEE.

Accordingly, during execution of the program code 107 the processor 103 is configured to validate the one or more data values 119 based on the stack pointer 113 and the cryptographically secure key 133. The processor 103 can generate a fault exception 137 in response to the compiler unit 117 determining that one or more of the data values 119 are invalid, thereby providing forward edge CFI.

Accordingly, the system can be used to implement a method for forward edge CFI. For example, the compiler unit 117 can be used to access the program code 107 and a 64-bit value that identifies or narrows down the set of legitimate targets as much as possible before a potentially corrupted code address (such as a function pointer) is used as the target of an indirect branch (BR or BER). Any suitable method to approximate of the CFG can be used. In practice, a unique ID can be used for the function callback type. The stack pointer 113 can then be signed using the above value as an input value such as a modifier, and one of the system-provisioned PA keys for example.

At a legitimate branch target code location, there will be a desire to balance out (or compensate for) the side effects of the changes from the previous case, so the compiler unit 117 can, in an example, insert matching instructions such that the same 64-bit value can be computed. The stack pointer 113 can then be authenticated using the above value as modifier, and one of the system-provisioned PA keys for example.

In a situation in which there are two corruptible branches, and if the stack pointer is not used at all but the in-between code accesses memory and/or calls other functions, a “dummy” load instruction from the stack pointer can be inserted. For example, a runtime check that the stack pointer is currently a valid address (not signed) can be performed. In an example, PAuth can be used to protect return addresses and achieve backward-edge CFI. In an example, because current PAuth instructions cannot use the actual stack pointer processor register as the input/output signee operand, the stack pointer is moved to a different register for signing and authentication.

Optimizations to the above can be implemented. For example, a different register can be selected as the stack pointer. This is because in some cases the nominal stack pointer cannot be used as proper operand as noted above. To avoid signing/authenticating on statically provably incorruptible (notably direct) branches, incorruptible branches can skip over the inserted stack pointer authentication code. This concerns, for instance, functions that are invoked both through corruptible function pointers, and directly, as well as exported shared library functions.

According to an example, after an indirect branch, depending on the branch target, the execution flow can be transferred. For example, the execution flow can be transferred to a function permitted by the CFG approximation in the event that signed stack pointer is authenticated successfully, and thus the code runs normally. Alternatively, in the event that execution flow is transferred to another function, the signed stack pointer will fail authentication and the code can fault immediately while writing the new stack frame record to an invalid stack pointer value. Alternatively, in the event that execution flow is transferred to the “middle” of code (e.g., not a function start address), there are several different outcomes. With branch target instructions (BTI), which are extensions providing crude protection against JOP attacks, the program code can fault immediately due to BTI failure (“Instruction abort” exception). Alternatively, without BTI, the program code can fault at some subsequent point due to the presence of the signed stack pointer instead of a normal stack pointer value. If a stack pointer is not used for an entire function or a long sequence of instructions, a load-XZR-from-SP instruction (or any instruction which causes a dereference of the stack pointer without causing interfering side effects on program execution) can be inserted to expedite check and faulting.

Accordingly, the system can implement a method for providing forward edge CFI by accessing, from a memory 105 of a computing system 100, program code 107 executable by a processor 103 of the computing system, the program code 107 comprising one or more branch instructions 109, a stack data structure 111 accessible to the processor 103, and a stack pointer 113 associated to the stack data structure 111, the stack pointer 113 identifying an address 115 in the stack data structure 111 during execution of the program code 107 by the processor 103. For each of the one or more branch instructions 109, a data value 119 based on an output of a cryptographically secure function 123 can be generated. Data values 119 for respective branch instructions 109 can be generated based on a first input 125 identifying the address 115 prior to an evaluation of the branch instruction 109, a second input 127 encoding information indicative of a target address 129 in the memory 105 subsequent to evaluation of the branch instruction 109, and a third input 131 comprising a cryptographically secure key 133. The method can further comprise generating data values for memory access operations and/or function calls between branch instructions in the control flow of the program code, based on an output of the cryptographically secure function. The cryptographically secure function can be implemented using an instruction set extension. For example, the instruction set extension can comprise a pointer authentication (PAuth) security extension. During execution of the program code by the processor, the one or more data values can be validated based on the stack pointer and the cryptographically secure key. A fault exception can be generated in response to determining that one or more data values are invalid, thereby enabling termination of the program code by the system for example.

Figure 2 is a flow chart of a method for providing forward edge CFI according to an example. In the example of figure 2, a legitimate branch function is provided. In block 201 normal execution of program code 107 by system 100 proceeds. As part of the normal execution, in block 203, a modifier is computed (using a cryptographic function generator, CFG, for example) and used to sign the stack pointer 113 in block 205. In block 207 an indirect branch is evaluated leading to a legitimate branch target in block 209. In block 211 a modifier for the legitimate branch target is evaluated using the CFG, which is then used to authenticate the stack pointer in block 213. In block 215, as the branch target is legitimate, the authentication is valid and normal execution proceeds in block 217, with stack pointer access enabled in block 219.

Figure 3 is a flow chart of a method for providing forward edge CFI according to an example. In the example of figure 3, a branch target mismatch is considered. In block 301 normal execution of program code 107 by system 100 proceeds. As part of the normal execution, in block 303, a modifier is computed (using a cryptographic function generator, CFG, for example) and used to sign the stack pointer 113 in block 305. In block 307 an indirect branch is evaluated leading to a branch target mismatch in block 309. In block 311 a modifier for the branch target is evaluated using the CFG, which is then used to authenticate the stack pointer in block 313. Because of the branch target mismatch, in block 215, the authentication fails and abnormal execution proceeds in block 317, with stack pointer access faults in block 319.

Figure 4 is a flow chart of a method for providing forward edge CFI according to an example. In the example of figure 4, a branch to an invalid target (not start of a function) is considered. In block 401 normal execution of program code 107 by system 100 proceeds. As part of the normal execution, in block 403, a modifier is computed (using a cryptographic function generator, CFG, for example) and used to sign the stack pointer 113 in block 405. In block 407 an indirect branch is evaluated leading to an invalid branch target in block 409. In block 411 the signed stack pointer fails authentication. Thus, because of the invalid branch target, in block 413, abnormal execution proceeds, with stack pointer access faults in block 415.

According to an example, machine-readable instructions can be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow(s) in the flow charts and/or block(s) in the block diagrams.

Further, the teachings herein may be implemented in the form of a computer or software product, such as a non-transitory machine-readable storage medium, the computer software or product being stored in a storage medium and comprising a plurality of instructions, e.g., machine readable instructions, for making a computer device implement the methods recited in the examples of the present disclosure.

In some examples, some methods can be performed in a cloud-computing or networkbased environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface of the user equipment for example. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment.

While various embodiments have been described and/or illustrated herein in the context of fully functional computing systems, one or more of these exemplary embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable- storage media used to actually carry out the distribution. The embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the exemplary embodiments disclosed herein. In addition, one or more of the modules described herein may transform data, physical devices, and/or representations of physical devices from one form to another.

The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure.

Claims

1. A computing system, comprising: a processor; a memory coupled to the processor, configured to store: program code executable by the processor, the program code comprising one or more branch instructions; a stack data structure accessible to the processor; and a stack pointer associated to the stack data structure, the stack pointer identifying an address in the stack data structure during execution of the program code by the processor; and a compiler unit coupled to the memory and processor, configured to: access the program code from the memory; and generate, for each of the one or more branch instructions, a data value based on an output of a cryptographically secure function, wherein data values for respective branch instructions are generated based on a first input identifying the address of the stack pointer prior to an evaluation of the branch instruction, a second input encoding information indicative of a target address in the memory subsequent to evaluation of the branch instruction, and a third input comprising a cryptographically secure key.

2. The computing system of claim 1, wherein the compiler unit is further configured to generate data values for memory access operations and/or function calls between branch instructions in the control flow of the program code, based on an output of the cryptographically secure function.

3. The computing system of claim 1 to 2, wherein the cryptographically secure function is implemented using an instruction set extension.

4. The computing system of claim 3, wherein the instruction set extension comprises a pointer authentication (PAuth) security extension.

5. The computing system of claim 1 to 4, wherein, during execution of the program code the processor is configured to validate the one or more data values based on the stack pointer and the cryptographically secure key.

6. The computing system of claim 5, wherein the processor is configured to generate a fault exception in response to the compiler unit determining that one or more data values are invalid.

7. A method comprising accessing, from a memory of a computing system, program code executable by a processor of the computing system, the program code comprising one or more branch instructions, a stack data structure accessible to the processor, and a stack pointer associated to the stack data structure, the stack pointer identifying an address in the stack data structure during execution of the program code by the processor; and generating, for each of the one or more branch instructions, a data value based on an output of a cryptographically secure function, wherein data values for respective branch instructions are generated based on a first input identifying the address of the stack pointer prior to an evaluation of the branch instruction, a second input encoding information indicative of a target address in memory subsequent to evaluation of the branch instruction, and a third input comprising a cryptographically secure key.

8. The method of claim 7, comprising generating data values for memory access operations and/or function calls between branch instructions in the control flow of the program code, based on an output of the cryptographically secure function.

9. The method of claim 7 or 8, wherein the cryptographically secure function is implemented using an instruction set extension.

10. The method of claim 9, wherein the instruction set extension comprises a pointer authentication (PAuth) security extension.

11. The method of claim 7 to 10, comprising validating, during execution of the program code by the processor, the one or more data values based on the stack pointer and the cryptographically secure key.

12. The method of claim 11, comprising generating a fault exception in response to determining that one or more data values are invalid.

13. A network device, comprising: a processor; a memory coupled to the processor, configured to store program code executable by the processor, the program code comprising one or more branch instructions; a stack data structure accessible to the processor; and a stack pointer associated to the stack data structure, the stack pointer identifying an address in the stack data structure during execution of the program code by the processor; and a compiler unit coupled to the memory and processor, configured to: access the program code from the memory; and generate, for each of the one or more branch instructions, a data value based on an output of a cryptographically secure function, wherein data values for respective branch instructions are generated based on a first input identifying the address of the stack pointer prior to an evaluation of the branch instruction, a second input encoding information indicative of a target address in the memory subsequent to evaluation of the branch instruction, and a third input comprising a cryptographically secure key.

14. The network device of claim 13, wherein the compiler unit is further configured to generate data values for memory access operations and/or function calls between branch instructions in the control flow of the program code, based on an output of the cryptographically secure function.

15. The network device of claim 13 to 14, wherein the cryptographically secure function is implemented using an instruction set extension.

16. The network device of claim 15, wherein the instruction set extension comprises a pointer authentication (PAuth) security extension.

17. The network device of claims 13 to 16, wherein, during execution of the program code the processor is configured to validate the one or more data values based on the stack pointer and the cryptographically secure key.

18. The network device of claim 17, wherein the processor is configured to generate a fault exception in response to the compiler unit determining that one or more data values are invalid.