Data manipulation detection through verification operating system

Abstract

A verification operating system (VOS) is an intermediate operating system that verifies the data of a primary operating system before the primary operating system takes control of a computing device. When a computing device is initialized, the initial boot process loads the VOS in place of the primary operating system. The VOS performs a verification process on the data that stores the primary operating system to verify that the primary operating system has not been tampered with or corrupted before handing over control of the computing device to the primary operating system. Additionally, a VOS may be used to verify operating systems used by virtual machines (VMs). The VOS verifies the data that stores the VM operating system used for a requested VM. If the VOS verifies that the VM OS data is accurate, the VOS provides the VM OS data to the hypervisor for use by the VM.

Description

[Technical Field]

[0001] The present disclosure relates to data manipulation detection through verification of an operating system at initialization time. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 397,695, entitled "Data Manipulation Detection through a Verification Operating System," filed August 12, 2022, and incorporated herein by reference.

[0003] A computing device may use an operating system (OS) that manages the hardware components of the computing device. Additionally, the operating system may provide an interface between the hardware components and applications running on the computing device. Modern operating systems can be complex software systems that offer many features that improve the operation of a computing device. However, as operating systems become more complex, they also become more difficult for software developers to properly maintain. Thus, vulnerabilities within complex operating systems may not be immediately noticed or addressed. The aforementioned vulnerabilities undermine the security of the operating system by creating opportunities for malicious actors to exploit. For example, operating systems have broad control over the functionality of a computing device and are therefore particularly attractive to malicious actors who exploit them to gain unauthorized access to or control the computing device. Thus, traditional operating systems are frequently subject to hacking attempts by malicious actors. Summary of the Invention

[0004] A verification operating system (VOS) is an intermediate operating system that verifies the data of a primary operating system before the primary operating system assumes control of a computing device. When a computing device is initialized, the initial boot process (e.g., the basic input output system (BIOS) process) loads the VOS instead of the primary operating system. The VOS performs a verification process on the data that stores the primary operating system to verify that the primary operating system has not been tampered with or corrupted. For example, the VOS may use parity bits, checksums, or cryptographic hash functions, or any combination of functions, to compare the data on the computing device that stores the primary operating system with data that stores the correct version of the primary operating system. If the VOS determines that the primary operating system stored on the computing device is correct, the VOS hands over control of the computing device to the primary operating system.

[0005] Additionally, the VOS may be used to validate operating systems used by virtual machines (VMs). The online VM system may receive instructions from a client device to initialize one or more VMs. The online VM system may allocate resources of the online VM system to one or more VMs and load the VOS onto the resources. The VOS validates data storing the VM operating system to be used for the requested VM. If the VOS verifies that the VM OS data is accurate, the VOS provides the VM OS data to the hypervisor for use in the VM. In some embodiments, the VOS generates a set of VM OS clones that are duplicates of the instance of the VM OS to be used for the VM. In embodiments where multiple instances (e.g., two or more) of the VM OS are needed (e.g., for a rolling security computing platform), the hypervisor can use the set of VM OS clones when rebuilding VMs in a server group.

[0006] By using the VOS as an intermediate operating system before handing over control of a computing device to the primary operating system, the VOS can verify the correctness of the primary operating system before the primary operating system takes control of the computing device. Thus, if the primary operating system is not verified, the primary operating system does not control the computing device. Thus, a malicious actor cannot gain unauthorized access to or control the computing device by manipulating the primary operating system. Similarly, by loading the VOS into the resources of an online VM system before loading the VM OS into the resources, the VM OS is not loaded until after it has been verified by the VOS. Thus, a malicious actor cannot exploit potential vulnerabilities in the primary operating system or VM OS when they are unable to gain access to or control the computing device or the online VM system.

[0007] The disclosed embodiments have other advantages and features that will become more readily apparent from the detailed description, the appended claims, and the accompanying drawings (or figures), a brief introduction of which is set forth below. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an exemplary system architecture of a computing device according to some embodiments. [Figure 2] FIG. 1 illustrates an exemplary system environment of an online VM system according to some embodiments. [Figure 3] 1 is an interaction diagram of an exemplary process (or method) for using a verification operating system in the boot-up process of a computing device according to some embodiments. [Figure 4] 1 is an interaction diagram of an exemplary process for using a verification operating system to verify an operating system used by a virtual machine according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0009] The drawing(s) and ensuing description relate to preferred embodiments by way of example only. It should be noted from the ensuing discussion that alternative embodiments of the structures and methods disclosed herein are readily apparent as viable alternatives that may be utilized without departing from the principles of the claims.

