Antifragile software systems

Abstract

The method (300) includes generating (304) output code (112a-112m) based on input code (104a-104m) using a compiler or translator (102) and providing (306) the output code to one or more platforms (114a-114n) for execution. The method also includes receiving (308) feedback (118) related to the execution of the output code, the feedback identifying at least one of one or more defects during execution of the output code and one or more performance characteristics of the execution of the output code. The method further includes modifying (312) the compiler or translator based on the feedback and generating (314) additional output code (112a-112m) using the modified compiler or translator (102).

Description

[Technical Field]

[0001] This disclosure is directed generally to software systems, and more particularly to antifragile software systems. [Background technology]

[0002] Software systems (devices or systems that run software applications) can be fragile at various points, including immediately after software implementation and during early software testing. For example, software systems can frequently crash during real-world use due to unexpected events that cause the software to be unable to handle real-world conditions. No software is perfect, and all software experiences (possibly catastrophic) failures, even after rigorous real-world testing. Unfortunately, the cycle times required for software data collection, analysis, and patching can be prohibitive. Some applications, such as defense-related applications, may not be able to tolerate these long cycle times. Summary of the Invention

[0003] The present disclosure relates to antifragile software systems.

[0004] In a first embodiment, a method includes generating output code based on input code using a compiler or translator and providing the output code to one or more platforms for execution. The method also includes receiving feedback related to the execution of the output code, the feedback identifying at least one of one or more defects during execution of the output code and one or more performance characteristics of the execution of the output code. The method further includes modifying the compiler or translator based on the feedback and generating additional output code using the modified compiler or translator.

[0005] In a second embodiment, an apparatus includes at least one processor configured to generate output code based on input code using a compiler or translator and provide the output code to one or more platforms for execution. The at least one processor is also configured to receive feedback related to execution of the output code, the feedback identifying at least one of one or more defects during execution of the output code and one or more performance characteristics of the execution of the output code. The at least one processor is further configured to modify the compiler or translator based on the feedback and generate additional output code using the modified compiler or translator.

[0006] In a third embodiment, a non-transitory computer-readable medium includes instructions that, when executed, cause at least one processor to generate output code based on input code using a compiler or translator and provide the output code to one or more platforms for execution. The medium also includes instructions that, when executed, cause the at least one processor to receive feedback related to execution of the output code, the feedback identifying at least one of one or more defects during execution of the output code and one or more performance characteristics of the execution of the output code. The medium further includes instructions that, when executed, cause the at least one processor to modify the compiler or translator based on the feedback and to generate additional output code using the modified compiler or translator.

[0007] Other technical features will be readily apparent to those skilled in the art from the following drawings, descriptions, and claims.

[0008] For a more complete understanding of the present disclosure, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0009] [Figure 1] 1 illustrates an exemplary system for supporting antifragile software generation in accordance with the present disclosure.

[0010] [Figure 2] 1 illustrates an exemplary device that supports antifragile software generation in accordance with the present disclosure.

[0011] [Figure 3] 1 illustrates an exemplary antifragile software generation method according to the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0012] 1 through 3 described below and the various embodiments used to explain the principles of the present disclosure are exemplary only and should not be construed as limiting the scope of the present disclosure in any way. Those skilled in the art will understand that the principles of the present disclosure can be implemented in any type of suitably arranged device or system.

[0013] As mentioned above, software systems (devices or systems that run software applications) can be fragile at various times, including immediately after the software is implemented and during early software testing. For example, software systems can frequently crash during real-world use due to unexpected events that prevent the software from handling real-world conditions. No software is perfect, and all software experiences (possibly catastrophic) failures, even after rigorous real-world testing. Unfortunately, the cycle times required for software data collection, analysis, and patching can be prohibitive. Some applications, such as defense-related applications, may not be able to tolerate these long cycle times.

[0014] This disclosure provides various techniques for generating antifragile software. As described in more detail below, these techniques utilize an ahead-of-time (AoT) compilation or translation process (such as that supported by the WebAssembly workflow) to create binary code or native machine code based on input code. These techniques use various mechanisms during the AoT compilation or translation process to incorporate knowledge from previous executions of the software, such as previous defects during the software execution and previous performance characteristics associated with the software execution. Other knowledge, such as security issues or other issues associated with the previous software, may also be used. This knowledge enables the AoT compilation or translation process to generate binary or native machine code that is more resilient to failure conditions, more secure, and improves performance. For example, this knowledge can be used to reduce or eliminate defects identified during subsequent software executions, improve performance characteristics during subsequent software executions, or improve security during subsequent software executions. The AoT compilation or translation process can be repeated multiple times, with subsequent iterations of the AoT compilation or translation process incorporating increasingly more knowledge from previous runs of the software. As a result, the AoT compilation or translation process can support the production of antifragile software by producing software that becomes increasingly less fragile over time. These approaches can also support self-repairing and self-optimizing software.

