Hardware offload support for an operating system offload interface using operation code verification

A method may include receiving, by a privileged component executed by a processing device, bytecode of a packet processing component from an unprivileged component executed by the processing device, analyzing, by the privileged component, the bytecode of the packet processing component to identify whether the bytecode comprises a first command that returns a redirect, analyzing, by the privileged component, the bytecode of the packet processing component to identify whether the bytecode comprises a second command that returns a runtime computed value, and responsive to determining that the bytecode comprises the first command or the second command, setting a redirect flag maintained by the privileged component.

TECHNICAL FIELD

The disclosure is generally related to networking computing systems, and is more specifically related to hardware offload support for an operating system (OS) offload interface using operation code (opcode) verification.

BACKGROUND

In digital communications networks, packet processing refers to the techniques that are applied to a packet of data or information as it moves through the various network elements of a communications network. Within any network-enabled device (e.g., router, switch, firewall, network element or terminal such as a computer or smartphone), a packet processing subsystem manages the traversal of packets through a multi-layered network or protocol stack from lower, physical and network layers to the application layer.

Packet processing systems often apply packet filter rules (PFRs) (also known as Internet Protocol (IP) filter rules) to examine incoming packets. A packet filter implementing the PFRs examines the header of each packet based on a specific set of rules, and on that basis decides to allow the packet to pass through the filter (called an Accept/Pass Action) or prevent the packet from passing through (called a Drop Action). Other actions are also possible to be implemented by more advanced versions of packet filters. Packet filters have a significant impact on performance, both throughput and latency, since typically multiple PFRs are checked for every received packet on an interface before the packet is forwarded or terminated.

DETAILED DESCRIPTION

Implementations of the disclosure are directed to hardware offload support for an operating system (OS) offload interface using operation code (opcode) verification. In one implementation, an OS offload interface refers to packet processing components that process and filter network packets in a computing system. Packet processing refers to the variety of techniques that are applied to a packet of data or information as it moves through various network elements of a communications network. Within any network-enabled device (e.g., router, switch, firewall, network element or terminal such as a computer or smartphone), a packet processing subsystem manages the traversal of the packets through a multi-layered network or protocol stack from lower, physical and network layers to the application layer.

Packet processing components often apply packet filter rules (PFRs) (also known as Internet Protocol (IP) filter rules) to examine incoming packets. A packet filter implementing the PFRs examines the header of each packet based on a specific set of rules, and on that basis decides to allow the packet to pass through the filter (called an Accept/Pass Action) or prevent the packet from passing through (called a Drop Action). More advanced versions of packet filters may perform other actions (e.g., abort, redirect, transmit) as well. Packet filters have a significant impact on performance, both throughput and latency, since typically multiple PFRs are checked for every received packet on an interface before the packet is forwarded or terminated. Scaling up the number of rules and/or the rule complexity also significantly impacts performance.

One way to implement PFRs is by using a software-based library executing on one or more processor cores of a computing platform. The Berkeley Packet Filter (BPF) has become a standard mechanism for packet filtering in many operating systems (OSes). The BPF was originally used to efficiently select which packets are to be taken from a packet stream. The basic idea is that a set of filter rules is compiled into bytecode that is then applied to each inspected packet to decide whether the packet is passed or ignored. The BPF allowed for constructing high-level PFRs, such as “only pass packets from ‘example.com’ with the top destination port X” and having them compiled to run efficiently.

The BPF has been extended in the kernel of some OSes and moved out of network subsystem code. One example extension of the BPF is eXpress Data Path (XDP), which provides a programmable network data path in the OS kernel, providing bare metal packet processing at the lowest point in the software application stack. One change involved in the extension of BPF to the OS kernel is the addition of “maps”, which are key-value sets that allow for the keeping of state information between packet inspection events and the passing of state information back to the user. In the present disclosure, the extension of BPF into the OS kernel is referred to as an OS offload interface or, more generally, a packet processing component.

