Patent Publication Number: US-11397602-B2

Title: Processor control register configuration support

Description:
BACKGROUND 
     Virtualization may be used to provide some physical components as logical objects in order to allow running various software modules, for example, multiple operating systems, concurrently and in isolation from other software modules, on one or more interconnected physical computer systems. Virtualization may allow, for example, for consolidating multiple physical servers into one physical server running multiple guest virtual machines in order to improve the hardware utilization rate. 
     Virtualization may be achieved by running a software layer, often referred to as a hypervisor, above the hardware and below the guest virtual machines. A hypervisor may run directly on the server hardware without an operating system beneath it or as an application running on a traditional operating system. A hypervisor may virtualize the physical layer and provide interfaces between the underlying hardware and guest virtual machines. Processor virtualization may be implemented by the hypervisor scheduling time slots on one or more physical processors for execution of a guest virtual machine, rather than a guest virtual machine executing on a dedicated physical processor. 
     SUMMARY 
     The present disclosure provides new and innovative systems and methods providing processor configuration support for booting a new operating system from a currently-executing operating system. In an example, a system includes a memory, a processor in communication with the memory, a control register in communication with the processor, and a hypervisor. The hypervisor is configured to determine a fault resulting from a guest attempting to execute first code from a memory page designated as non-executable. The first code is configured to cause a new operating system to boot from a currently-executing operating system. In the example, the hypervisor changes a configuration of the control register from a locked configuration to an unlocked configuration based at least in part on the fault. In the example, the hypervisor is further configured to receive a hypercall from the guest after execution of the first code. The hypercall indicates that the control register has been configured by the guest after booting the new operating system. In the example, the hypervisor may change the configuration of the control register from the unlocked configuration to the locked configuration. Further, in the example, the hypervisor may change the memory page from executable to non-executable. 
     In an example, a method includes determining, by a hypervisor, a fault resulting from a guest attempting to execute first code from a memory page designated as non-executable. The first code is configured to cause a new operating system to boot from a currently-executing operating system. The method also includes changing, by the hypervisor, a configuration of a control register associated with a processor from a locked configuration to an unlocked configuration based at least in part on the fault. The method may include changing, by the hypervisor, the memory page from non-executable to executable. The method may also include receiving, by the hypervisor from the guest after execution of the first code, a hypercall indicating that the control register has been configured by the guest after booting the new operating system. The method may include changing, by the hypervisor, the configuration of the control register from the unlocked configuration to the locked configuration, and changing the memory page from executable to non-executable. 
     In an example, a non-transitory machine readable medium stores a program, which when executed by a processor causes a hypervisor to determine a fault resulting from a guest attempting to execute first code from a memory page designated as non-executable. The first code is configured to cause a new operating system to boot from a currently-executing operating system. The program also causes the hypervisor to change a configuration of a control register associated with the processor from a locked configuration to an unlocked configuration based at least in part on the fault. The program may also causes the hypervisor to change the memory page from non-executable to executable. The program may also cause the hypervisor to receive a hypercall from the guest after execution of the first code. The hypercall indicates that the control register has been configured by the guest after booting the new operating system. The program may cause the hypervisor to change the configuration of the control register from the unlocked configuration to the locked configuration, and change the memory page from executable to non-executable. 
     Additional features and advantages of the disclosed method and system are described in, and will be apparent from, the following Detailed Description and the Figures. The features and advantages described herein are not all-inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the figures and description. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and not to limit the scope of the inventive subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         FIG. 1  illustrates a block diagram of an example computer system according to an example embodiment of the present disclosure. 
         FIG. 2  illustrates example communications between a hypervisor and guest according to an example embodiment of the present disclosure. 
         FIG. 3  illustrates a flowchart of an example process for processor control register configuration support according to an example embodiment of the present disclosure. 
         FIGS. 4A and 4B  illustrate a flow diagram of an example process for processor control register configuration support according to an example embodiment of the present disclosure. 
         FIG. 5  illustrates a block diagram of an example processor control register configuration support system according to an example embodiment of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS 
     Techniques are disclosed for providing processor control register (e.g., central processing unit (“CPU”) control register) configuration support. Although CPU control registers are generally referred to herein, the various techniques described may be applicable to other control registers potentially associated with other non-CPU types of processors (e.g., a control register associated with a graphical processing unit, etc.). However, for brevity and clarity the various examples described herein generally refer to CPU control registers. In some CPU implementations CPU protections are implemented to prevent malicious attacks and/or unauthorized attempts to gain root level access to a computing system. For example, supervisor mode access prevention (“SMAP”) is a feature of various CPU implementations that allows applications with supervisor mode access privileges to optionally set user-space memory mappings so that access to those memory mappings from supervisor mode causes a fault. 
     In the absence of SMAP, supervisor-privileged code usually has read and write access to user-space memory mappings (or has the ability to obtain access). This has led to the development of several security exploits, including privilege escalation exploits, which operate by causing the kernel to access user-space memory. Operating systems can block these exploits by using SMAP to force unintended user-space memory accesses to trigger page faults. Additionally, SMAP can expose flawed kernel code which does not follow the intended procedures for accessing user-space memory. 
     Another CPU protection that has been implemented is supervisor mode execution prevention (“SMEP”), SMEP is used to prevent supervisor mode from unintentionally executing user space code by causing a fault when an attempt is made to execute user space code from supervisor mode (e.g., by an operating system kernel). Bits in CPU control register 4 (“CR 4 ”) may be used to enable/disable SMAP and SMEP. For example, in the x86-64 instruction set architecture, bits  20  and  21  in CR 4  enable SMEP and SMAP, respectively, when set. 
     Another example CPU protection that has been implemented is write protect (“WP”). Write protect, when enabled, prevents the CPU from writing to read-only pages when the privilege level is 0. In the x86-64 instruction set architecture, bit  16  in CR 0  enables wtite protect, when set. 
     Malicious attacks have recently sought to disable such CPU protections in furtherance of the attack. Disabling SMAP and SMEP allows an attacker to access user space memory and execute user space code, opening up the attack to increased flexibility. Disabling write protect allows an attacker to write to read-only memory like the operating system code and/or kernel code itself. To prevent malicious attackers from disabling such CPU protections, the operating system (e.g., the kernel) may add one or more sensitive bits to the control registers to prevent attackers from disabling the protections described above. Such sensitive bits are access control flags that prevent instructions that lack the requisite privilege level from changing bit values in the control register, directory, and/or file with which the sensitive bit is associated. Associating a sensitive bit with a control register is sometimes referred to as “pinning” the bit to the control register. A CPU control register with a pinned sensitive bit is sometimes referred to as having a “sticky” CPU configuration, as the sensitive bit prevents guests (and/or other users without the requisite privilege level) from changing the CPU configuration without a CPU reset. 
     Various operating systems are able to boot a new operating system (and/or a new kernel) from a currently-executing operating system (and/or a currently-executing kernel). For example, kexec is a mechanism or component of the Linux kernel that allows booting of a new kernel from the currently existing kernel. kexec skips the bootloader stage and hardware initialization phase performed by the system firmware (e.g., BIOS or UEFI), and directly loads the new kernel into main memory and begins execution. Booting a new operating system from a currently-executing operating system using kexec (or a similar mechanism) avoids the long wait times associated with a CPU reset (e.g., a full reboot) and may enable systems to meet high-availability requirements by minimizing downtime. Although kexec is a specific mechanism of the Linux kernel, the term “kexec,” as used herein, may also refer more generally to any mechanism whereby a new operating system is booted directly from a currently-executing operating system while skipping one or more of the bootloader stage and hardware initialization phases. 
     An operating system may comprise a supervisor, a bootloader, a firmware component, a user space component, one or more application components, etc. As described above, typically, in order to change the values/configuration of CPU control registers, a CPU reset is needed. Since operations such as kexec, that boot new operating systems from currently-executing operating systems, do not include CPU resets, such operations may have no opportunity to change the CPU configuration when booting the new operating system from the currently-executing operating system. Accordingly, various embodiments described herein provide CPU control register configuration support for kexec. 
     In various example embodiments described herein, a guest may allocate a startup page in memory that includes a branch to a kexec routine (or other code effective to cause a new operating system to boot from a currently-executing operating system). The startup page may be passed from the guest to the hypervisor and may be designated non-executable by the hypervisor. The kexec routine may be modified to execute the code at the offset of the branch to the kexec routine on the startup page instead of jumping directly to the kexec initialization routine. 
     Thereafter, when a guest attempts to execute the kexec routine, a startup page fault occurs due to the attempt to execute code on a memory page designated as non-executable. Upon detection by the hypervisor of the startup page fault, the hypervisor may change a configuration of one or more control registers (e.g., CR 4 , CR 0 , etc.) from a locked configuration to an unlocked configuration to allow the guest to change one or more of the bits in the unlocked control registers. Additionally, the hypervisor may change the designation of the startup page that includes the branch to the kexec routine from non-executable to executable and may re-enter the guest. The guest may thereafter execute the kexec routine and may set up the unlocked control registers. After configuring the control registers, the guest may make a hypercall causing the hypervisor to change the control registers from the unlocked to the locked configuration (e.g., by pinning one or more sensitive bits to the relevant control registers). After locking the control registers the hypervisor may change the designation of the startup page to non-executable. Accordingly, in order to change the control register configuration (e.g., CR 0 , CR 4 , etc.) code from the startup page (e.g., a reset page) must be executed, forcing the kexec initialization which, in turn, causes a new operating system to boot from the currently-executing operating system. Accordingly, kexec and/or other mechanisms by which a new operating system is booted from a currently-executing operating system may be enabled without loss of security. 
       FIG. 1  depicts a high-level component diagram of an example computer system  100  in accordance with one or more aspects of the present disclosure. The computing system  100  may include an operating system (e.g., host OS  186 ), one or more virtual machines (VM  170 A-B) and nodes (e.g., nodes  110 A-C). 
     Virtual machines  170 A-B may include a guest OS, guest memory, a virtual CPU (VCPU), virtual memory devices (VMD), and virtual input/output devices (VI/ 0 ). 
     For example, VM  170 A may include guest OS  196 A, guest memory or virtual machine memory  195 A, a virtual CPU  190 A, a virtual memory devices  192 A, and virtual input/output device  194 A. Virtual machine memory  195 A may include one or more memory pages. Similarly, VM  170 B may include guest OS  196 B, virtual machine memory  195 B, a virtual CPU  190 B, a virtual memory devices  192 B, and virtual input/output device  194 B. Virtual machine memory  195 B may include one or more memory pages. 
     The computing system  100  may also include a hypervisor  180  and host memory  184 . The hypervisor  180  may manage host memory  184  for the host operating system  186  as well as memory allocated to the virtual machines  170 A-B and guest operating systems  196 A-B such as guest memory or virtual machine memory  195 A-B provided to guest OS  196 A-B. Host memory  184  and virtual machine memory  195 A-B may be divided into a plurality of memory pages that are managed by the hypervisor  180 . Virtual machine memory  195 A-B allocated to the guest OS  196 A-B may be mapped from host memory  184  such that when a guest application  198 A-D uses or accesses a memory page of virtual machine memory  195 A-B, the guest application  198 A-D is actually using or accessing host memory  184 . 
     The hypervisor  180  may be configured to allocate a memory page (e.g., guest-writable memory page) for each page table of a set of page tables used by applications (e.g., applications  198 A-D). In an example, the hypervisor  180  may be configured to map each respective memory page (e.g., guest-writable memory page) at a guest physical address in each page table. 
     In an example, a VM  170 A may execute a guest operating system  196 A and run applications  198 A-B which may utilize the underlying VCPU  190 A, VIVID  192 A, and VI/O device  194 A. One or more applications  198 A-B may be running on a VM  170 A under the respective guest operating system  196 A. A virtual machine (e.g., VM  170 A-B, as illustrated in  FIG. 1 ) may run on any type of dependent, independent, compatible, and/or incompatible applications on the underlying hardware and OS. In an example, applications (e.g., App  198 A-B) run on a VM  170 A may be dependent on the underlying hardware and/or OS  186 . In another example embodiment, applications  198 A-B run on a VM  170 A may be independent of the underlying hardware and/or OS  186 . For example, applications  198 A-B run on a first VM  170 A may be dependent on the underlying hardware and/or host OS  186  while applications (e.g., application  198 C-D) run on a second virtual machine (e.g., VM  170 B) are independent of the underlying hardware and/or OS  186 A. Additionally, applications  198 A-B run on a VM  170 A may be compatible with the underlying hardware and/or OS  186 . In an example embodiment, applications  198 A-B run on a VM  170 A may be incompatible with the underlying hardware and/or OS  186 . For example, applications  198 A-B run on one VM  170 A may be compatible with the underlying hardware and/or OS  186 A while applications  198 C-D run on another VM  170 B are incompatible with the underlying hardware and/or OS  186 . In an example embodiment, a device may be implemented as a virtual machine (e.g., VM  170 A-B). 
     The computer system  100  may include one or more nodes  110 A-C. Each node  110 A-C may in turn include one or more physical processors (e.g., CPU  120 A-D) communicatively coupled to memory devices (e.g., MD  130 A-D) and input/output devices (e.g., I/O  140 A-C). Each CPU  120 A-D may include and/or be in communication with one or more control registers (e.g., CR  150 A-D). The control registers may include CR 0  and/or CR 4 , described above, among other possible control registers. Each CR  150 A-D may have a configuration that may be either locked or unlocked, as controlled by a sensitive bit (e.g., an access flag) associated with the respective control registers CR  150 A-D. As described herein, hypervisor  180  may be effective to change the configuration from CR  150 A-D from locked to unlocked configurations and vice versa. In at least some examples, hypervisor  180  may change the configurations from locked to unlocked in response to the detection of a startup page fault caused by a guest (e.g., VM  170 A-B) attempting to execute code on a startup page designated as non-executable. Additionally, as described in further detail below, after configuring one or more of CR  150 A-D, VM  170 A-B may make a hypercall to hypervisor  180  instructing hypervisor  180  to change the configuration of one or more of CR  150 A-D from an unlocked configuration to a locked configuration. 
     Each node  110 A-C may be a computer, such as a physical machine and may include a device, such as hardware device. In an example, a hardware device may include a network device (e.g., a network adapter or any other component that connects a computer to a computer network), a peripheral component interconnect (PCI) device, storage devices, disk drives, sound or video adaptors, photo/video cameras, printer devices, keyboards, displays, etc. Virtual machines  170 A-B may be provisioned on the same host or node (e.g., node  110 A) or different nodes. For example, VM  170 A and VM  170 B may both be provisioned on node  110 A. Alternatively, VM  170 A may be provided on node  110 A while VM  170 B is provisioned on node  110 B. 
     As used herein, physical processor or processor (e.g., CPU  120 A-D) refers to a device capable of executing instructions encoding arithmetic, logical, and/or I/O operations. In one illustrative example, a processor may follow a Von Neumann architectural model and may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. In a further aspect, a processor may be a single core processor which is typically capable of executing one instruction at a time (or process a single pipeline of instructions), or a multi-core processor which may simultaneously execute multiple instructions. In another aspect, a processor may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., in which individual microprocessor dies are included in a single integrated circuit package and hence share a single socket). A processor may also be referred to as a central processing unit (CPU). 
     As discussed herein, a memory device  130 A-D refers to a volatile or non-volatile memory device, such as random access memory (RAM), read only memory (ROM), electrically erasable read only memory (EEPROM), or any other device capable of storing data. As discussed herein, I/O device  140 A-C refers to a device capable of providing an interface between one or more processor pins and an external device capable of inputting and/or outputting binary data. 
     Processors (e.g., CPUs  120 A-D) may be interconnected using a variety of techniques, ranging from a point-to-point processor interconnect, to a system area network, such as an Ethernet-based network. Local connections within each node, including the connections between a processor (e.g., CPU  120 A-D) and a memory device  130 A-D may be provided by one or more local buses of suitable architecture, for example, peripheral component interconnect (PCI). 
       FIG. 2  illustrates example communications of a system  200 , for example, between a hypervisor and guest according to an example embodiment of the present disclosure.  FIG. 2  is conceptually divided into guest view  230 , representing actions taken by guest virtual machines, and host view  232 , representing actions taken by hypervisor  180  of the host. VM  170 A (e.g., a guest VM) may allocate a memory page as a startup page  202 A including a branch to a kexec initialization routine (e.g., “BR kexec.init” in  FIG. 2 ). Hypervisor  180  may designate startup page  202 A as non-executable. Additionally, the kexec routine may be modified to jump to the correct offset on startup page  202 A, instead of directly to the kexec initialization routine. Accordingly, when guest VM  170 A attempts to execute the kexec routine, a fault  204  occurs due to the startup page  202 A being designated non-executable. 
     Upon determining fault  204 , hypervisor  180  may determine that the fault corresponds to an attempt to execute code on the non-executable startup page  202 A (block  206 ). In response to the determination that the fault  204  occurred on the startup page  202 A, hypervisor  180  may change the configuration of one or more control registers (e.g., CR  150 A, etc.) from a locked configuration to an unlocked configuration (block  208 ). Additionally, hypervisor  180  may designate the startup page  202 A as executable by changing the designation of the startup page  202 A from non-executable to executable (block  210 ). 
     Subsequently, VM  170 A may be re-entered (action  212 ) and startup page  202 A may be designated as executable. VM  170 A may thereafter run kexec and may configure the unlocked control register(s) (e.g., CR  150 A) (block  214 ). After configuring the control register  150 A, VM  170 A may make a hypercall to hypervisor  180 . The hypercall may indicate that control register  150 A has been configured. Accordingly, hypervisor  180  may change the configuration of control register  150 A from the unlocked configuration to the locked configuration (e.g., by setting a sensitive bit to make the control register configuration “sticky”) (block  216 ). Additionally, hypervisor  180  may designate startup page  202 A as non-executable (block  218 ) and may re-enter the guest VM  170 A (action  220 ). 
       FIG. 3  illustrates a flowchart of an example process  300  for processor control register configuration support in accordance with an example embodiment of the present disclosure. Although the example process  300  is described with reference to the flowchart illustrated in  FIG. 3 , it will be appreciated that many other methods of performing the acts associated with the process  300  may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, blocks may be repeated, and some of the blocks described may be optional. The process  300  may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software, or a combination of both. In some examples, the actions described in the blocks of the process  300  may represent a series of instructions comprising computer-readable machine code executable by one or more processing units of one or more computing devices. In various examples, the computer-readable machine codes may be comprised of instructions selected from a native instruction set of and/or an operating system (or systems) of the one or more computing devices. 
     The example process  300  includes determining a fault resulting from an attempt to execute code from a memory page designated as non-executable (block  310 ). For example, hypervisor  180  may determine that a guest (e.g., guest VM  170 A) has attempted to execute code on a startup page (e.g., startup page  202 A) designated as non-executable. The attempt to execute code on a memory page designated as non-executable may result in a protection fault (e.g., fault  204 ). In various examples, other blocks in process  300  may be executed based on a determination by the hypervisor  180  that the fault occurred on a startup page. Further, in some examples, the hypervisor  180  may check to ensure that an offset specified by the fault corresponds to the offset at which the branch to the kexec initialization code begins on startup page  202 A, prior to performing subsequent actions of process  300 . 
     In an example, the process  300  may include unlocking a control register (block  320 ). For example, if the fault occurs on a startup page and/or if the offset matches the expected offset of the branch to the kexec initialization routine on startup page  202 A, hypervisor  180  may change the configuration of a control register (e.g., CR 0  CR 4 , etc.) from locked to unlocked. In an example, the hypervisor  180  may unlock a control register by setting a sensitive bit (e.g., an access flag) to allow changes to be made to values stored in the control register. In an example, the process  300  may include designating the memory page as executable (block  330 ). For example, the hypervisor  180  may designate the startup page  202 A as executable, thereby allowing the guest VM  170 A to run the kexec initialization routine. Additionally, since the hypervisor  180  has unlocked the control register at block  320 , the guest VM  170 A may configure values stored in the control register (e.g., by setting one or more bits of the control register). Generally, a locked configuration of a control register prevents a guest from changing a value of bits stored in the control register, while an unlocked configuration allows a guest to change the value of bits in the control register. 
     In an example, the process  300  may include receiving a hypercall indicating that the control register has been configured (block  340 ). For example, hypervisor  180  may receive a hypercall from guest VM  170 A indicating that kexec has been performed and that the control register  150 A has been configured. In some examples, the hypercall may indicate that the control register is to be locked. In an example, the process  300  may include locking the control register (block  350 ). For example, the control register (e.g., CR  150 A, which may represent CR 4 , CR 0  etc.) may be locked in response to receiving the hypercall indicating that the control register has been configured. Hypervisor  180  may lock the control register by setting a sensitive bit (e.g., an access flag) to make the control register configuration sticky. 
     In an example, the process  300  may include designating the memory page as non-executable (block  360 ). Hypervisor  180  may designate the startup page  202 A as non-executable. Accordingly, if guest VM  170 A, or another guest, attempts to execute code on the non-executable startup page  202 A, a fault will occur that may then trigger the hypervisor to unlock the control registers and/or mark the startup page  202 A as executable. 
       FIGS. 4A and 4B  illustrate a flow diagram of an example process  400  for process control register configuration support in accordance with an example embodiment of the present disclosure. Although the example method  400  is described with reference to the flow diagram illustrated in  FIGS. 4A and 4B , it will be appreciated that many other methods of performing the acts associated with the process  400  may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, blocks may be repeated, and some of the blocks described are optional. The process  400  may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software, or a combination of both. For example, hypervisor  180  and VM  170 A may communicate to perform example process  400 . In some examples, the actions described in the blocks of the process  400  may represent a series of instructions comprising computer-readable machine code executable by one or more processing units of one or more computing devices. In various examples, the computer-readable machine codes may be comprised of instructions selected from a native instruction set of and/or an operating system (or systems) of the one or more computing devices. 
     In the illustrated example, a guest (e.g., VM  170 A) may allocate a startup page (e.g., a reset page including a branch to kexec causing a new operating system to boot from a currently-executing operating system) including a branch to the kexec initialization routine (e.g., kexec.init) (block  402 ). Accordingly, startup page  202 A may be allocated and may include a branch to kexec.init at some offset within startup page  202 A (block  404 ). The startup page  202 A may be sent to the hypervisor  180  (block  406 ). 
     Upon receipt of startup page  202 A (block  408 ), hypervisor  180  may designate the startup page  202 A as non-executable (block  410 ). Accordingly, data stored in the memory addresses representing the startup page  202 A may be designated as non-executable (block  412 ). Additionally, hypervisor  180  (and/or some component of the operating system) may modify the kexec routine to jump to the address of the kexec initialization branch at the correct offset in the startup page  202 A (block  414 ). Subsequently, the guest VM  170 A may be re-entered. 
     Guest VM  170 A may make a system call to perform kexec (block  426 ). The kexec routine may jump to the branch to the kexec initialization routine at the offset in the startup page  202 A (block  428 ). However, an attempt by guest VM  170 A to execute the code at the branch to the kexec initialization routine in startup page  202 A generates a protection fault, as startup page  202 A has been previously designated as non-executable by hypervisor  180  (e.g., at block  410 ). Accordingly, fault  429  is sent to hypervisor  180  resulting from an attempt to execute code on a memory page marked non-executable. Hypervisor  180  detects the startup page fault and may determine that the memory page at which the fault occurred is startup page  202 A (block  430 ). In an example, hypervisor  180  may check the offset indicated by the protection fault to ensure that the offset matches the offset of the kexec initialization branch code of startup page  202 A (block  432 ). 
     As illustrated in  FIG. 4B , the hypervisor  180  unlocks the CPU control register(s) (block  434 ) provided that the offset in the fault  429  matches the expected offset of the kexec branch within the startup page  202 A. In various examples, if the offset in the fault  429  does not match the expected offset of the kexec branch within startup page  202 A the hypervisor  180  may maintain the locked CPU control register(s) configuration and/or the non-executable designation of startup page  202 A. The hypervisor  180  may unlock the CPU control register(s) by changing the value of one or more sensitive bits (e.g., access control flags) to allow values stored in the control register(s) to be changed. Additionally, the hypervisor  180  may designate the startup page  202 A as executable (block  436 ). Accordingly, the designation of startup page  202 A may be changed from non-executable to executable (block  438 ). Thereafter, the hypervisor  180  may re-enter the guest (e.g., VM  170 A). 
     The guest (VM  170 A) may make a system call to perform kexec (block  440 ). The system call may jump to the offset on startup page  202 A that includes the branch to the kexec initialization routine (block  442 ). As the startup page  202 A is now designated as executable, the kexec initialization routine may be executed and kexec may cause (action  443 ) hypervisor  180  to boot a new operating system from a currently-executing operating system (e.g., an existing operating system) (block  444 ). Guest (e.g., VM  170 A) may configure the CPU control registers at block  446  since the CPU control registers were previously unlocked by hypervisor  180  at block  434  in response to detection of fault  429 . Guest (e.g., VM  170 A) may change one or more bit values in the control registers (e.g., CR 0 , CR 4 , etc.). After configuration of the CPU control registers, the guest may make a hypercall (block  448 ) that may be sent to the hypervisor  180 . The hypercall may indicate that the CPU control registers have been configured and/or may comprise instructions to lock the CPU control registers. Accordingly, at block  450 , hypervisor  180  may lock the CPU control register(s) by setting a sensitive bit (e.g., an access control bit) effective to make the configuration of the CPU control register(s) sticky. Additionally, at block  452 , hypervisor  180  may change the designation of startup page  202 A from executable to non-executable. Accordingly, startup page  202 A may include the designation “non-executable” (block  454 ). Accordingly, the next time the guest runs kexec a protection fault is generated that causes the hypervisor to unlock the control registers. 
       FIG. 5  is a block diagram of an example process control register configuration support system  500  according to an example embodiment of the present disclosure. The system  500  includes a memory  520 , a processor  540  in communication with the memory  520 , a control register  504  included in and/or in communication with processor  540 , a hypervisor  510 , a currently-executing operating system  530 , a new operating system  532 , and a guest  560  (e.g., a guest virtual machine such as VM 170 A-B of  FIG. 1 ). 
     Initially, the physical host computing device may be running a currently-executing operating system  530  (e.g., host OS  186  of  FIG. 1 ). Guest  560  allocates memory page  550  at address  522  in memory  520 . Memory page  550  may include first code  554  comprising a branch to a kexec initialization routine. Memory page  550  may have a designation  552  of either executable or non-executable. Memory page  550  may initially be designated non-executable by hypervisor  510 . Additionally, hypervisor  510  may modify kexec to jump to the first code  554  (e.g., at an offset within memory page  550 ) instead of directly executing the kexec initialization routine. 
     Guest  560  may make a system call to run kexec. In response, kexec may jump to first code  554  causing a fault  562  to be detected by hypervisor  510  due to the guest  560  attempting to execute the first code  554  from a memory page  550  designated as non-executable by designation  552 . Hypervisor  510  may determine that the fault resulted from attempted execution of first code  554  on memory page  550  while memory page  550  was designated as non-executable. Hypervisor  510  may change a configuration of control register  504  from locked configuration  506   a  to unlocked configuration  506   b . In some examples, hypervisor  510  may first check that an offset indicated within the fault  562  matches the expected offset of the first code  554  within memory page  550  prior to unlocking the control register  504 . In an example, hypervisor  510  may change the control register from locked configuration  506   a  to unlocked configuration  506   b  by changing the value of a sensitive bit used to control access to the control register bits  508  (rendering the control register configuration “non-sticky”). 
     Hypervisor  510  may also change the designation  552  of the memory page  550  from non-executable to executable. Thereafter, guest  560  may be re-entered and may again make a system call to run kexec. Now, as hypervisor  510  has changed designation  552  of memory page  550  to executable, the first code  554  may be executed causing the kexec initialization routine to run. Running kexec may cause new operating system  532  to boot directly from currently-operating system  530  (in some examples skipping the bootloader stage and/or the hardware initialization phase performed by system firmware during the booting of the new operating system  532 ). 
     Guest  560  may change bit values (e.g., value(s)  509 ) of the control register bits  508  stored in control register  504  while control register  504  is in the unlocked configuration  506   b . After configuring the control register  504 , guest  560  may make hypercall  564  to hypervisor  510  causing hypervisor  510  to change the configuration of control register  504  from the unlocked configuration  506   b  back to the locked configuration  506   a . Additionally, hypervisor  510  may change the designation  552  of memory page  550  from executable back to non-executable. 
     Among other potential benefits, the various systems and techniques described herein provide CPU control register configuration support without requiring a CPU reset. This enables fast-reboot techniques such as kexec to be enabled without loss of security. For example, the only way to change the values of sensitive control register bits (such as those enabling SMAP/SMEP and write protect) is through an allocated startup page which forces the kexec initialization to boot a new operating system. 
     It will be appreciated that all of the disclosed methods and procedures described herein can be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer readable medium or machine readable medium, including volatile or non-volatile memory, such as RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be provided as software or firmware, and/or may be implemented in whole or in part in hardware components such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) or any other similar devices. The instructions may be configured to be executed by one or more processors, which when executing the series of computer instructions, performs or facilitates the performance of all or part of the disclosed methods and procedures. 
     It should be understood that various changes and modifications to the example embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.