[0015] FIG. 1 illustrates an exemplary system 100 that supports antifragile software generation in accordance with the present disclosure. As shown in FIG. 1, the system 100 includes a WebAssembly compiler / translator 102, which generally operates to convert one or more instances of input code 104a-104m into an executable format. Here, the WebAssembly compiler / translator 102 compiles or interprets each instance of input code 104a-104m into corresponding WebAssembly (WASM) assembly language code 106. The WebAssembly compiler / translator 102 can also convert the WASM assembly language code 106 into WASM binary code 108. The WebAssembly compiler / translator 102 may further convert the WASM binary code 108 into native code 110. The WebAssembly compiler / translator 102 provides output code 112a-112m corresponding to input code 104a-104m, with each instance of output code 112a-112m representing WASM binary code 108 or native code 110 associated with the corresponding instance of input code 104a-104m.

[0016] The WebAssembly compiler / translator 102 includes any suitable logic for translating input code into WASM assembly code, WASM binary code, and / or native code. Various compilers and translators have been developed for the WebAssembly language, and additional compilers and translators for the WebAssembly language will certainly be developed in the future. Any of these WebAssembly compilers and translators (modified as described below) can be used herein to support the generation of antifragile software. The WebAssembly compiler / translator 102 supports the use of various types of input code languages, such as C, C++, Rust, Ada, Go, Haskell, FORTRAN, and COBOL (to name just a few).

[0017] As used herein, one or more instances of the output code 112a-112m can be provided to one or more platforms 114a-114n for execution. The platform 114a-114n used herein can vary widely based on the application. For example, at least one platform 114a-114n may include an internet browser and may execute one or more instances of the output code 112a-112m within the internet browser. At least one platform 114a-114n may support the WebAssembly System Interface (WASI) specification, enabling one or more instances of the output code 112a-112m to be executed on a server, embedded system, or other system without modification. At least one platform 114a-114n may support the use of a runtime operating system (RTOS) that may execute one or more instances of the output code 112a-112m. At least one platform 114a-114n may enable virtual execution of one or more instances of the output code 112a-112m, thereby enabling (among other things) digital simulation execution of the output code 112a-112m and possibly identification of defects or other problems with the output code 112a-112m. As particular examples, the platforms 114a-114n may include one or more x86-based platforms, ARM-based platforms, MIPS-based platforms, or PowerPC-based platforms.

[0018] The input codes 104a-104m and output codes 112a-112m can support any desired functionality depending on the application. For example, the input codes 104a-104m and output codes 112a-112m can support functionality such as internet browser gaming, video conferencing, Internet of Things (IoT) security, sensor or actuator functionality, or a wide range of other applications running on Windows, Linux, embedded, or other operating systems. As another example, the input codes 104a-104m and output codes 112a-112m can be used with a variety of weapon systems, and the specific output codes provided to a particular weapon system can be changed based on the current mission or tactical environment.

[0019] The compilation / translation fixer 116 uses various information to fix the operation of the WebAssembly compiler / translator 102. For example, the compilation / translation fixer 116 can receive feedback 118 regarding the execution of the software on the platforms 114a-114n, such as information identifying what malfunctions the software (such as previously generated output code 112a-112m) encountered during execution or how it performed during execution on one or more platforms 114a-114n. As a particular example, the feedback 118 can identify any malfunctions that occurred during a previous execution of the software, memory usage characteristics that occurred during a previous execution of the software, or other characteristics of a previous execution of the software. This allows the compilation / translation fixer 116 to collect appropriate telemetry related to the software execution and use the telemetry to improve its next iteration or usage of the WebAssembly compiler / translator 102. The compilation / translation fix function 116 can also optionally receive information from one or more external sources 120, for example, information identifying security vulnerabilities in the software or information from one or more users.