Some network devices offer BPF extension support in network input/output (I/O) devices, such as in Network Interface Cards (NICs). This support of BPF and BPF extensions (e.g., packet processing components) in hardware network devices is referred to herein as hardware offload support or hardware offload. Hardware offload support for a packet processing component enables more efficient and quicker network packet processing. For example, the packet processing component may be offloaded to a network I/O device, such as a Network Interface Card (NIC), which can execute the packet processing component and apply the filter rules without involving software execution at the processor.

In some systems, a packet processing component may provide the following return responses when a network packet is received: drop, abort, pass, redirect, and transmit. However, with hardware offload of a packet processing component, the redirect action may not be supported by the hardware offloader device (e.g., NIC card). This is because the redirect action involves a redirection of a packet to a different network device interface or another application. The network device providing hardware offload for the packet processing component may not have the capability to redirect a received packet to another network interface or application. This inability to properly handle redirect actions can cause portability issues for users of the packet processing component. For example, for virtual machines (VMs) migrating between hosts with and without redirect support, it should be known in advance whether the packet processing component uses redirect so that a determination can be made whether the VM can be successfully migrated. However, information regarding redirect support is typically not provided as metadata with packet processing components.

Aspects of the disclosure address the above and other deficiencies by providing a verifier of a privileged component of a computing system. The privileged component may refer to a kernel of an OS or a hypervisor that manages one or more VMs. The verifier may be an opcode verifier and may perform verification of bytecode of a packet processing component received from an unprivileged component (e.g., an application, a VM, etc.) of the computing system. Bytecode and opcode are referred to throughout this disclosure. Bytecode may refer to a representation of a program (as a sequence of bytes). Opcode may refer to a number that represents a single instruction. The processor in a computer reads values from memory and interprets these as instructions. Such a sequence of values is called “machine code”. Machine code consists of many individual instructions. An instruction may appear in the memory as a number, say 0x1F38520A in hexadecimal notation. Depending on how the processor is designed, the first eight bits may determine what the instruction is. For example, 0x1F may mean “add”. As such, 0x1F is the opcode for addition. Bytecode is similar to machine code. Its instructions are also represented by numbers, and the “opcode” identifies which instruction it is. The difference between byte code and machine code (opcode) is that bytecode is not designed to be executed by the processor directly, but rather by another program.

In one implementation, the verifier may include a redirect checker that detects a command to return a redirect action in the bytecode of the packet processing component. The redirect checker can pass over all opcodes in the packet processing component bytecode provided by the unprivileged component. If the redirect checker detects a command to return a redirect, it can set a redirect flag that indicates a redirect action is detected in the packet processing component.

In some implementations, a command to return a redirect may not be explicit in the packet processing component bytecode. For example, the opcode may return a value that is not known in advance, such as a value from a register, from a map (e.g., a data structure for storage of different data types, used to keep state between invocations of the packet processing component), or from memory. These values are discernable at runtime, but not directly discernable from the bytecode of the packet processing component. These values may be referred to herein as runtime-computed values that are generated during runtime of the application. In some implementations, a redirect action may be returned via such an unknown value detected in the bytecode. As such, in some implementations, the redirect checker also sets the redirect flag when the redirect checker detects that the opcode (within the bytecode) returns a values that is not known in advance (e.g., only known at runtime).

Once the verifier validates the packet processing component bytecode and the redirect checker completes its check, the privileged component may recognize that a hardware device, such as a NIC, provides hardware offload support for the packet processing component. The privileged component may then pass off the unprivileged component's request to load the packet processing component to the device driver for the device that provides the hardware offload support for the packet processing component. The device driver can check the redirect flag to determine whether a command to return a redirect is detected in the bytecode of the packet processing component. If the redirect flag is set, then the device driver may cause the packet processing component to be executed in a software implementation for each networking packet that is received. On the other hand, if the redirect flag is not set, then the device driver may cause the packet processing component to be loaded in the device to be executed in a hardware implementation for each networking packet that is received.