[0010] Reference will now be made in detail to several example embodiments illustrated in the accompanying drawings. It is noted that, wherever practical, similar or the same reference numerals may be used in the drawings and may indicate similar or the same functionality. The drawings depict embodiments of the disclosed system (or method) for purposes of illustration only. Those skilled in the art will readily appreciate from the description that follows that alternative embodiments of the structures and methods illustrated herein may be utilized without departing from the principles described herein.

[0011] Exemplary System Architecture FIG. 1 illustrates an exemplary system architecture of a computing device 100 according to some embodiments. The computing device 100 illustrated in FIG. 1 includes a processor 110, a primary memory 120, an initial boot-up module 130, a verification operating system (VOS) 140, and a secondary storage 150. Alternate embodiments may include more, fewer, or different components than those illustrated in FIG. 1, such as a network interface. Furthermore, the functionality of each component may be partitioned between different components as described below. Furthermore, each component may perform its respective functionality in response to a request from a human or automatically without human intervention.

[0012] Computing device 100 is a device that can perform computational functions for a user. For example, computing device 100 can be a desktop computer, a laptop computer, a server, a smartphone, or a tablet. In addition to the components illustrated in FIG. 1 , computing device 100 may include other components that perform additional functionality. For example, computing device 100 may include one or more communication components that enable computing device 100 to communicate with other devices, such as, for example, a network card that enables computing device 100 to communicate with devices over a network (e.g., the Internet). Computing device 100 may include or be connected to one or more user interface components, such as, for example, a display, a mouse, a keyboard, a touchscreen, or a trackpad.

[0013] Processor 110 is one or more computing processors (generally, processors or processing units) that perform calculations on computing device 100. For example, processor 110 may include a central processing unit, a graphics processing unit, a visual processing unit, a tensor processing unit, a neural processing unit, a field programmable gate array, a quantum processing unit, a controller, a state machine, and / or a microprocessor. In some embodiments, processor 110 includes one or more memories (generally one memory) that store data used by processor 110. For example, processor 110 may include registers or cache memory.

[0014] Primary memory 120 is memory that is directly accessible by processor 110. Primary memory 120 may include volatile memory, such as static random-access memory (SRAM) or dynamic random-access memory (DRAM), or may include non-volatile memory, such as read-only memory (ROM).

[0015] The initial boot-up module 130 performs one or more initial boot processes to boot the computing device 100. The initial boot process is an initialization process that occurs when the computing device 100 is handed over to an operating system before control of the computing device 100 is handed over to the operating system. For example, the initial boot-up module 130 may include a basic input / output system (BIOS), and the initial boot process may include a process performed by the BIOS to boot the computing device 100. In some embodiments, instructions for the initial boot process performed by the initial boot-up module 130 are stored in ROM within the primary memory 120. The initial boot process may include a process in which secondary storage 150 is decrypted. For example, the secondary storage 150 may apply one or more levels of encryption to data stored on the secondary storage 150, and the initial boot-up module 130 may decrypt the data stored on the secondary storage 150.

[0016] The initial boot-up module 130 may perform the initial boot process upon receiving a boot input signal. The boot input signal is a signal that instructs the initial boot-up module 130 to begin operation of the computing device 100. For example, the boot input signal may be a cold boot signal generated when the computing device 100 is powered on, or a warm boot signal generated when the computing device 100 is restarted without interrupting power to the computing device 100. In some embodiments, the boot input signal is generated when the power switch of the computing device 100 is activated by a user. For example, the boot input signal may be generated after the computing device 100 has been powered off for a configurable set of power cycle times to empty any capacitor caches and enable a new power cycle based on the time event. The delayed power cycle ensures that temporary changes are not carried over from the previous boot cycle.

[0017] Initial boot-up module 130 may perform an initial boot process that verifies that hardware in computing device 100 is functioning properly and brings up components of computing device 100, such as processor 110 and primary memory 120. Initial boot-up module 130 may then perform a boot loader process that loads the OS from secondary storage 150. In some embodiments, secondary storage 150 includes its own encryption and authentication process that unlocks access to the drive, partition, virtual drive, or other element that stores VOS 140. The boot loader process loads VOS 140 and hands control of computing device 100 over to VOS 140.