[0020] The compilation / translation fixer 116 uses these types of information to modify how the WebAssembly compiler / translator 102 converts input code 104a-104m into output code 112a-112m in order to make future instances of output code 112a-112m less fragile (robust). For example, the compilation / translation fixer 116 may cause the WebAssembly compiler / translator 102 to change how it generates output code 112a-112m from input code 104a-104m in order to avoid defects in the output code 112a-112m, improve performance, or increase security. Exemplary ways in which the compilation / translation fixer 116 can modify how the WebAssembly compiler / translator 102 converts input code 104a-104m into output code 112a-112m are provided below. It should be noted that these examples are for illustrative purposes only, and any other or additional modifications can be made to the operation of the WebAssembly compiler / translator 102 to change how it generates the output code 112a-112m.

[0021] One exemplary modification that can be made to the operation of the WebAssembly compiler / translator 102 is to include metrics related to the actual or simulated execution of the output code 112a-112m in the feedback 118. Examples of the types of metrics that may be included in the feedback 118 can include memory stack allocation, control flow graphs, and memory heap interactions. The compilation / translation fixer 116 can use these metrics to modify subsequent iterations of the WebAssembly compiler / translator 102, such as by modifying how memory stack allocation, control flow graphs, and memory heap interactions are implemented in subsequently generated output code 112a-112m. As a particular example, the compilation / translation fixer 116 can modify how the WebAssembly compiler / translator 102 allocates memory for the stack, such as by increasing or decreasing the size of the allocated stack. The compilation / translation fixer 116 can modify how the WebAssembly compiler / translator 102 allocates and frees memory locations, for example, by allocating more or less memory, or by freeing memory locations earlier or later in the output code 112a-112m. The compilation / translation fixer 116 can modify how the WebAssembly compiler / translator 102 inserts traps into the output code 112a-112m, for example, by inserting or removing traps that attempt to access unavailable memory locations or otherwise interrupt the normal flow control of executed instructions.These types of changes can be based on previous bugs and performance characteristics associated with previous executions of the software by one or more platforms 114a-114n, thereby enabling subsequent operations of the WebAssembly compiler / translator 102 to produce output code with fewer bugs or improved performance.

[0022] Another example modification that can be made to the operation of the WebAssembly compiler / translator 102 may involve obtaining information from one or more external sources 120 that identifies attack vectors or other vulnerabilities associated with previous cyber-attacks. For example, this information may identify how side-channel attacks (such as Spectre and Meltdown attacks) rely on hardware or software vulnerabilities. The compilation / translation modification function 116 can modify how the WebAssembly compiler / translator 102 generates output code 112a-112m to fully or partially avoid these types of vulnerabilities.

[0023] Yet another exemplary modification that can be made to the operation of the WebAssembly compiler / translator 102 may involve obtaining information from one or more external sources 120, which information identifies one or more portions of code to be translated or otherwise converted into output code 112a-112m. The one or more portions of code to be converted into output code 112a-112m may be identified based on any suitable criteria. In some cases, code licensed for use by one or more particular users, organizations, or platforms 114a-114n may be selected. In other cases, code classified based on a particular confidentiality classification may or may not be selected for conversion. In still other cases, one or more environmental sensors or configurations may be used to provide information that can be used to select the code to be converted. The compilation / translation modification function 116 may use this information to selectively generate output code 112a-112m associated with selected portions of the input code 104a-104m, WASM assembly language code 106, WASM binary code 108, or native code 110. This allows the compilation / translation fixer 116 and / or the WebAssembly compiler / translator 102 to effectively act as a runtime "pre-processor" at the assembly level or other levels.

[0024] As yet another example of modifications that can be made to the operation of the WebAssembly compiler / translator 102, the compilation / translation modification function 116 can support runtime execution obfuscation by using binary diversity on the output code 112a-112m. Binary diversity refers to the randomization of various execution parameters of binary code and is a powerful cyber risk mitigation strategy. By randomizing the layout of instructions or data in memory, each executable binary is unique, preventing attackers from reliably launching exploits across a set of targets. Binary diversity typically involves randomizing the layout of code and data at each power-on, but the runtime execution environment must accommodate this randomization (typically by using indirect function calls that rely on lookup tables). However, these operations add a nontrivial penalty to runtime performance due to additional memory accesses and can introduce inefficiencies in the processor's branch history prediction logic, among other things. Additionally, the resulting increased attack surface of a software system as a result of indirect branching increases its susceptibility to attacks such as Spectre and attacks that violate control flow integrity.