In some implementations, the techniques disclosed herein may be expanded beyond the packet processing context and applied to other use cases. For example, implementations of the disclosure may provide for operation code verification for unknown execution actions of any compiled instruction code. One example use case is detecting unsafe speculation due to indirect branch instructions in bytecode of an application. The verifier described herein can be extended to detect occurrence of such indirect branch instructions and set a flag indicating existence of the indirect branch. The flag can be used to notify the user and/or modify the instruction code to better enumerate potential unknown values in the bytecode to avoid the unsafe speculation caused by the indirect branch instruction.

The techniques disclosed herein may provide hardware offload support for an OS offload interface using opcode verification, where a privileged component executes a verifier to verify whether a redirect action is returned by bytecode of a packet processing component. In such an instance, the privileged component may avoid offloading the packet processing component to a hardware device that is not capable of supporting the redirect action, thereby increasing efficiency of a computer system by reducing power consumption and processor (e.g., central processing unit (CPU)) cycles that would be associated with a hardware offload that would be error-prone due to inability to support redirect actions.

FIG.1illustrates an example system architecture100in which implementations of the disclosure may operate. The system architecture100may include a computer system110, a source node120, and a destination node130coupled via a network140. In one example, the computer system110, the source node120, and the destination node130may be host systems in a cluster in a data center. In another example, the computer system110may be a host system and the source node120and the destination node130may be virtual machines, hypervisors, and/or devices (e.g., virtual and/or physical NICs) running on the computer system110or another computer system. The network140may be a public network (e.g., the Internet), a private network (e.g., a virtual local area network (vLAN), a local area network (LAN), or a wide area network (WAN)), or a combination thereof. The network140may include a wireless infrastructure, which may be provided by one or more wireless communications systems, such as a wireless fidelity (WiFi) hotspot connected with the network140and/or a wireless carrier system that can be implemented using various data processing equipment, communication towers, etc. Additionally or alternatively, the network140may include a wired infrastructure (e.g., Ethernet).

The computer system110may comprise one or more processing devices communicatively coupled to memory devices and devices150(e.g., I/O devices, CD-ROM drive, physical NICs, etc.). The computer system110may be a server, a mainframe, a workstation, a personal computer (PC), a laptop, a mobile phone, a palm-sized computing device, or any suitable computing device. The computer system110runs a host operating system (OS)160, which is an application that manages the hardware resources of the computer system110and that provides functions such as interprocess communication, scheduling, memory management, and so forth.

The host OS160may include and execute a privileged component170. In one implementation, the privileged component170may be kernel. In some implementations, a kernel may also be referred to as a supervisor or supervisor component. The kernel is a computer program that is the core of the OS160. The critical code of the kernel is usually loaded into a separate area of memory, which is protected from access by application programs or other, less critical parts of the OS160. The kernel performs its tasks, such as running processes, managing hardware devices such as the hard disk, and handling interrupts, in this protected kernel space. In contrast, unprivileged components130, such as application programs including browsers, word processors, audio or video players, or virtual machines (VMs), use a separate area of memory referred to as user space. This separation prevents user data and kernel data from interfering with each other and causing instability and slowness, as well as preventing malfunctioning unprivileged components130from crashing the entire OS160.

In one implementation, the privileged component170is a hypervisor. A hypervisor may refer to an application that provides a virtual operating platform for a set of virtual machines (VMs). Each VM of the set of VMs may be an unprivileged component130of computer system100. The hypervisor abstracts the physical layer of the computer system110, including the processors, memory, I/O devices, network devices, and presents this abstraction to the VMs. The hypervisor may create, run, manage, and monitor various aspects of virtual machines operation, including the processing, and storage, memory, and network interfaces. The VMs may be implemented in computer instructions that emulate physical machines and may execute applications as though they were an actual physical machine. For example, a VM executes a guest operating system that may utilize the underlying virtual devices, including virtual processors, virtual memory, virtual I/O devices, and virtual NICs.

In one implementation, the unprivileged component130(e.g., application, VM, etc.) may generate a packet processing component using one or more rules for processing network packets. In one example, the packet processing component may be implemented using instructions (e.g., Berkeley Packet Filter bytecode) that can be, for example, specified by a user and provided to the unprivileged component130.