[0018] VOS 140 controls computing device 100 as an intermediate step between the initial boot process performed by initial boot-up module 130 and when the primary OS takes control of computing device 100. VOS 140 is an operating system that performs a validation process on data stored in secondary storage 150 before the primary OS takes control of computing device 100. VOS 140 may include a kernel that handles control of the hardware components of computing device 100. Additionally, VOS 140 may include higher level functionality, such as user accounts and application interfaces. VOS 140 may be stored in secondary storage 150 or in ROM in primary memory 120.

[0019] The verification process performed by VOS 140 is a process that verifies that data stored by secondary storage 150 has not been manipulated or corrupted. For example, the verification process may verify data stored by secondary storage 150 using one or more combinations of parity bits, checksums, or cryptographic hashes, other cryptographic elements, malware, stegonography, system features such as clocks, custom hardware signatures, or more. In some embodiments, the verification process compares data stored by secondary storage 150 with known accurate data. Additionally, the verification process may include one or more steps performed at a server with which VOS 140 communicates. For example, VOS may send data from secondary storage 150 to be verified to a remote server. VOS 140 may then receive a response from the server indicating whether the data is accurate or whether there is an error with the transmitted data. In some embodiments, VOS 140 verifies data stored by primary memory 120 or in external storage.

[0020] VOS 140 verifies that primary OS data 160 stored on secondary storage 150 is accurate. Primary OS data 160 is the data that makes up the primary operating system. The primary OS is the operating system that computing device 100 uses during normal operation. For example, the primary OS may include Windows, MacOS, Linux, iOS, Android, or ChromeOS. The data of the primary OS may include executable files, source code, machine code, and other files that implement the functionality of the primary OS. The primary OS data 160 may include a set of files or a set of data blocks stored on secondary storage 150.

[0021] In some embodiments, VOS 140 validates application data 170 stored by secondary storage 150. Application data 170 is data that makes up an application that runs on computing device 100. For example, application data 160 may include executable files, source code, machine code, or other files that implement an application that runs on computing device 100. Application data 160 may include a set of files or a set of data blocks stored on secondary storage 150.

[0022] In some embodiments, VOS 140 verifies user data 180 stored by secondary storage 150. User data 180 is data stored on computing device 100 by a user. For example, user data 180 may include documents, photos, and videos stored on secondary storage 150. User data 180 may include a set of files or a set of data blocks stored on secondary storage 150.

[0023] Once VOS 140 verifies that the data stored in secondary storage 150 is accurate, VOS 140 loads the primary OS into primary memory and transfers control of computing device 100 to the primary OS. For example, VOS 140 may load instructions for bootstrapping the primary OS from a location in secondary storage 150 where VOS 140 stored the instructions. Upon transferring control of the computing device to the primary OS, VOS 140 may cease operation or may perform some background process.

[0024] If VOS 140 detects that data stored on secondary storage 150 is inaccurate (e.g., tampered with or corrupted), VOS 140 may perform one or more fault handling processes to correct the inaccuracy or minimize the impact of the inaccuracy. For example, VOS 140 may not load or transfer control to the primary OS for computing device 100. VOS 140 may fix or attempt to fix the inaccuracy in the data, or may replace the data with a version of the data that is known to be accurate. For example, if VOS 140 determines that there is an inaccuracy in primary OS data 160, VOS 140 may reinstall the primary OS on computing device 100. Similarly, VOS 140 may replace data blocks or files stored on secondary storage 150 based on data blocks or files in a known good state. If VOS 140 analyzes and determines that the inaccurate data results from manipulation by a malicious actor or from data corruption, the primary OS will not load. VOS 140 may further generate a notification that the data in secondary storage 150 could not be verified and / or that the primary OS is not loaded. Additionally, if VOS determines that there is inaccuracy in the data stored in secondary storage 150, VOS 140 may delete the data in secondary storage 150 to prevent access to the data by potentially malicious actors.

[0025] Figure 2 illustrates an exemplary system environment of an online VM system 220 according to some embodiments. The system environment illustrated in Figure 2 includes a client device 200, a network 210, and an online VM system 220. Alternative embodiments may include more, fewer, or different components than those illustrated in Figure 2, and the functionality of each component may be partitioned among the components differently than described below. Additionally, each component may perform its respective functionality in response to a request from a human or automatically without human intervention.

