Patent Publication Number: US-2020285736-A1

Title: Security-adaptive code execution

Description:
BACKGROUND 
     Attacks on computing systems are commonplace and take many forms. For example, an attacker may gain unauthorized access to a system and acquire private data stored therein and/or inject malware to invade, damage, or disable the system. In view of this threat, modern computing systems are typically designed to include various security features. 
     Since security features consume system resources, a trade-off exists between strength of security and system performance. Consequently, strong security features may consume an unacceptable amount of system resources if implemented in a low-resource embedded system or in a performance-critical system. Many of such systems are therefore designed with no security or with weak security. In a specific example, software functions written for such a system may include few or no security checks. 
     Systems are desired to provide improved security in resource-constrained environments. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of a platform executing code to provide adaptive security according to some embodiments. 
         FIG. 2  is a flow diagram of a process to provide adaptive security according to some embodiments. 
         FIG. 3  is a block diagram of an embedded system to execute security-adaptive code according to some embodiments. 
         FIG. 4  is a flow diagram of a process to generate security-adaptive code according to some embodiments. 
         FIG. 5  is a block diagram of a system to generate security-adaptive code according to some embodiments. 
         FIG. 6  is a diagram illustrating generation of security-adaptive code according to some embodiments. 
         FIG. 7  is a representation of security-adaptive code according to some embodiments. 
         FIG. 8  is a block diagram of a system to execute security-adaptive code according to some embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily-apparent to those in the art. 
     Some embodiments provide selective execution of two versions of a given software-implemented function. One version is a low- or no-security version of the function, which the other version is a higher-security version of the function. The higher-security function is selectively called based on evaluated criteria. Accordingly, certain security features are invoked sometimes (i.e., during some executions of the given function) and are not invoked at other times (i.e., during other executions of the given function). Embodiments may therefore consume fewer resources than a system in which the higher-security version of the function is always executed, while still occasionally providing the security features of the higher-security version of the function. 
       FIG. 1  is a block diagram of a system according to some embodiments. Platform  100  includes code execution unit  110  and memory  120  storing executable code  125 . Platform  100  may comprise any type of computing platform for executing code that is or becomes known. Platform  100  may include any number of other devices, peripherals, integrated circuits, discrete circuits, and mechanical elements (e.g., cooling elements and interconnects) as is known. 
     Code execution unit  110  may comprise a central processing unit, a processing core, a processing thread, or any other entity to execute machine code. Code execution unit  110  executes executable code  125  to perform functions embodied therein. 
     Executable code  125  may comprise machine code which is directly executable by code execution unit  110 . In some embodiments, code  125  comprises pre-compiled higher-level code which is subjected to Just-in-Time compiling prior to execution by code execution unit  110  as is known in the art. 
       FIG. 1  illustrates portion  130  of executable code  125  according to some embodiments. The contents of portion  130  are depicted symbolically to provide an understanding of the machine code represented thereby. As depicted, portion  130  includes code  132  to execute Function X. Accordingly, code  132  is executed if Function X is called during execution of another portion of code  125  by code execution unit  110 . Function X may be called with input parameters as is known in the art. 
     Code  132  includes code of three functions: a Security Adaptation function; Function X S ; and Function X R . Generally, Function X R  and Function X S  both perform Function X, and Function X S  performs Function X in a more secure manner than Function X R . For example, Function X S  may provide one or more of stack cookie protection, extended checks, extended logging, and secure function analogs that include buffers size checks. Function X S  may provide any other security features/methods/techniques that are or become known. 
     Function X R  may provide some or no security features. In some embodiments, Function X R  consumes fewer processing resources than Function X S . 
     The Security Adaptation function determines whether to perform Function X S  or Function X R  in response to a call to Function X. Accordingly, a call to Function X results in execution of Function X S  some of the time and execution of Function X R  at other times. Embodiments may therefore provide higher security at the cost of more processing resources during some executions of Function X and lower security and less resource consumption during other executions of Function X. 
     The determination of whether to execute Function X S  or Function X R  may be based on any one or more suitable criteria. In some non-exhaustive examples, the determination may be based on a counter (e.g., Function X S  is performed once for every 100 calls to Function X), based on a statistical mechanism (e.g., Function X S  is performed each time bits x, y and z are enabled in the packet checksum has enabled, based on a performance metric (e.g., Function X S  is performed if the amount of free computation resources is above a given threshold), and/or based on a security profile of the input/environment (e.g., Function X S  is performed if the determined security risk is above a given threshold). 
     According to some embodiments, Function X S  performs Function X in a different, but not necessarily more secure, manner than Function X R . In a non-limiting example, Function X S  may perform Function X and also provide debug functionality, while Function X R  simply performs Function X. In such an embodiment, the Adaptation function is a Debug Adaptation function which may determine whether Function X should be performed with debug functionality and pass control to either Function X R  or Function X S  based on the determination. 
       FIG. 2  is a flow diagram of process  200  to provide adaptive execution of a secure function according to some embodiments. Process  200  and the other processes described herein may be performed using any suitable combination of hardware or software. Executable code embodying these processes may be executed by a central processing unit of a microprocessor or microcontroller, for example, and may be stored in any non-transitory tangible medium, including a read-only memory, a volatile or non-volatile random access memory, a fixed disk, a DVD, a Flash drive, or a magnetic tape. Embodiments are not limited to the examples described below. 
     Prior to process  200 , it is assumed that a security-adaptive function (e.g., Function X) is called during execution of program code by a code execution unit. Next, at S 210 , it is determined whether to execute a regular version or a secure version of the function. For purposes of the present description, the regular version of the function is less secure and less resource-consuming than the secure version of the function. 
     The determination at S 210  may be performed by an adaptation function (e.g., the Security Adaptation function of code  132 ) which is first executed in response to a call to the security-adaptive function. In some embodiments, the determination is performed by the calling function (e.g., if rand(100) call f_regular; else call f_secure). 
     Flow proceeds to S 220  if it is determined at S 210  to execute the regular version of the function, based on criteria such as that described above or on other criteria. Accordingly, the regular version of the function (e.g., Function X R ) is executed at S 220  and program flow returns to the calling function at S 230 . 
     The secure version of the function (e.g., Function X S ) is executed at S 240  if it is determined at S 210  to execute the secure version of the function. Flow then returns at S 230  as described above. 
       FIG. 3  depicts embedded system  300  according to some embodiments. Embedded system  300  may possess limited processing resources. Accordingly, embodiments may provide security to functions executed by system  300  while consuming fewer resources than would otherwise be consumed. 
     System  300  may comprise a microcontroller including CPU  310 , memory  320  storing executable code  325  including one or more security-adaptive functions as described herein, random number generator  330  which may be usable in determining whether to execute a secure version or a regular version of a function, Read Only Memory (ROM)  340  and I/O interface  350 . Some embodiments may be implemented in any microcontroller configuration. 
     According to some embodiments, a developer simply writes source code of a function (e.g., Function X) which includes a regular version of the function (e.g., Function X R ), a secure version of the function (e.g., Function X S ), and a security adaptation determination (e.g., the Security Adaptation function of Function X) which selectively calls the regular version or the secure version based on the determination. The source code is compiled (along with other source code) to generate corresponding machine-executable code. 
     In contrast,  FIG. 4  is a flow diagram of process  400  to generate a security-adaptive function using compiler flags according to some embodiments. Prior to process  400 , a developer writes compilable source code to execute a function. The developer also associates one or more compiler flags with the function to indicate that the compiler should generate a security-adaptive function based on the source code. The one or more compiler flags may indicate that the security-adaptive function should be generated, and may also indicate one or more security features to include in the secure version of the function, criteria to be used in the determination of whether to execute the regular version or the secure version of the function, and/or other suitable parameters. 
       FIG. 5  illustrates a cloud-based development environment according to some embodiments. Developer system  510  may communicate with cloud-based integrated development environment  520  to generate the above-mentioned compilable source code. Environment  520  may then execute process  400  based on the source code. The source code may be developed and compiled entirely on system  510  without use of a remote environment such as environment  520  in some embodiments. 
     Returning to process  400 , the compilable code is received by a compiler at S 410 . During compilation, it is determined at S 420  whether the function is associated with a flag indicating that the compiler should generate a security-adaptive function based thereon. If not, flow proceeds to S 450  to generate a compiled (e.g., object code) regular version of the function. 
     If the determination at S 420  is affirmative, a compiled secure version of the function is generated at S 430 . As mentioned above, the source code of the function may be associated with flags indicating security features to be included in the secure version. 
     An adaptation function associated with the function is generated at S 440 . The adaptation function may be executed to determine whether to execute the regular version of the function or the secure version of the function. Generation of the adaptation function may be based on compiler flags which specify parameters and/or logic of the determination performed by the adaptation function. A regular version of the function is then generated at S 450  as described above. 
     As noted above, the calling function may determine whether to call the regular version or the secure version of a function in some embodiments. S 440  may be omitted in such scenarios (i.e., an adaptation function is not needed). 
       FIG. 6  depicts process  400  according to some embodiments. Source code  610  includes on or more functions which are flagged as described. Compiler  620 , which may be implemented in any manner that is or becomes known, receives code  610  and generates executable code  630  including security-adaptive functions corresponding to the flagged functions. In some embodiments, compiler  620  generates object code based on code  610  and links the object code with other (unshown) object code to generate executable code  630 . 
     Code  630  may include one or more security-adaptive functions.  FIG. 7  depicts code  700  including more than one security-adaptive functions according to some embodiments. Code  700  includes executable code of Function X, Function Y and Function Z. Function X is a security-adaptive function similar to Function X of  FIG. 1 . Function Y includes code to perform a single version of Function Y and is therefore not security-adaptive as described herein. 
     Function Z includes a Security Adaptation function and a regular function (i.e., Function Z R ) as described herein. Function Z also includes two secure versions, Function Z S1  and Function Z S2 . Function Z S1  and Function Z S2  may provide different security features, with one being more secure and more resource-intensive than the other. Function Z S1  and Function Z S2  may be similarly resource-intensive but provide different security features. The Security Adaptation function of Function Z therefore determines which one of Function Z R , Function Z S1  and Function Z S2  to execute in response to a call to Function Z. 
       FIG. 8  is a block diagram of computing system  800  to execute code including security-adaptive functions as described herein. System  800  may comprise a general-purpose computer. For example, system  800  may comprise a computer implementing platform  100  in some embodiments. 
     System  800  includes microprocessor  810  operatively coupled to communication device  820 , persistent data storage system  830 , one or more input devices  840 , one or more output devices  850  and volatile memory  860 . Microprocessor  810  may comprise one or more processors, processing cores, etc. for executing program code. Communication interface  820  may facilitate communication with external devices, such as networked devices. Input device(s)  840  may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, a touch screen, and/or an eye-tracking device. Output device(s)  850  may comprise, for example, a display (e.g., a display screen), a speaker, and/or a printer. 
     Data storage system  830  may comprise any number of appropriate persistent storage devices, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc. Memory  860  may comprise Random Access Memory (RAM), Storage Class Memory (SCM) or any other fast-access memory. 
     Data storage system  830  stores code  832  including security-adaptive functions. Code  832  may comprise a software application providing any functionality that is or becomes known. Resource monitor  834  may comprise code executable to monitor system resources. Such monitoring may be used by code  832  to determine whether to execute a regular or a secure version of a function. Data storage device  830  may store code of other software applications, which do or do not include security-adaptive functions as described herein. Data storage device  830  may also store data and other program code for providing additional functionality and/or which are necessary for operation of system  800 , such as device drivers, operating system files, etc. 
     The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each component or device described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each component or device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. 
     Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.