As shown inFIG.1, the packet processing component may be represented as packet processing component bytecode135. Bytecode may refer to program code that has been compiled from source code into low-level code designed for a software interpreter. The bytecode may be executed by a virtual machine (such as a JVM) or further compiled into machine code, which is recognized by the processor. In one implementation, the packet processing component may be an XDP application. XDP provides a high performance, programmable network data path in the privileged component170, such as a kernel or a hypervisor. XDP provides bare metal packet processing at the lowest point in an application stack. The one or more rules for processing network packets may be compiled into packet processing component bytecode135at the unprivileged component130. For example, the packet processing component created by the unprivileged component130is compiled into packet processing component bytecode135using a packet processing library function. The library function may make a packet processing system call to the privileged component160.

Upon receiving the system call, the privileged component170may validate the packet processing component bytecode135. Validating the packet processing component bytecode135via the privileged component170ensures that the packet processing component can be run properly at the privileged component170. Once the bytecode135is validated, machine dependent assembly language code is inserted into the privileged component170as packet processing component174(e.g., in memory associated with the privileged component170) or is loaded in a hardware device150in a hardware offload implementation of the packet processing component155.

In one implementation, validating the packet processing component bytecode135at the privileged component170may include verifying the semantics of the system call and compiling the bytecode135into the machine dependent assembly language code. Specifically, verifying the packet processing component bytecode135may include verifying that the packet processing component can be granted a high privilege level of operation by not executing illegal instructions (e.g., changing arbitrary memory outside the packet buffer, executing back branches, running certain loops, sending data outside of packets, etc.).

In one implementation, a verifier172of the privileged component170may perform the verification of the packet processing component bytecode135received from the unprivileged component130. The verifier172may be operation code (opcode) verifier. In one implementation, the verifier172may include a redirect checker173. As noted above, the packet processing component may be offloaded to hardware (e.g., device150) to enable more efficient and quicker network packet processing. For example, the packet processing component may be offloaded to a NIC card, which can execute the packet processing component and apply the filter rules without involving software execution at the processor.

As discussed above, a packet processing component may generally provide one or more of the following return responses when a network packet is received: drop, abort, pass, redirect, and transmit. However, with hardware offload of a packet processing program, the redirect return action may not be supported by the hardware offloader (e.g., the NIC card). This can cause portability issues for users of the packet processing component. For example, for VMs migrating between hosts with and without redirect support, it should be known in advance whether the packet processing component uses redirect so that the user can know whether the VM can be successfully migrated. However, applications generally do not supply this information as metadata with packet processing components.

Implementations of the disclosure provide the redirect checker173to detect a command to return a redirect action in the packet processing component bytecode135. The redirect checker173can pass over all opcodes in the packet processing component bytecode135provided by the unprivileged component130. If the redirect checker173detects a command to return a redirect, it can set a redirect flag178that indicates a redirect action is detected in the packet processing component bytecode135. In one implementations, the redirect flag178may be maintained in memory of the privileged component170(e.g., kernel memory, hypervisor memory, etc.). For example, the redirect flag178may be included with system flags maintained by the privileged component170.

In some implementations, a command to return a redirect may not be explicit in the packet processing component bytecode135. For example, an opcode (of the bytecode135) may return a value that is not known in advance (e.g., runtime-computed value generating during runtime of the application), such as a value from a register, from a map (e.g., a data structure for storage of different data types, used to keep state between invocations of the packet processing component), or from memory. These values are discernable at runtime, but not discernable from the bytecode135of the packet processing component. In some implementations, a redirect action may be returned via an unknown value detected in the bytecode135at runtime. As such, in some implementation, the redirect checker173also sets the redirect flag178when the redirect checker173detects that the bytecode135returns a values that is not known in advance (e.g., known at runtime).