[0025] The compilation / translation fixer 116 can support different approaches to binary diversity, such as by focusing on “per-asset” diversity rather than “per-power-up” diversity. For example, the compilation / translation fixer 116 can introduce binary diversity during generation of the output code 112a-112m. This binary diversity can include randomizing the order of at least some function code blocks and the location of at least some data in memory. This binary diversity can also include randomizing the amount of stack space allocated to each of one or more functions in the output code 112a-112m. As a specific example, stack space randomization can add randomized padding beyond the requested allocation as defined in the original input code 104a-104m or the associated WASM assembly language code 106, WASM binary code 108, or native code 110. The added randomized padding can be limited to a maximum allowable amount. Heap memory allocation requests may similarly be randomly padded up to some maximum allowable amount. This binary diversity may further include the insertion of chaff loops (loops that briefly perform unnecessary or irrelevant operations), nonsense conditional statements (conditions that are always or never satisfied), no-op (NOP) instructions (instructions that do nothing), and resumes (stopping loops or other operations and restarting them). Generally, these modifications represent modifications that can be made to the output code 112a-112m without affecting the outcome of the function performed by the output code 112a-112m.

[0026] Note that this approach to binary diversity maintains the performance benefits of direct branching to functions and eliminates the reliance on indirect function calls and lookup tables. Also, note that compilation or translation of WASM assembly language code 106 or WASM binary code 108 to native code 110 can be performed on command or during a particular mode of the software system. For example, a refresh of native code based on WASM assembly code (or some other compilation or translation) can be performed during an extended built-in test (BIT) of the software system or during a reprogramming operation of the software system. Also, note that the compilation or translation and associated diversity operation can be performed offline. Furthermore, note that independently isolated runtime binaries can be instantiated multiple times on processing cores with binary diversity, enabling standby redundancy on embedded software systems.

[0027] In some cases, one or more of the platforms 114a-114n, as used herein, may represent at least one simulated version of one or more actual platforms. For example, the platforms 114a-114n may represent a "digital twin" of an actual platform used to execute code, meaning that the platforms 114a-114n are designed to mimic the behavior (including code execution and memory access behavior) of the actual platform. In these embodiments, the WebAssembly compiler / translator 102 generates output code 112a-112m, runs the output code on at least one platform 114a-114n that simulates the actual platform, and uses feedback 118 to modify additional versions of the output code 112a-112m. This enables the compilation / translation modification function 116 to iteratively (and rapidly) determine improvements to the compilation / translation process(es) performed by the WebAssembly compiler / translator 102 when generating the output code 112a-112m.

[0028] In some embodiments, the compilation / translation fixer 116 uses at least one trained machine learning model to adjust the operation of the WebAssembly compiler / translator 102 based on feedback 118, information from external source(s) 120, or any other or additional information. For example, the machine learning model may be trained by providing different instances of input code 104a-104m to the WebAssembly compiler / translator 102 to generate associated output code 112a-112m, running the associated output code 112a-112m using one or more simulated or actual platforms 114a-114n, adjusting the WebAssembly compiler / translator 102 using feedback 118, and generating additional output code 112a-112m that is run using one or more simulated or actual platforms 114a-114n. Optionally, input from one or more users may be obtained herein, such as when notifying a user that the runtime behavior of the generated output code 112a-112m deviates from desired or normal runtime behavior (in which case the user may provide input identifying whether the deviation is acceptable or unacceptable and possible remedies for the deviation). This process may be repeated any number of times to train a machine learning model to identify which modifications to the generation of output code 112a-112m by the WebAssembly compiler / translator 102 result in improved characteristics of the output code 112a-112m (e.g., fewer defects, improved performance, increased security, improved binary diversity, etc.). Once trained, the trained machine learning model may be used by compilation / translation modification functionality 116 to determine how to compile / translate additional instances of input code 104a-104m.

[0029] Overall, the approach supported by the compilation / translation fixer 116 is useful for improving the quality of software generated by the WebAssembly compiler / translator 102 for one or more platforms 114a-114n and reducing the risks associated with the software. These risks can include computing hardware defects, cyber-exploit attempts, and environmental impacts. Specific risks that can be reduced include random-access memory defects, radiation-induced single-event effects (SEEs), unresponsiveness of peripheral hardware devices, hardware vulnerabilities (such as Spectre and Meltdown attacks), and cyber-attacks related to memory management defects. Furthermore, the approach supported by the compilation / translation fixer 116 enables WebAssembly-based "templates" to become reference architectures for building antifragile software-intensive systems. In an antifragile approach, the generated software system becomes stronger and more reliable with exposure to adverse conditions. Furthermore, these approaches can be used to support self-repair and self-optimization of software systems.