[0026] A user can interact with the online VM system 220 through a client device 200. For example, the client device 200 can be a personal or mobile computing device, such as a smartphone, a tablet, a laptop computer, or a desktop computer. In some embodiments, the client device 200 is a device similar to the computing device 100 illustrated in FIG. 1. The client device 200 may execute a client application that uses an application programming interface (API) to communicate with the online VM system 220 over the network 210.

[0027] The client device 200 may send initialization instructions to the online VM system 220 to create a virtual machine (VM). The initialization instructions may specify the resources required for the VM (e.g., processing power, primary memory, secondary storage, network bandwidth), how long the VM should run, what type of operating system the VM should use, and what applications should be available in the VM. Additionally, the client device 200 may include an interface that a user can use to interact with the VM in the online VM system 220. In some embodiments, the client device 200 is an AI-controlled system that communicates with the online VM system 220.

[0028] Client device 200 may communicate with online VM system 220 via network 210. Network 210 may be a local area and / or wide area network utilizing wired and / or wireless communication links. In some embodiments, network 210 uses standard communication technologies and protocols. For example, network 210 may include communication links using technologies such as Ethernet, Fibre Channel, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, code division multiple access (CDMA), digital subscriber line (DSL), etc. Examples of network protocols used to communicate over network 210 include Multiprotocol Label Switching (MPLS), Transmission Control Protocol / Internet Protocol (TCP / IP), Hypertext Transport Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP). Data exchanged over network 210 may be represented using any format, such as hypertext markup language (HTML) or extensible markup language (XML). In some embodiments, all or some of the communication links of network 210 may be encrypted.

[0029] Furthermore, FIG. 2 illustrates an exemplary system architecture of an online VM system 220 according to some embodiments. The VM system is built on a computing device architecture including one or more processors, memory, storage devices, and network connections. The online VM system 220 illustrated in FIG. 2 includes an initial boot-up module 230, a verification OS module 240, a hypervisor (or virtual machine monitor) module 250, and data storage 260. Alternative embodiments may include more, fewer, or different components than those illustrated in FIG. 1, and the functionality of each component may be partitioned among the components differently than described below. Furthermore, each component may perform its respective functionality in response to a request from a human or automatically without human intervention.

[0030] The initial boot-up module 230 receives initialization instructions from the client device 200 and begins a process to initialize a VM in the online VM system 220. For example, the initial boot-up module 230 may identify physical resources in the online VM system 220 to be used for the VM requested by the client device 200. The initial boot-up module 230 may pass control of the identified resources to the verification OS module 240. Additionally, the initial boot-up module 230 may authenticate the client device 200 using an encryption key, an authentication process, a password verification process, or a file fingerprint.

[0031] The verification OS module 240 loads the VOS onto the VM resources and verifies the data stored in data storage 260 before handing over control of the resources to the VM OS hypervisor. The verification OS module 240 may use one instance of the VOS to control the identified VM resources for multiple final VMs, or may use one VOS instance for each final VM. The VOS used by the verification OS module 240 may include some or all of the functionality of the VOS 140 described in FIG. 1.

[0032] The VOS used by verify OS module 240 performs one or more verification processes on data stored in data storage 260. For example, the VOS may verify VM OS data 270 stored in data storage 260. VM OS data 270 is data that makes up one or more operating systems that may be used during normal operation of a virtual machine in online VM system 220. For example, VM OS data 270 may include executable files, source code, machine code, or other files that implement the functionality of an operating system that may be used by a VM. In some embodiments, the VOS validates application data and / or user data stored in online VM system 220.

[0033] If verification OS module 240 verifies VM OS data 270, verification OS module 240 may generate a set of OS clones based on the verified OS. An OS clone is an instance of a VM OS cloned based on verified VM OS data 270. Each OS clone may be generated to run in a specific VM using specific resources in online VM system 220. In some embodiments, each OS clone is encrypted so that the OS clone can only run in a specific VM. The OS clones may be used by a rolling security platform to reconstruct VMs running in a sever group. U.S. Patent No. 9,906,530, entitled "Rolling Security Platform," contains more information on rolling security platforms, the contents of which are incorporated herein by reference.