Once the verifier172validates the packet processing component bytecode135and the redirect checker173completes its check, the privileged component170may determine that a hardware device150, such as a network I/O device (e.g., a NIC), provides hardware offload support for the packet processing component. In one implementation, the privileged component170may reference configuration data, such as a setting or a flag provided by the device driver176, that indicates hardware offload for packet processing is supported by the device150. The privileged component170may then pass off the unprivileged component's130request to load the packet processing component to the device driver176corresponding to the device150that provides the hardware offload support for the packet processing component. The device driver176can check the redirect flag178to determine whether a command to return a redirect is detected in the bytecode135of the packet processing component. If the redirect flag178is set, then the device driver176may cause the packet processing component to be executed in a software implementation174for each networking packet that is received. On the other hand, if the redirect flag178is not set, then the device driver176may cause the packet processing component to be loaded in the device150to be executed in a hardware implementation155for each networking packet that is received.

In a software implementation of the packet processing component174, the privileged component170compiles the packet processing component into machine dependent assembly language code using, for example, a native compiler of the privileged component170. The machine dependent assembly language code is inserted into a kernel “hook” in kernel code and is executed along with the privileged component170. When incoming packets (e.g., networking packets) arrive at a network I/O device150, the network I/O device150hardware passes each packet to the packet processing component174for processing in software.

In a hardware offload implementation of the packet processing component155, the device driver176compiles the packet processing component into machine dependent assembly language code (e.g., native instructions for the device150) using a compiler (e.g., a compiler, such as a last stage compiler, of the device driver176). The machine dependent assembly language code is loaded in the device150. In one implementation, the packet processing component155is implemented as settings and logic within the device (e.g., NIC)150. When incoming packets (e.g., networking packets) arrive at the device150, the device150processes each packet using hardware implementation of the packet processing component155.

In some implementations, the privileged component170may provide a notification to the user of the unprivileged component130when the redirect flag178is set and hardware offload is not implemented. For example, the notification may include a suggestion that users rewrite the packet processing component to enumerate all possible values for a potential return value. For example, the notification may suggest that the user rewrite instruction code according to the below example:

In response to the feedback to provide explicit enumeration, packet processing component may be generated that includes any commands to return redirects explicitly in the instruction code. As a result, the redirect flag178may be more accurately set for these packet processing components. In some implementations, compilers and/or code generators may also be modified to emit compiled code that enumerates known values to reduce the unnecessary setting of the redirect flag178.

In one example implementation, if a packet is sent from a source node120and destined for a destination node130via an unprivileged component130(e.g., a router application, a VM, etc.), the packet processing component (either hardware implementation155or software implementation174) may process the received packet in view of one or more rules. For example, a first rule of the rules may cause the packet processing component155,174to process (e.g., modifying encapsulation headers, adding encapsulation headers, removing encapsulation headers, encrypting data in the packet, decrypting data in the packet, etc.) the packet for transmission to the destination node130, without providing the packet to the unprivileged component130for routing. In instances where the encapsulation headers are modified, a destination address for the packet may be changed.

Implementations of the disclosure may also be expanded into other applications beyond the packet processing component context discussed above. For example, implementations of the disclosure may provide for operation code verification for unknown execution actions of any compiled instruction code. In the context of indirect branch instructions, these type of instructions are often not safely speculated in a computing system The verifier172discussed above may be adapted to set a flag responsive to loaded bytecode including an indirect jump (or indirect branch) instruction. If the flag is set, then execution of the instruction code of the application may be denied and/or a warning may be produced instructing the user to rewrite the instruction code to enumerate the unknown values. For example, the original code:

FIG.2depicts a flow diagram of an example method200for hardware offload support for an OS offload interface using opcode verification, in accordance with one or more aspects of the present disclosure. Method200and each of its individual functions, routines, subroutines, or operations may be performed by one or more processing devices of the computer device executing the method. In certain implementations, method200may be performed by a single processing thread. Alternatively, method200may be performed by two or more processing threads, each thread executing one or more individual functions, routines, subroutines, or operations of the method. In an illustrative example, the processing threads implementing method200may be synchronized (e.g., using semaphores, critical sections, and/or other thread synchronization mechanisms). Alternatively, the processes implementing method200may be executed asynchronously with respect to each other.