[0030] It should be noted that the various functions illustrated in FIG. 1 and described above may be implemented in system 100 in any suitable manner. For example, in some embodiments, the various functions of FIG. 1 may be implemented or supported using one or more software applications or other software / firmware instructions executed by at least one processor or other processing device. In other embodiments, at least some of the functions of FIG. 1 may be implemented or supported using dedicated hardware components. In general, the functions of FIG. 1 described above may be performed using any suitable hardware or any suitable combination of hardware and software / firmware instructions.

[0031] While Figure 1 illustrates an example system 100 that supports antifragile software generation, various modifications may be made to Figure 1. For example, components may be added, omitted, combined, further subdivided, duplicated, or arranged in any other suitable configuration depending on particular needs. As a particular example, system 100 may be used to translate any number of input code instances into output code instances for any number of platforms, and system 100 may include any number of WebAssembly compiler / translators 102.

[0032] Figure 2 illustrates an example device 200 that supports antifragile software generation in accordance with this disclosure. One or more devices 200 may be used to implement, for example, the functionality of the WebAssembly compiler / translator 102 and the compilation / translation fixer 116 of Figure 1. However, the WebAssembly compiler / translator 102 and the compilation / translation fixer 116 may each be implemented in any other suitable manner.

[0033] 2, device 200 represents a computing device or system that includes at least one processing device 202, at least one storage device 204, at least one communication unit 206, and at least one input / output (I / O) unit 208. Processing device 202 may execute instructions that may be loaded into memory 210. Processing device 202 includes any suitable number(s) and type(s) of processors or other processing devices in any suitable arrangement. Exemplary types of processing device 202 include one or more microprocessors, microcontrollers, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or discrete circuits.

[0034] Memory 210 and persistent storage 212 are examples of storage device 204, representing any structure(s) that can store and facilitate retrieval of information (such as data, program code, and / or other suitable information, whether temporary or persistent). Memory 210 can represent random access memory or any other suitable volatile or non-volatile storage device(s). Persistent storage 212 can include one or more components or devices that support longer-term storage of data, such as read-only memory, a hard drive, flash memory, or an optical disk.

[0035] The communications unit 206 supports communications with other systems or devices. For example, the communications unit 206 may include a network interface card or a wireless transceiver that facilitates communications over a wired or wireless network. The communications unit 206 may support communications over any suitable physical or wireless communications link(s). The communications unit 206 may, for example, support receiving input codes 104a-104m and providing output codes 112a-112m.

[0036] I / O unit 208 allows for the input and output of data. For example, I / O unit 208 may provide a connection for user input via a keyboard, mouse, keypad, touchscreen, or other suitable input device. I / O unit 208 may also send output to a display or other suitable output device. Note, however, that if device 200 does not require local I / O, for example, if device 200 represents a server or other device that can be accessed remotely, I / O unit 208 may be omitted.

[0037] In some embodiments, the instructions executed by the processing device 202 include instructions that implement functionality of the WebAssembly compiler / translator 102 and / or the compilation / translation modification function 116. Thus, for example, the instructions executed by the processing device 202 may convert input code 104a-104m into output code 112a-112m. Additionally, or alternatively, the instructions executed by the processing device 202 may modify the conversion of the input code 104a-104m into the output code 112a-112m based on feedback 118, information from external source(s) 120, or any other or additional information. Exemplary techniques for modifying the conversion of the input code 104a-104m into the output code 112a-112m are provided above.

[0038] In particular embodiments, at least the functionality of the compilation / translation correction function 116 (and possibly the WebAssembly compiler / translator 102) may be implemented using an FPGA (processing device 202) embedded in a larger system, allowing for rapid generation of output code 112a-112m, if needed or desired. In other particular embodiments, at least the functionality of the compilation / translation correction function 116 (and possibly the WebAssembly compiler / translator 102) may be implemented using firmware embedded in or otherwise accessible to the processing device 202.

[0039] Although Figure 2 illustrates an example of a device 200 that supports antifragile software generation, various modifications can be made to Figure 2. For example, computing and communication devices and systems come in a wide variety of configurations, and Figure 2 does not limit the disclosure to any particular computing or communication device or system.