[0034] Additionally, the VOS may validate hypervisor data 280 stored in data storage 260. Hypervisor data 280 is data that creates the hypervisor used by online VM system 220 to manage VMs. For example, hypervisor data 280 may include executable files, source code, machine code, or other files that implement the functionality of the hypervisor of online VM system 220. The VOS may provide the validated hypervisor data 280 to hypervisor module 250, which will be used by the hypervisor for the VMs. In some embodiments, the VOS provides hypervisor module 250 with a set of OS clones to use for the VMs.

[0035] The hypervisor module 250 creates and operates VMs using one or more hypervisors. The hypervisor may manage the allocation of physical resources to VMs in the online VM system 220 and may provide an interface between the physical resources and the VMs. Additionally, the hypervisor may provide an interface between the VMs and the client device 200 that requested the VM. In some embodiments, the hypervisor initializes and rebuilds the VM using an OS clone provided by the verification OS module 240 (e.g., when using a rolling security platform, such as described in U.S. Pat. No. 9,906,530, entitled "Rolling Security Platform," filed September 17, 2015, which is incorporated by reference herein). For example, the hypervisor may build a new VM session using the OS clone when the previous VM session has been shut down.

[0036] Figure 3 is an interaction diagram of an exemplary process (or method) for using a verification operating system in the boot-up process of a computing device according to some embodiments. Alternate embodiments may include more, fewer, or different components than those illustrated in Figure 3, and the steps may occur in a different order than those illustrated in Figure 3. Furthermore, each of the steps just described may be performed automatically by the computing device without human intervention.

[0037] The initial boot-up module 300 of the computing device receives 315 a boot input signal that instructs the initial boot-up module 300 to begin operation of the computing device. For example, the boot input signal may be a cold boot signal indicating that the computing device has been powered on, or a warm boot signal indicating that the computing device has restarted without an interruption in power to the computing device.

[0038] The initial boot-up module 300 performs 320 one or more initial boot-up processes to boot the computing device. For example, the initial boot-up module 300 may perform one or more processes performed by the BIOS of the initial boot-up module 300. Once the initial boot-up process is complete, the initial boot-up module 300 loads 325 the verification operating system 305. In some embodiments, loading 325 the verification operating system 305 includes transferring control of the computing device to the verification operating system 305.

[0039] The verification operating system 305 performs 330 one or more verification processes for data stored on a computing device, such as computing device 100. The verification operating system 305 may perform 330 a verification process for a set of data blocks stored on the secondary storage of the computing device or a set of files stored on the secondary storage of the computing device. The verification operating system 305 verifies 335 primary OS data stored by the computing device. In some embodiments, the verification operating system 305 verifies 340 application data stored on the computing device. Additionally, the verification operating system 305 may verify 345 user data stored on the computing device.

[0040] If the verification operating system 305 successfully verifies 350 that the data stored on the computing device has not been manipulated or corrupted, the verification operating system 305 loads 335 the primary operating system 310. In some embodiments, loading 355 the primary operating system 310 includes handing control of the computing device to the primary operating system 310. If the verification operating system 305 determines that the data stored on the computing device has been manipulated or corrupted, the verification operating system 305 executes 360 a fault handling process. For example, the verification operating system 305 may notify a user of the manipulated or corrupted data and may prevent the primary operating system 310 from loading, or may attempt to fix the manipulated or corrupted data and load the primary operating system 310 if fixed or will not load the primary operating system 310 if not fixed.

[0041] Figure 4 is an interaction diagram of an exemplary process (or method) using a verification operating system to verify an operating system used by a virtual machine, such as online virtual machine system 220, according to some embodiments. Alternate embodiments may include more, fewer, or different components than those illustrated in Figure 4, and the steps may occur in a different order than those illustrated in Figure 4. Additionally, each of the steps just described may be performed automatically by an online system without human intervention.

[0042] An initial boot-up module 400 of the online VM system receives 415 initialization instructions from a client device. The initialization instructions are instructions to initialize one or more VMs in the online VM system. The initialization instructions may include instructions on how many VMs to initialize, what kind of resources should be available to the VMs, how long the VMs should run, what kind of operating system the VMs should use, or which applications should be available in the VMs. The initial boot-up module 400 performs 420 initial boot-up processes (e.g., identifying physical resources of the online VM system to use for the VMs) and loads 425 a verification operating system 405. In some embodiments, loading 425 the verification operating system 405 includes handing over control of the physical resources identified by the initial boot-up module 400 to the verification operating system 405.