Method200may begin at block201. At block201, a processing device may receive bytecode of a packet processing component from an unprivileged component. In one implementation, the unprivileged component may include an application or a VM. The packet processing component bytecode may be received at a privileged component on the same computing system as the unprivileged component. The privileged component may include a kernel of an OS or a hypervisor managing one or more VMs. The packet processing component may be represented as instructions implementing one or more rules for processing network packets. The packet processing component may also be referred to as an OS offload interface. One implementation of the packet processing component is an XDP application.

At block202, the processing device may analyze the bytecode of the packet processing component to identify if the bytecode includes a first command that returns a redirect. At block203, the processing device may analyze bytecode of the packet processing component to identify if the bytecode includes a second command that returns a runtime-computed value that is generated during runtime.

At block204, the processing device may set a redirect flag if the bytecode either includes either the first command and/or the second command. In one implementation, in response to the redirect flag being set, hardware offload of the packet processing component may be denied and the packet processing component implemented in software instead. In some implementations, in response to the redirect flag being set, a notification may be provided to a user associated with the packet processing component, where the notification provides a suggestion to rewrite the code of the packet processing component to enumerate unknown returned values in the packet processing component. In some implementations, based on the notification, a compiler or a code generator may be modified to enumerate unknown values in the bytecode of the packet processing component.

FIG.3depicts a block diagram of an example computer system300, in accordance with one or more aspects of the present disclosure. Computer system300may be the same or similar to the computer system110and may include one or more processing devices302and one or more memory devices350. In the example shown, the processing device302of the computer system300may include an unprivileged component305and a privileged component310. Unprivileged component305may be same as unprivileged component130described with respect toFIG.1. Privileged component310may be same as privileged component170described with respect toFIG.1. The unprivileged component305may include a packet processing component307. The privileged component310may include packet processing component receiving module320, bytecode analyzing module330, and flag setting module340. The privileged component310may execute each of the packet processing component receiving module320, bytecode analyzing module330, and flag setting module340.

The packet receiving module320may receive bytecode325of a packet processing component307from an unprivileged component305executed by the processing device302. The bytecode analyzing module330may analyze the bytecode325of the packet processing component to identify whether the bytecode325comprises a first command332that returns a redirect, The bytecode analyzing module330may also analyze the bytecode325of the packet processing component to identify whether the bytecode325comprises a second command334to that returns a value that is not known in advance of runtime of the packet processing component307.

The flag setting module340may set, in response to determining that the bytecode325comprises the first command332or the second command334, a redirect flag360maintained by the privileged component310in memory350of the system300.

FIG.4depicts a flow diagram of an example method400for a system supporting hardware offload support for an OS offload interface using opcode verification, in accordance with one or more aspects of the disclosure. Method400includes operations performed by the computer system110. Also, method400may be performed in the same or a similar manner as described above in regards to method200. Method400may be performed by processing devices of the computer system110executing the unprivileged component130and privileged component170.

Method400may begin at block401. At block401, the processing device may call, via an unprivileged component (e.g., application, VM, etc.), a packet processing component library in user space corresponding to the unprivileged component. The unprivileged component may comprise an application or a VM. In one implementation, the call to the packet processing library is to compile the packet processing component into bytecode. At block402, the processing device makes, using the packet processing component library, a packet processing component system call to a privileged component (e.g., supervisor, kernel, hypervisor, etc.) to load the packet processing component.

At bock403, the processing device, in response to the system call, analyzes the bytecode of the packet processing component at the privileged component. The privileged component may include a kernel of an OS executed by the processing device or a hypervisor executed by the processing device. The analysis of the bytecode by the privileged component is to determine whether to set a redirect flag for hardware offload of the packet processing component in view of occurrence of redirects or unknown value returns in the bytecode.