[0040] Figure 3 illustrates an exemplary antifragile software generation method 300 according to the present disclosure. For ease of explanation, method 300 is described as being performed by device 200 shown in Figure 2 using system 100 shown in Figure 1. However, method 300 may be performed using any other suitable device or system.

[0041] As shown in FIG. 3, step 302 receives input code, and step 304 generates output code related to the input code using a WebAssembly compiler / translator. This may include, for example, the processing device 202 receiving input code 104a-104m, which may be obtained from any suitable source(s). This may also include the processing device 202 executing or otherwise implementing the WebAssembly compiler / translator 102 to generate output code 112a-112m based on the input code 104a-104m. Step 306 provides the output code to one or more platforms for execution. This may include, for example, the processing device 202 providing the output code 112a-112m to one or more real or simulated platforms 114a-114n for execution.

[0042] Step 308 may receive feedback information related to the execution of the output code by one or more platforms, and step 310 may receive additional information from one or more external sources. This may include, for example, the processing device 202 receiving feedback 118 including telemetry related to the execution of the output code 112a-112m by one or more real or simulated platforms 114a-114n. This may also include the processing device 202 receiving information from one or more external sources 120, such as information related to cybersecurity risks or information from one or more users (which may or may not be specifically related to the previously generated and executed output code 112a-112m).

[0043] Step 312 determines, based (at least in part) on the received information, how to modify the operation of the WebAssembly compiler / translator. This may include, for example, having the processing device 202 execute or otherwise implement a compilation / translation modification function 116 to determine how to modify the operation of the WebAssembly compiler / translator 102. As described above, the compilation / translation modification function 116 can modify the operation of the WebAssembly compiler / translator 102 in various ways. For example, the compilation / translation modification function 116 can use metrics (e.g., memory stack allocation, control flow graph, and memory heap interaction) in feedback 118 related to actual or simulated execution of the output code 112a-112m, and the compilation / translation modification function 116 can use these metrics to modify subsequent iterations of the WebAssembly compiler / translator 102 (e.g., modify how it implements memory stack allocation, control flow graph, and memory heap interaction). The compilation / translation fixer 116 can use information related to cybersecurity threats to fix how the WebAssembly compiler / translator 102 generates output code 112a-112m to completely or partially avoid creating certain types of vulnerabilities in the output code 112a-112m. The compilation / translation fixer 116 can use information about one or more portions of code that are translated or otherwise converted into the output code 112a-112m to fix the operation of the WebAssembly compiler / translator 102 to only convert one or more portions of the code. The compilation / translation fixer 116 can use information about the target platform or other information to determine how to provide binary diversity in the output code 112a-112m.

[0044] At step 314, additional output code (of the same original input code or different input code) is generated, which at step 316 is provided to one or more platforms for execution. This may include, for example, the processing device 202 executing or otherwise implementing the WebAssembly compiler / translator 102 to generate additional output code 112a-112m using the same input code 104a-104m received at step 302, or using additional input code 104a-104m. Note that, herein, the WebAssembly compiler / translator 102 generates the additional output code 112a-112m in a modified manner relative to step 304 due to modification(s) made by the compilation / translation modification function 116 to the operation of the WebAssembly compiler / translator 102. This may also include the processing device 202 providing the additional output code 112a-112m to one or more real or simulated platforms 114a-114n for execution. It should be noted that the platform(s) 114a-114n used herein may or may not be the same platform(s) 114a-114n as in step 306.

[0045] While Figure 3 illustrates an example of an antifragile software generation method 300, various modifications can be made to Figure 3. For example, while various steps in Figure 3 are shown as a series of steps, they may overlap, occur in parallel, occur in a different order, or occur any number of times. As a specific example, steps 308-316 may be repeated any number of times to iteratively modify the operation of the WebAssembly compiler / translator 102. Ideally, over time, the WebAssembly compiler / translator 102 will produce increasingly better output code 112a-112m.

[0046] In some embodiments, various functions described in this patent document are implemented or supported by a computer program formed from computer-readable program code and embodied in a computer-readable medium. The phrase "computer-readable program code" includes any type of computer code, including input code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random-access memory (RAM), hard disk drive (HDD), compact disc (CD), digital video disc (DVD), or any other type of memory. "Non-transitory" computer-readable media excludes wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media include media on which data can be permanently stored and media on which data can be stored and later overwritten, such as rewritable optical disks or erasable storage devices.