[0043] The verification operating system 405 verifies 430 the hypervisor data stored in the data storage of the online VM system. If the verification operating system 405 successfully verifies 432 that the hypervisor data has not been manipulated or corrupted, the verification operating system 405 initializes 435 the hypervisor based on the hypervisor data. The verification operating system 405 verifies 440 the VM OS data against the operating system to be used by the VM requested by the client device. If the verification operating system verifies 442 that the VM OS data has not been manipulated or corrupted, the verification operating system 405 generates 445 a set of VM OS clones based on the verified VM OS data and provides 450 the VM OS clones to the hypervisor.

[0044] The verification operating system 405 may perform an error handling process 455 if the verification operating system 405 does not successfully verify 432 the hypervisor data and / or does not successfully verify 442 the VM OS data. For example, the verification operating system 405 may attempt to fix the hypervisor data and / or the VM OS data to remove inaccuracies from possible manipulation or corruption of the hypervisor data and / or the VM OS data. If the verification operating system 405 is able to fix the hypervisor data and / or the VM OS data, the verification operating system 405 may initialize 435 the hypervisor and provide 450 the VM OS clone to the hypervisor module 410. In some embodiments, the verification operating system 405 attempts to replace the hypervisor data and / or the VM OS data with a version of the data that is known to be accurate. Additionally, the verification operating system 405 does not initialize 435 the hypervisor and / or does not create 445 the VM OS clone. The verification operating system 405 may notify the user that the hypervisor data and / or VM OS data has been manipulated or corrupted.

[0045] Although described in the context of a VM system, the techniques described above may be applied to verifying data for other computing systems, such as bare metal servers, embedded operating systems, or software containers. For example, for a bare metal server, the server may perform the processing illustrated in FIG. 3, or for a bare metal server, the hypervisor and operating system may be verified as illustrated in FIG. 4. Similarly, a software container comprises an isolated computing environment. An online system may verify the hypervisor that manages the online system's containers, as illustrated in FIG. 4, and may verify data stored by the containers, as illustrated in FIG. 3. For an embedded operating system, the system may perform a method similar to that illustrated in FIG. 3.

[0046] Additional Considerations By using the VOS as an intermediate operating system before handing over control of a computing device to the primary operating system, the VOS can ensure that the primary operating system has not been manipulated or corrupted in a way that could expose a user's personal data to theft by malicious actors. Furthermore, by loading the VOS onto the resources of an online VM system before loading the VM OS onto the resources, the VM OS is not loaded until it has been verified by the VOS. Thus, the VOS addresses the long-standing problem of data security in personal computing devices and for online systems.

[0047] The foregoing description of embodiments has been provided for illustrative purposes and is not intended to be comprehensive or to limit patent rights to the precise pages disclosed. Those skilled in the art to which it pertains will recognize that many modifications and variations are possible in light of the above disclosure.

[0048] Some portions of the description describe embodiments in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by data processing engineers to effectively convey the substance of their work to others skilled in the art. The operations described herein, while described functionally, computationally, or logically, will be understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. Moreover, it has proven convenient at times, without loss of generality, to refer to the described arrangements of operations as modules. The described operations and associated modules may be embodied in software, firmware, hardware, or any combination thereof.

[0049] Any of the steps, operations, or processes described herein may be performed or implemented by one or more hardware or software modules, alone or in combination with other devices. In some embodiments, a software module is implemented by a computer program product that includes one or more computer-readable media containing computer program code or instructions, which can be executed by a computer processor to perform any or all of the described steps, operations, or processes. In some embodiments, a computer-readable medium includes one or more computer-readable media that, individually or together, contain instructions that, when executed by one or more processors, cause the one or more processors to perform, individually or together, the steps of the instructions stored on the one or more computer-readable media.

[0050] Additionally, embodiments may relate to apparatus for performing the operations herein. The presently described apparatus may be specially constructed for the required purposes and / or may include a general-purpose computing device selectively activated or reconfigured by a computer program stored in a computer. The computer program may be stored on a non-transitory, tangible, computer-readable storage medium or any type of medium suitable for storing electronic instructions, which may be coupled to a computer system bus. -Furthermore, the computing systems referred to herein may include a single processor or may be architectures utilizing multiple processor designs for increased computing performance.

[0051] Additionally, embodiments may relate to products produced by the computer processes described herein. The products may include information resulting from the computer processes, which information may be stored on a non-transitory, tangible, computer-readable storage medium and may include any embodiment of a computer program product or other data combination described herein.