At block404, the processing device, via the privileged component, recognizes that hardware corresponding to the device driver provides hardware offload support for the packet processing component. In one implementation, the privileged component may determine that the device driver provides hardware offload support by referring to configuration data corresponding to the device driver, where the configuration data may include an indicator of hardware offload support. At block405, the processing device may, via the device driver, check the redirect flag to determine whether the hardware offload is allowed for the packet processing component. In one implementation, if the redirect flag is set, the hardware offload is denied for the packet processing component and the packet processing component is provided via a software implementation.

In one implementation, at block406, if the redirect flag is not set, the device driver compiles the bytecode into machine dependent binary code (e.g., an assigned pattern of binary digits to represent characters, instructions, etc.). At block407, the processing device may, via the device driver, program the machine dependent binary code of the packet processing component into a hardware device (e.g., a NIC) corresponding to the device driver. At block408, the processing device may cause the binary code of the packet processing component to execute in the hardware device in order to process packets for the unprivileged component.

FIG.5depicts a flow diagram of an example method500for using opcode verification to flag commands that return unknown values in bytecode, in accordance with one or more aspects of the disclosure. Method500includes operations performed by the computer system110. Also, method500may be performed in the same or a similar manner as described above in regards to methods200and/or400. Method500may be performed by processing devices of the computer system110executing the unprivileged component130and the privileged component170.

Method500may begin at block501. At block501, the processing device may receive bytecode corresponding to an application to be loaded by an unprivileged component. The unprivileged component may be an application or a VM. At block502, the processing device may analyze the bytecode at a privileged component. The privileged component may be a kernel of an OS or a hypervisor executing one or more VMs. The privileged component may analyze the bytecode to determine whether the bytecode includes a command that returns a runtime-computed value that is generated during runtime of the application. In one implementation, the command may be an indirect branch command (e.g., indirect jump instruction).

At block503, the processing device may, in response to identifying that the bytecode includes the command, set a flag indicating that the bytecode of the application includes the command that returns the runtime-computed value that is generated during runtime of the application. At block504, the processing device may, in response to the flag being set, provide a notification that the bytecode of the application comprises the command. In one implementation, the notification may inform a user that the application cannot be safely speculated and/or a suggestion on how to rewrite the instruction code of the application. In one implementation, the suggestion may include rewriting the code to enumerate runtime-computed values in order to avoid unsafe speculation in the bytecode.

FIG.6depicts a block diagram of a computer system operating in accordance with one or more aspects of the present disclosure. In various illustrative examples, computer system600may correspond to a computing device110within system architecture100ofFIG.1. In one implementation, the computer system600may be the computer system110ofFIG.1. The computer system600may be included within a data center that supports virtualization. Virtualization within a data center results in a physical system being virtualized using virtual machines to consolidate the data center infrastructure and increase operational efficiencies. A virtual machine (VM) may be a program-based emulation of computer hardware. For example, the VM may operate based on computer architecture and functions of computer hardware resources associated with hard disks or other such memory. The VM may emulate a physical computing environment, but requests for a hard disk or memory may be managed by a virtualization layer of a host system to translate these requests to the underlying physical computing hardware resources. This type of virtualization results in multiple VMs sharing physical resources.

In a further aspect, the computer system600may include a processing device602, a volatile memory604(e.g., random access memory (RAM)), a non-volatile memory606(e.g., read-only memory (ROM) or electrically-erasable programmable ROM (EEPROM)), and a data storage device616, which may communicate with each other via a bus608.

Computer system600may further include a network interface device622. Computer system600also may include a video display unit610(e.g., an LCD), an alphanumeric input device612(e.g., a keyboard), a cursor control device614(e.g., a mouse), and a signal generation device620.

Data storage device616may include a non-transitory computer-readable storage medium624on which may store instructions626encoding any one or more of the methods or functions described herein, including instructions implementing method200, method400, and method500for verifier650(which may be the same as verifier172ofFIG.1) and the modules illustrated inFIGS.1and3.

Instructions626may also reside, completely or partially, within volatile memory604and/or within processing device602during execution thereof by computer system600, hence, volatile memory604and processing device602may also constitute machine-readable storage media.