[0047] It may be advantageous to provide definitions of certain words and phrases used throughout this patent document. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof, adapted for implementation in suitable computer code (including input code, object code, or executable code). The term "communicate" and its derivatives encompass both direct and indirect communication. The terms "including" and "comprising," and their derivatives, mean inclusive without limitation. The term "or" is inclusive and / or. The word "related to" and its derivatives may mean including, contained within, interconnected with, containing, housed within, connected to or with, coupled to or with, communicable with, associated with, interleaved with, parallel to, proximate to, bound to or with, having, having properties of, relating to or with, etc. The phrase "at least one of," when used in conjunction with a list of items, means that different combinations of one or more of the listed items may be used, and may require only one item in the list. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A, B, and C.

[0048] Nothing in this application should be read as implying that any particular element, step, or function is a required or critical element required for inclusion within the scope of any claim. The scope of patented subject matter is defined solely by the scope of the allowed claims. Furthermore, no claim shall invoke 35 U.S.C. §112(f) with respect to any of the appended claims or claim elements unless the precise phrase "means for" or "step for" is expressly used in a particular claim, followed by a participial phrase identifying the function. Use of terms such as "mechanism," "module," "device," "unit," "component," "element," "member," "apparatus," "machine," "system," "processor," or "controller" in the claims is understood to and intended to refer to structures known to those skilled in the art, as further modified or enhanced by features of the claims themselves, and is not intended to invoke 35 U.S.C. §112(f).

[0049] While this disclosure has described particular embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of exemplary embodiments does not define or constrain the disclosure. Other changes, substitutions, and alterations are possible without departing from the spirit and scope of the disclosure, as defined by the following claims.

Claims

1. generating output code based on input code using a compiler or translator; providing the output code to one or more platforms for execution; receiving feedback related to the execution of the output code, the feedback identifying at least one of one or more defects during the execution of the output code and one or more performance characteristics of the execution of the output code; modifying the compiler or the translator based on the feedback; and generating additional output code using the modified compiler or the modified translator, wherein generating the additional output code includes using binary diversity to randomize an amount of stack space allocated to each of one or more functions associated with the additional output code; A method comprising:

2. Modifying the compiler or the translator may include modifying the compiler or the translator to: reducing or eliminating the one or more defects during execution of the additional output code; and improving the one or more performance characteristics of the execution of the additional output code relative to the execution of the output code; The method of claim 1 , comprising at least one of:

3. The method of claim 1 , wherein the feedback includes metrics related to memory stack allocation, control flow graph, and memory heap interaction during the execution of the output code.

4. receiving information identifying one or more cybersecurity vulnerabilities; modifying the compiler or the translator based on the information; further comprising 2. The method of claim 1, wherein modifying the compiler or the translator comprises modifying the compiler or the translator to partially or completely avoid generating the one or more vulnerabilities in the additional output code.

5. receiving information identifying one or more portions of the input code or additional input code to be translated using the compiler or the translator; The method of claim 1 , wherein the compiler or the translator is modified so that the compiler or the translator translates only the one or more portions of the input code or the additional input code.

6. Generating the additional output code using the binary diversity includes: randomizing the order of at least some functional code blocks associated with said additional output codes; randomizing the order of the data used by said additional output codes; randomizing heap memory allocations associated with the additional output code; and inserting instructions into the additional output code that do not change the results produced by the additional output code; The method of claim 1 , comprising at least one of:

7. The method of claim 1 , wherein the compiler or translator comprises a WebAssembly compiler or translator.

8. Modifying the compiler or the translator based on the feedback includes using a machine learning model and performing multiple types of changes to the compiler or the translator based on telemetry that identifies at least one of the one or more defects and the one or more performance characteristics. The method of claim 1.

9. 1. An apparatus including at least one processor, The at least one processor generating output code based on input code using a compiler or translator; providing the output code to one or more platforms for execution; receiving feedback related to the execution of the output code, the feedback identifying at least one of one or more defects in the execution of the output code and one or more performance characteristics of the execution of the output code; modifying the compiler or the translator based on the feedback; and generating additional output code using the modified compiler or the modified translator; configured for the at least one processor is configured to use binary diversity to randomize an amount of stack space allocated to each of one or more functions associated with the additional output code.