[0052] Finally, the style used herein has been selected primarily for ease of reading and instructional purposes, and may not have been selected to delineate or limit the inventive subject matter. Accordingly, it is intended that the scope of patent rights be limited not by the detailed description set forth hereinabove, but rather by any claims issuing on an application based thereon. Accordingly, the disclosure of the embodiments is intended to illustrate, but not limit, the scope of patent rights discussed in the claims that follow.

[0053] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements just mentioned, but may include other elements not expressly listed or inherent in the process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" refers to an inclusive or, not an exclusive or. For example, condition A or B satisfies any one of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), or both A and B are true (or exist).

Claims

1. When executed by a processor, the processor: receiving a boot input signal that initializes operation of the computing device; Upon receiving the boot input signal, performing one or more initial boot processes for the computing device; loading a verification operating system onto the computing device via the one or more initial boot processes; verifying, with the verification operating system, a set of data in secondary storage of the computing device, the set of data including data stored with a primary operating system for the computing device; loading the primary operating system on the computing device in response to verifying the set of data; or executing a failure handling process in response to a failure of validation of said set of data; Do one of the following:

10. A non-transitory computer-readable medium comprising stored instructions for causing a computer to:

2. 10. The non-transitory computer-readable medium of claim 1, wherein the one or more early boot processes further include instructions that, when executed, cause a processor to perform basic input / output system operations.

3. 2. The non-transitory computer-readable medium of claim 1, wherein the instructions for loading the verification operating system further comprise instructions that, when executed by the processor, cause the processor to load the verification operating system from a read-only memory of the computing device.

4. 2. The non-transitory computer-readable medium of claim 1, wherein the set of data includes a set of data blocks that stores the primary operating system.

5. 2. The non-transitory computer-readable medium of claim 1, wherein the set of data includes a set of data files that store the primary operating system.

6. The non-transitory computer-readable medium of claim 1 , wherein the set of data further comprises data storing an application on the computing device.

7. The non-transitory computer-readable medium of claim 1 , wherein the set of data further comprises data storing user data.

8. a processor; When executed by the processor, the processor: receiving a boot input signal that initializes operation of the computing device; Upon receiving the boot input signal, performing one or more initial boot processes for the computing device; loading a verification operating system onto the computing device via the one or more initial boot processes; verifying, with the verification operating system, a set of data in secondary storage of the computing device, the set of data including data stored with a primary operating system for the computing device; loading the primary operating system on the computing device in response to verifying the set of data; or executing a failure handling process in response to a failure of validation of said set of data; Do one of the following: a non-transitory computer-readable medium including stored instructions for causing the A system comprising:

9. 10. The system of claim 8, wherein the one or more early boot processes further include instructions that, when executed, cause the processor to perform basic input / output system operations.

10. 10. The system of claim 8, wherein the instructions for loading the verification operating system further comprise instructions that, when executed by the processor, cause the processor to load the verification operating system from a read-only memory of the computing device.

11. 9. The system of claim 8, wherein the set of data includes a set of data blocks that stores the primary operating system.

12. 9. The system of claim 8, wherein the set of data includes a set of data files that store the primary operating system.

13. The system of claim 8 , wherein the set of data further comprises data storing an application on the computing device.

14. 10. The system of claim 8, wherein the set of data further comprises data storing user data.

15. receiving a boot input signal that initializes operation of the computing device; executing one or more initial boot processes for the computing device upon receiving the boot input signal; loading a verification operating system onto the computing device via the one or more initial boot processes; verifying, with the verification operating system, a set of data in secondary storage of the computing device, the set of data including data stored with a primary operating system for the computing device; loading the primary operating system on the computing device in response to verifying the set of data; or executing a failure handling process in response to a failure of validation of said set of data; and A method comprising:

16. 16. The method of claim 15, wherein the one or more early boot processes include operation of a basic input / output system.

17. 16. The method of claim 15, wherein loading the verification operating system further comprises loading the verification operating system from a read-only memory of the computing device.

18. 16. The method of claim 15, wherein the set of data includes a set of data blocks that stores the primary operating system.

19. The method of claim 15, wherein the set of data further comprises data storing an application on the computing device.

20. 16. The method of claim 15, wherein the set of data further comprises data storing user data.

Images