10. The at least one processor modifies the compiler or the translator to: reducing or eliminating the one or more defects during execution of the additional output code; and improving the one or more performance characteristics of the execution of the additional output code relative to the execution of the output code; 10. The apparatus of claim 9, configured for at least one of:

11. The apparatus of claim 9 , wherein the feedback includes metrics related to memory stack allocation, control flow graph, and memory heap interaction during the execution of the output code.

12. The at least one processor receiving information identifying one or more cybersecurity vulnerabilities; modifying the compiler or the translator based on the information to partially or completely avoid generating the one or more vulnerabilities in the additional output code; The apparatus of claim 9 , further configured for:

13. the at least one processor is further configured to receive information identifying one or more portions of the input code or additional input code to be translated using the compiler or the translator; The apparatus of claim 9 , wherein the at least one processor is configured to modify the compiler or the translator to translate only the one or more portions of the input code or the additional input code.

14. The at least one processor uses the binary diversity to: randomizing the order of at least some functional code blocks associated with said additional output codes; randomizing the order of data used by said additional output codes; randomizing heap memory allocations associated with the additional output code; and inserting instructions into the additional output code that do not change the results produced by the additional output code; 10. The apparatus of claim 9, configured for at least one of:

15. The apparatus of claim 9 , wherein the compiler or translator comprises a WebAssembly compiler or translator.

16. To modify the compiler or the translator based on the feedback, the processor is configured to use a machine learning model and to perform multiple types of changes to the compiler or the translator based on telemetry that identifies at least one of the one or more defects and the one or more performance characteristics.

10. The apparatus of claim 9.

17. When executed, the method causes at least one processor to: instructions that cause a compiler or translator to generate output code based on input code; instructions for providing the output code to one or more platforms for execution; instructions for receiving feedback associated with the execution of the output code, the feedback identifying at least one of one or more defects during the execution of the output code and one or more performance characteristics of the execution of the output code; instructions to modify the compiler or the translator based on the feedback; instructions for generating additional output code using the modified compiler or the modified translator; 12. A non-transitory computer-readable medium comprising: instructions that, when executed, cause the at least one processor to generate the additional output code, the instructions that, when executed, cause the at least one processor to randomize an amount of stack space allocated to each of one or more functions associated with the additional output code using binary diversity.

18. The instructions, which, when executed, cause the at least one processor to modify the compiler or the translator, when executed, cause the at least one processor to modify the compiler or the translator: instructions that, during execution of the additional output code, cause the one or more defects to be reduced or eliminated; instructions for improving the one or more performance characteristics of the execution of the additional output code relative to the execution of the output code; 20. The non-transitory computer-readable medium of claim 17, comprising at least one of:

19. The instructions, when executed, further cause the at least one processor to receive information identifying one or more cybersecurity vulnerabilities; 20. The non-transitory computer-readable medium of claim 17, wherein the instructions that, when executed, cause the at least one processor to modify the compiler or the translator comprise instructions that, when executed, cause the at least one processor to modify the compiler or the translator to partially or completely avoid generating the one or more vulnerabilities in the additional output code.

20. The instructions, when executed, further cause the at least one processor to receive information identifying one or more portions of the input code or additional input code to be translated using the compiler or the translator; 20. The non-transitory computer-readable medium of claim 17, wherein the instructions that, when executed, cause the at least one processor to modify the compiler or the translator comprise instructions that, when executed, cause the at least one processor to modify the compiler or the translator to translate only the one or more portions of the input code or the additional input code.

21. The instructions, which, when executed, cause the at least one processor to generate the additional output code, when executed, cause the at least one processor to use the binary diversity to: instructions for randomizing the order of at least some functional code blocks associated with said additional output code; instructions for randomizing the order of data used by said additional output code; instructions for randomizing heap memory allocations associated with the additional output code; instructions to insert into said further output code instructions that do not change the results produced by said further output code; 20. The non-transitory computer-readable medium of claim 17, comprising at least one of:

22. 20. The non-transitory computer-readable medium of claim 17, wherein the compiler or translator comprises a WebAssembly compiler or translator.

23. The instructions that, when executed, cause the at least one processor to modify the compiler or the translator based on the feedback include instructions that, when executed, cause the at least one processor to perform multiple types of changes to the compiler or the translator using a machine learning model and based on telemetry that identifies at least one of the one or more defects and the one or more performance characteristics.

20. The non-transitory computer-readable medium of claim 17.

Images