阅读说明：本技术 使用硬件保护操作系统配置 (Protecting operating system configuration using hardware ) 是由 P·J·卡拉汉 于 2018-06-12 设计创作，主要内容包括：一种方法,系统和计算机程序产品包括在计算系统的启动状态下接收加载操作系统配置的请求。该方法还包括响应于接收到请求而自动存储用于认证操作系统配置的数字密钥。该方法还包括重启计算系统。响应于重启计算系统并且当计算系统处于预启动状态时,该方法包括：证实所存储的数字密钥是用于有效操作系统配置的数字密钥；从物理地耦接到计算系统的用户接口接收确认所接收的请求的信号；响应于接收到信号,使用数字密钥认证操作系统配置；并且响应于认证,启动操作系统配置。(A method, system, and computer program product include receiving a request to load an operating system configuration in a boot state of a computing system. The method also includes automatically storing a digital key for authenticating the operating system configuration in response to receiving the request. The method also includes restarting the computing system. In response to restarting the computing system and while the computing system is in a pre-boot state, the method includes: verifying that the stored digital key is a digital key for a valid operating system configuration; receiving a signal from a user interface physically coupled to the computing system confirming the received request; authenticating the operating system configuration using the digital key in response to receiving the signal; and in response to authentication, initiating operating system configuration.)

1. A method, comprising:

receiving a request to load an operating system configuration in a boot state of a computing system;

in response to receiving the request, automatically storing a digital key for authenticating the operating system configuration;

restarting the computing system;

in response to restarting the computing system and while the computing system is in a pre-boot state:

verifying that the stored digital key is a digital key for a valid operating system configuration;

receiving a signal from a user interface physically coupled to the computing system acknowledging the received request;

authenticating the operating system configuration using the digital key in response to receiving the signal; and

in response to the authentication, initiating the operating system configuration.

2. The method of claim 1, further comprising:

prior to the receiving, determining that a public key corresponds to an operating system configuration authorized to be booted on the computing system.

3. The method of claim 1, further comprising:

in response to receiving an acknowledgement signal, moving the digital key to a protected memory of the computing system, wherein the protected memory is writable only when the computing system is in a pre-boot state.

4. The method of claim 3, wherein the protected memory is writable only by a software application that performs code integrity certification by a hardware component of the computing system.

5. The method of claim 3, wherein the authenticating comprises: the digital key is retrieved from the protected memory and a digital signature of the operating system configuration is verified using the retrieved digital key.

6. The method of claim 1, wherein the operating system configuration comprises:

an operating system kernel; and

a set of parameters for executing an access control policy of the operating system kernel.

7. The method of claim 6, wherein the set of parameters is compiled into executable code of the operating system kernel.

8. The method of claim 1, wherein:

the operating system configuration is digitally signed by a private key of a public-private key pair, and

the digital key is a public key of the public-private key pair.

9. A system, comprising:

a user interface terminal;

a computing system physically coupled to the user interface terminal and having a memory and a processor; and

a computer readable storage medium of the computing system having program instructions embodied in the computer readable storage medium that are executable by the processor to cause the system to:

receiving a request to load an operating system configuration in a boot state of the computing system;

in response to receiving the request, automatically storing a digital key for authenticating the operating system configuration;

restarting the computing system;

in response to restarting the computing system and while the computing system is in a pre-boot state:

verifying that the stored digital key is a digital key for a valid operating system configuration;

receiving a signal from a user interface physically coupled to the computing system acknowledging the received request;

authenticating the operating system configuration using the digital key in response to receiving the signal; and

in response to the authentication, initiating the operating system configuration.

10. The system of claim 9, wherein the program instructions are further executable by the processor to cause the system to:

prior to the receiving, determining that a public key corresponds to an operating system configuration authorized to be booted on the computing system.

11. The system of claim 9, wherein the program instructions are further executable by the processor to cause the system to:

in response to receiving an acknowledgement signal, moving the digital key to a protected memory of the computing system, wherein the protected memory is writable only when the computing system is in a pre-boot state.

12. The system of claim 11, wherein the protected memory is writable only by software applications that perform code integrity certified by a hardware component of the computing system.

13. The system of claim 11, wherein the program instructions are further executable by the processor to cause the system to retrieve the digital key from the protected memory and verify a digital signature of the operating system configuration using the retrieved digital key.

14. The system of claim 9, wherein the operating system configuration comprises:

an operating system kernel; and

a set of parameters for executing an access control policy of the operating system kernel.

15. The system of claim 14, wherein the set of parameters is compiled into executable code of the operating system kernel.

16. The system of claim 9, wherein:

the operating system configuration is digitally signed by a private key of a public-private key pair, and

the digital key is a public key of the public-private key pair.

17. A computer program product for securely booting a computing system, the computer program product comprising a computer readable storage medium having program instructions embodied therein, wherein the computer readable storage medium is not itself a transitory signal, the program instructions executable by a processor to cause the computing system to perform a method comprising:

receiving a request to load an operating system configuration in a boot state of the computing system;

in response to receiving the request, automatically storing a digital key for authenticating the operating system configuration;

restarting the computing system;

in response to restarting the computing system and while the computing system is in a pre-boot state:

verifying that the stored digital key is a digital key for a valid operating system configuration;

receiving a signal from a user interface physically coupled to the computing system acknowledging the received request;

authenticating the operating system configuration using the digital key in response to receiving the signal; and

in response to the authentication, initiating the operating system configuration.

18. The computer program of claim 17, wherein the method further comprises:

prior to the receiving, determining that a public key corresponds to an operating system configuration authorized to be booted on the computing system.

19. The computer program of claim 17, wherein the method further comprises:

in response to receiving an acknowledgement signal, moving the digital key to a protected memory of the computing system, wherein the protected memory is writable only when the computing system is in a pre-boot state.

20. The computer program product of claim 17, wherein the operating system configuration comprises:

an operating system kernel; and

a set of parameters for executing an access control policy of the operating system kernel.

21. A method, comprising:

receiving, from a user application executing under a first operating system configuration on a computing device, a request to execute a second operating system configuration of a set of operating system configurations, wherein the second operating system configuration is:

signed by a private key of a public-private key pair, and

at least comprising an operating system kernel compiled with a set of parameters associated with an access control policy configured by the second operating system;

in response to receiving the request, storing, in a non-volatile memory of the computing device, a public key corresponding to the private key; and

during a pre-boot state of the computing device, executing a trusted application to:

verifying that the stored digital key is a digital key for a valid operating system configuration,

receiving a signal from a local interface to the computing device acknowledging the received request,

moving the public key into protected memory when the signal acknowledges the request, an

Executing a boot loader having access to the protected memory to authenticate the second operating system using a public key stored in the protected memory and to boot the second operating system configuration in response to the authentication.

22. The method of claim 21, wherein the set of parameters determines a software module that is loadable in the second operating system configuration.

23. The method of claim 21, wherein the set of parameters determines enforcement of the access control policy.

24. The method of claim 21, wherein the protected memory is writable only by a set of applications whose executable code integrity is certified by a hardware component of the computing system, the set of applications including the trusted application.

25. A system, comprising:

a user interface terminal;

a computing system physically coupled to the user interface terminal and having a memory and a processor; and

computer readable storage media of one or more computing nodes having program instructions embodied in the computer readable storage media executable by the processor to cause the system to:

receiving, from a user application executing under a first operating system configuration on a computing device, a request to execute a second operating system configuration of a set of operating system configurations, wherein the second operating system configuration is:

signed by a private key of a public-private key pair, and

at least comprising an operating system kernel compiled with a set of parameters associated with an access control policy configured by the second operating system;

in response to receiving the request, storing, in a non-volatile memory of the computing device, a public key corresponding to the private key; and

during a pre-boot state of the computing device, executing a trusted application to:

verifying that the stored digital key is a digital key for a valid operating system configuration,

receiving a signal from the user interface terminal acknowledging the received request,

moving the public key into protected memory when the signal acknowledges the request, an

Executing a boot loader having access to the protected memory to authenticate the second operating system using a public key stored in the protected memory and to boot the second operating system configuration in response to the authentication.

Background

The present disclosure relates to computing systems employing secure booting of an operating system. More particularly, the present disclosure relates to using hardware to protect operating system configurations of computing systems.

The computing system has an access control policy that can restrict a user's access to the file system object. For example, access control policies may restrict files that a user may modify, or they may prohibit a user from loading a given operating system module. The access control policy may be enforced by a configuration of an operating system executing on the computing system. In turn, the operating system configuration may be determined by setting kernel parameters corresponding to a given configuration of an operating system kernel before the kernel is used to boot the computing system to a state suitable for executing user applications. Once the computing system is booted using a given operating system configuration, the access control policies enforced by that configuration may remain in effect until the computing system boots under a different operating system configuration, if the computing system permits.

Some computing systems enable a user to select from a set of different operating system configurations. Users with active accounts on these computing systems may change the access control policy (or enforcement of the access control policy) of the computing system by selecting and launching an operating system configuration that has a different access control policy than the configuration currently being launched.

It is common for users to use account credentials (e.g., username and password) to remotely access a computing system. Accessing the computing system remotely by a user typically follows the same access control policy as accessing the computing system by the user from a local terminal. Thus, an authorized user of the computing system may remotely change the access control policy of the computing system using the previously described processes. However, the result of this system is that unauthorized users who are able to obtain access credentials of authorized users to the computing system may also remotely change the access control policies of the computing system, potentially raising their access rights to the computing system.

In view of the foregoing, there is a need for a technique for enabling a user of a computing system to select from a set of different operating system configurations, with the following assurances: the selected configuration has not been modified, changed, or otherwise tampered with prior to launching the selected configuration on the computing system.

Disclosure of Invention

Embodiments of the present disclosure include methods, systems, and computer program products that enable a user of a computing system to select from a set of different operating system configurations and ensure that the selected configuration has not been modified, changed, or otherwise tampered with prior to launching the selected configuration on the computing system. Embodiments disclosed herein provide advantages in security, access flexibility, and computing system management.

According to an embodiment of the present disclosure, a method includes receiving, in a boot state of a computing system, a request to load an operating system configuration. The method also includes automatically storing a digital key for authenticating the operating system configuration in response to receiving the request. The method also includes restarting the computing system. In response to restarting the computing system and while the computing system is in a pre-boot state, the method includes: verifying that the stored digital key is a digital key for a valid operating system configuration; receiving a signal from a user interface physically coupled to the computing system confirming the received request; authenticating the operating system configuration using a digital key in response to receiving the signal; and in response to authentication, initiating the operating system configuration.

According to various embodiments of the present disclosure, a system includes a user interface terminal, a computing system physically coupled to the user interface terminal and having a memory, a processor, and a computer-readable storage medium in which program instructions are embodied. The program instructions are executable by the processor to cause the system to receive a request to load an operating system configuration in a boot state of the computing system. The program instructions are also executable by the processor to cause the system to automatically store a digital key for authenticating an operating system configuration in response to receiving the request. The computing system is then restarted.

In response to restarting the computing system and while the computing system is in a pre-boot state, the program instructions are further executable by the processor to cause the system to: verifying that the stored digital key is a digital key for a valid operating system configuration; receiving a signal from a user interface physically coupled to the computing system confirming the received request; authenticating the operating system configuration using the digital key in response to receiving the signal; and in response to authentication, initiating the operating system configuration.

Various embodiments relate to a computer program product for a securely booted computing system. The computer program product includes a computer readable storage medium having program instructions embodied therein, wherein the computer readable storage medium is not a transitory signal and the program instructions are executable by a processor to cause a computing system to perform a method including receiving a request to load an operating system configuration in a boot state of the computing system. The method also includes automatically storing a digital key for authenticating the operating system configuration in response to receiving the request. The method then includes restarting the computing system.

In response to restarting the computing system and while the computing system is in a pre-boot state, the method further comprises: verifying that the stored digital key is a digital key for a valid operating system configuration; receiving a signal from a user interface physically coupled to the computing system confirming the received request; authenticating the operating system configuration using the digital key in response to receiving the signal; and in response to authentication, initiating operating system configuration.

In accordance with an alternative embodiment of the present disclosure, a method includes receiving, from a user application executing under a first operating system configuration on a computing device, a request to execute a second operating system configuration of a set of operating system configurations. The second operating system configuration is signed by a private key of the public-private key pair and includes at least an operating system kernel compiled with a set of parameters associated with an access control policy of the second operating system configuration. The method also includes, in response to receiving the request, storing, in non-volatile memory of the computing device, a public key corresponding to the private key. The method also includes executing the trusted application during a pre-boot state of the computing device to: verifying that the public key stored in the non-volatile memory is a public key for a valid operating system configuration; receiving a signal from a local interface to the computing device acknowledging the received request; moving the public key into the protected memory when the signal acknowledges the request; and executing a boot loader accessible to the protected memory to authenticate the second operating system using the public key stored in the protected memory and, in response to authentication, to boot the second operating system configuration.

According to an alternative embodiment of the present disclosure, a system includes a user interface terminal, a computing system physically coupled to the user interface terminal and having a memory, a processor, and a computer-readable storage medium having program instructions embodied therein. The program instructions are executable by the processor to cause the system to receive a request from a user application executing under a first operating system configuration on the computing device to execute a second operating system configuration of the set of operating system configurations. The second operating system configuration is signed by a private key of the public-private key pair and includes at least an operating system kernel compiled with a set of parameters associated with an access control policy of the second operating system configuration.

The program instructions are further executable by the processor to cause the system to store, in a non-volatile memory of a computing device, a public key corresponding to the private key in response to receiving the request. The program instructions are also executable by the processor to cause the system to execute a trusted application during a pre-boot state of the computing device to: the public key stored in the non-volatile memory is certified as a public key for valid operating system configurations. Receiving a signal from the user interface terminal confirming the received request; moving the public key into the protected memory when the signal acknowledges the request; and executing a boot loader accessible to the protected memory to authenticate the second operating system using the public key stored in the protected memory and to boot the second operating system configuration in response to the authentication.

The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure.

Drawings

The accompanying drawings, which are incorporated in and form a part of the specification, are incorporated in and constitute a part of this application. They illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are only for purposes of illustrating certain embodiments and are not to be construed as limiting the disclosure.

FIG. 1 depicts a flowchart of a set of computer-implemented operations for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments.

FIG. 2 depicts a flowchart of an example of a set of computer-implemented operations for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments.

FIG. 3 depicts a block diagram of an example system for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments.

FIG. 4 depicts a flowchart of a set of computer-implemented operations for securely initiating a user selection of an operating system configuration from a set of operating system configurations using hardware and software, in accordance with various embodiments.

FIG. 5 depicts an interaction diagram of interactions between a user and a computing system that performs a set of computer-implemented operations for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments.

FIG. 6 depicts a block diagram of a computer system having hardware and software components for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments.

While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

Detailed Description

Aspects of the present disclosure relate to computing systems utilizing secure booting of an operating system, and more particularly to securing an operating system configuration of a computing system prior to booting using hardware. While the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure may be appreciated through a discussion of various examples using this context.

Embodiments of the present disclosure include methods, systems, and computer program products that enable a user of a computing system to select from a set of different operating system configurations and ensure that the selected configuration has not been modified, changed, or otherwise tampered with prior to being launched on the computing system. Embodiments disclosed herein provide advantages in security, access flexibility, and computing system management.

Embodiments of the present disclosure are based on the recognition that: the secure boot technique may be extended or otherwise enhanced using the techniques described herein to, among other things, ensure the authenticity of an operating system configuration, selected from a set of operating system configurations stored on a computing system in a pre-boot environment. Secure boot techniques, such as unified extensible firmware interface secure boot (hereinafter "UEFI secure boot"), enhance the security of a computing system in a pre-boot environment by preventing execution of unprotected computer executable code (hereinafter "code") prior to booting the operating system. In one example, during manufacture of a technical system, a secure boot technique stores a set (e.g., one or more) of public keys in a set of asymmetric key pairs (e.g., public-private key pairs) in a set of variables in protected non-volatile memory of a computing system. Each application (e.g., computer program) that is approved (or authorized) for execution on the computing system is signed using a private key that has a corresponding public key in a stored set of public keys. Before executing the application when the computing system is in a pre-boot state, the trusted application verifies executable code integrity of the application to be executed by verifying whether the application is digitally signed using a private key corresponding to one of a stored set of public keys. One problem with this secure boot technique is that a set of authorized signers (or a set of private keys) is determined prior to or at the time of manufacture of the computing system. For example, securely enabling a new operating system by a computing system may require having one of a set of predetermined authorized signers digitally sign the operating system prior to deploying it to the computing system.

Secure launch techniques may provide a set of trusted applications to enable an end user to add additional public keys to authenticate applications that may be launched to a computing system. For example, UEFI secure launch provides "mokutil", "shim", and "grub" applications to enable a user to add a public key to a set of public keys provided during manufacture. A user logged into an operating system that is launched on a computing system where a new public key is to be added (e.g., corresponding to a new operating system kernel image (image) to be added to the computing system) executes mokutil to provide the new public key. The mokutil application writes the new public key to non-volatile memory, which can only be accessed by shim the next time the computing system is started. The shim application may be a trusted application embedded in, for example, protected memory of the computing system. Additionally, the computing system may be configured to ensure that shim is the first application to execute after the computing system is restarted. The next time the computing system is restarted, the UEFI secure boot system will verify and execute the shim application after the update by mokutil. The shim application then reads the non-volatile memory area written by mokutil to determine if a new public key is stored. In response to detecting the new public key, shim may prompt the user at the local console to confirm whether the new public key should be submitted to the collection or database of stored public keys. If the user does not provide a positive confirmation, shim erases (or deletes) the new public key. Alternatively, when the user provides a positive confirmation, shim moves the new public key to another area of non-volatile memory dedicated to grub (e.g., a database storing all accepted public keys) by invoking the shim application. Thereafter, the new public key may be used to verify the new kernel image.

To securely launch the operating system kernel, shim authenticates and executes grub after submitting any new keys to the computing system. grub uses its configuration file to determine the kernel image to be booted. After identifying the operating system kernel to be booted, the grub authenticates and boots the kernel image by invoking the shim application to verify whether the kernel image is signed by a private key corresponding to a public key stored in a public key database of the computing system. Once started, the operating system kernel can similarly authenticate kernel modules as they are requested to be loaded onto the computing system.

These secure boot techniques may enable a user to load a new operating system on a provided computer system (the user may have access to a properly signed version of the operating system) and maintain a public key corresponding to the private key used to sign the operating system. However, known secure boot techniques do not enable a user to select an operating system configuration from a set of operating system configurations stored on a computing system to boot on the computing system. Furthermore, known secure boot techniques do not enable the computing system to ensure that a selected operating system configuration is booted without being modified or otherwise tampered with.

Embodiments of the present disclosure provide methods, systems, and computer program products that improve upon known secure boot techniques by: the method includes receiving a request to launch an operating system configuration from a set of operating system configurations that are digitally signed by a private key of an asymmetric key pair and stored on the system, automatically providing a public key of the asymmetric key pair to a trusted application configured to update a protected public key database, verifying the request to load the operating system configuration using the user's actual presence in the computing system, and authenticating and launching the operating system configuration.

As used herein, a trusted application is an application whose executable code is authenticated or otherwise guaranteed to not be changed by a party without authorization to change the code. The executable code may be authenticated using known digital signature and verification techniques. For example, executable code may be signed by encrypting the code using a private key of an asymmetric key pair. The integrity of the code may then be authenticated by verifying the signature of the signed code using the public key of the asymmetric key pair. Verification fails when the signature of the signed code cannot be verified due to, for example, changes to the signed code after signing.

As used herein, a key database may be an area of protected memory configured to store a set of digital keys (e.g., public keys in asymmetric key pairs). The protected memory may be memory that is accessible (e.g., readable or writable) only by the trusted application or a selected group of applications.

As used herein, a pre-boot state of a computing system may be a state of the computing system after the computing system reboots and before the computing system boots an operating system. The boot state of the operating system is the state of the computing system after the operating system is booted on the computing system.

As used herein, an operating system configuration may be a data object having a bootable operating system kernel image (hereinafter referred to as an "operating system kernel" or "kernel") and a set of associated one or more kernel parameter values (e.g., parameter values). In some embodiments, the kernel parameter values may be hard-coded (e.g., compiled into executable code of the operating system kernel) fixed command line parameter values. Hard coding the core parameter values may include providing the parameter values to a compiler using one or more compiler options when compiling the operating system core. Hard coding the kernel parameter values may additionally include compiling the operating system kernel using a compilation option that prevents a boot loader or other application from overwriting the hard coded kernel parameter values. In some embodiments, the kernel parameter values may be provided in a data object separate from the operating system kernel.

A data object as used herein may be a single kernel image. The data object may also be a data structure having an operating system kernel and a set of additional data objects. Signing the operating system may include signing the data object and/or each component of the data object.

Initiating operating system configuration on a computing system in which kernel parameters are hard coded may include: passing the operating system kernel to a boot loader, and causing the boot loader to load and execute the operating system kernel on the computing system. Similarly, initiating an operating system configuration in which one or more kernel parameter values are stored in a data object separate from the operating system kernel may include: passing both the operating system kernel and the one or more kernel parameter values to the bootloader and causing the bootloader to load and execute the operating system kernel using the one or more kernel parameter values.

For a given operating system kernel, the operating system configuration may be characterized by the enforcement of access control policies. This may be referred to as a configured security level. For example, a computing system may have a security enhanced Linux (SELinux) module installed with, among other things, a security enhanced Linux (SELinux) module for executing access control policies

Distribution of kernels. Continuing with this example, the computing system may also be configured to support three types of operating system configurations (e.g., security levels): low, medium and high. The Linux kernel that is booted using low configuration may disable SELinux and prevent execution of the access control policy, while the Linux kernel that is booted using configuration may put SELinux in a permission or debug mode to monitor but not execute the access control policy. Furthermore, Linux kernels that are booted using high configuration may enable SELinux in execution mode to enforce access control policies when booting a computing system. Thus, the example computing system may support three different operating system configurations, each having a Linux kernel and an associated SELinux module compiled using, for example, kernel parameter values set to enable a particular access policy enforcement or security level.

Referring now to the drawings, FIG. 1 illustrates a flowchart 100 of a set of computer-implemented operations for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments. As described herein, the operations of flowchart 100 may be performed by a computing system configured to securely launch an application. In some embodiments, the computing system may be computer 305 (FIG. 3) or computing device 600 (FIG. 6). In certain embodiments, a computing system may include one or more computing nodes or computing devices. The various operations depicted in flowchart 100 may be performed using software, firmware, and hardware components of a computing system. These components, including the entire computing system, are collectively referred to herein as a computing system. Each of the operations illustrated in flowchart 100 may be performed automatically by a computing system or in response to one or more events (e.g., user actions or requests).

The computing system may perform operation 105 to receive a request to initiate configuration of an operating system. The request may be received from a remote user interface terminal (e.g., a user interface terminal coupled to the computing system via, for example, a data communication network). The request may also be received from a local user interface terminal (e.g., a user interface terminal physically connected to the computing system). A user submitting a request or otherwise interacting with a computing system using a local user interface terminal is required to be physically present in the computing system, or so close to the computing system that he can assume that he actually owns the computing system.

As described herein, the computing system may perform operation 110 to store a digital key for authenticating the requested operating system configuration. The digital key may be a public key of an asymmetric key pair, with a corresponding private key used to sign the requested operating system configuration. In an embodiment, the digital key may be stored in non-volatile memory. Non-volatile memory may include, but is not limited to, permanent Random Access Memory (RAM), FLASH memory, system memory. In some embodiments, the computing system may be configured to automatically check the non-volatile memory for the digital key after reboot.

The computing system may perform operation 115 to restart the computer system. In some embodiments, the computing system may be automatically restarted in response to performing operation 110. In various embodiments, a computing system may be restarted in response to receiving a restart request from a user interface terminal.

While the computing system is in the pre-boot state, the computing system may send a request to the user on the local user interface terminal to confirm the request to boot the requested operating system configuration. The computing system may then perform operation 120 to receive a signal from the local user interface terminal confirming the request to initiate the requested operating system configuration. Performing operation 120 may ensure that a user requesting a change to an operating system configuration initiated on the computing system (e.g., a possible change to an access control policy enforcement or security level) has physical access to the computing system. This operation may limit the possibility of an unauthorized user remotely changing the access control policy enforcement or security level of the computing system.

While still in the pre-boot state, the computing system may perform operation 125 to authenticate the requested operating system configuration using the digital key. The computing system may then perform operation 130 to initiate the requested operating system configuration.

In some embodiments, the computing system may verify (e.g., validate) or determine that the digital key stored in operation 115 corresponds to an operating system configuration authorized to be booted on the computing system in response to the reboot. Verification may include determining whether an operating system configuration stored on the computing system and authorized to be executed is signed by a private key corresponding to the digital key. The verification operation helps ensure the integrity of the pre-boot environment and the boot system by ensuring that only known or approved configurations are considered for boot.

In some embodiments, the computing system may move the digital key to the protected memory in response to receiving the confirmation in step 120. For example, the storage system may move the digital key to a key database or repository that is writable only by a particular trusted (e.g., secure or authenticated) application. These embodiments may provide the benefits of existing architectures that utilize secure boot techniques to enable trusted applications to verify the validity and authenticity of requested operating system configurations. This also enables the computing system to initiate the requested operating system configuration after a reboot without requiring the user to access the local user interface terminal.

In some embodiments, the protected memory (e.g., at the key database) is writable only by the software application, and the integrity of its executable code is authenticated by the hardware components of the computing system (e.g., using a digital key stored in the protected memory). These embodiments may provide the benefit of performing authentication of a requested operating system configuration by limiting the number of parties that may add new keys and possibly unauthorized keys to a computing system.

In some embodiments, authenticating the requested operating system configuration comprises: retrieving the digital key from the protected memory and using the retrieved key to verify the signature of the requested operating system configuration. These embodiments may provide the benefits of existing architectures that utilize secure boot techniques to ensure that operating system configurations are not modified prior to booting the configuration.

According to various embodiments, the operating system configuration requested in operation 105 may include an operating system kernel and a set of kernel parameter values for performing access control policy enforcement, or a security level (e.g., an access control policy), of the operating system kernel. As described herein, in some embodiments, the set of kernel parameter values is compiled into executable code of the operating system kernel.

FIG. 2 depicts a flowchart of an example of a set of computer-implemented operations for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments. As described herein, the operations of flowchart 200 may be performed by a computing system configured to securely launch an application. Each of the operations illustrated in flowchart 200 may be performed automatically by a computing system or in response to one or more events (e.g., user actions or requests).

The computing system may perform operation 205 by, for example, generating a set of operating system configurations that can be launched on the computing system. The operating system configuration may include an operating system kernel and a set of kernel parameter values. The kernel parameter values may configure the access control policy enforcement level (or security level) of the associated operating system kernel. Each configuration may also be digitally signed with a different private key, for example, in an asymmetric public-private key pair, to ensure executable code integrity for the operating system configuration. The public key corresponding to each private key may also be stored on the computing system.

The computing system may perform operation 210 to receive a request to launch a selected operating system configuration (e.g., a launch request). As described herein, the request may be received from a remote user interface terminal or a local user interface terminal.

At operation 215, the computing system may store a digital key (e.g., a public key) associated with a private key used to sign the requested operating system configuration. As described herein, the digital key may be stored in a non-volatile memory of the computing system. In some embodiments, the computing system may additionally update the configuration (e.g., configuration file) of the boot loader to cause the boot loader to launch the requested operating system configuration the next time the computing system is restarted.

At operation 220, the computing system may be restarted (e.g., restarted). Then, as described herein, the computing system may perform the following operations while the computing system is in a pre-boot state.

At operation 225, the computing system may verify the digital key to determine whether the digital key corresponds to a known (e.g., stored) operating system configuration that is authorized to be booted on the computing system, as described herein. The computing system may proceed to operation 230 when the public key is verified, or, in response to determining that the requested operating system configuration cannot be verified, the computing system may proceed to operation 250.

At operation 230, the computing system may acknowledge the request to initiate the requested operating system configuration. Performing operation 230 may include prompting the requesting user at the local user interface terminal to confirm the request to initiate the requested operating system configuration. The computing system may then receive an acknowledgement signal or message from the local user interface terminal. The received confirmation signal may comprise any electronic signal, including a voltage or a set of digital characters. The received acknowledgement signal may be a positive acknowledgement or a negative acknowledgement. When the received acknowledgement signal is a positive acknowledgement, the computing system may continue with operation 235, and when the received acknowledgement signal is a negative acknowledgement, the computing system may proceed to operation 250. Additionally, in response to receiving the positive acknowledgement, the computing system may move the digital key to protected memory (e.g., as an alternative to performing operation 235), as described herein.

At operation 235, the computing system may move the digital key to a protected memory of the computing system, as described herein. In some embodiments, the calculation may perform operation 235 before performing operation 230.

At operation 240, the computing system may retrieve or read the digital key from the protected memory and use it to authenticate the system configuration for the requested operation, as described herein. Authenticating the requested operating system configuration may include: determining that the requested operating system configuration was not modified after signing the requested operating system configuration with the private key. When the requested operating system configuration is trusted, the computing system may continue to operate 245, and when the requested operating system configuration is not trusted, the computing system may continue to operate 250.

At operation 245, the computing system may initiate the requested operating system configuration, as described herein. The computing system may end the operations of flowchart 200 at operation 255.

At operation 250, the computing system may delete or erase the digital key from the non-volatile memory and/or the protected memory. The computing system may then provide an indication that the requested operating system configuration cannot be launched. In some embodiments and in response to reaching operation 250 from other operations (e.g., operations 225,235, and 240), the computing system may not delete the private key. In these embodiments, the computing system may abort the boot process by providing an indication that the requested operating system configuration cannot be booted.

FIG. 3 illustrates a block diagram of an example system 300 for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments. As described herein, the system 300 may be a computing system configured to perform the operations of the present disclosure. The system 300 includes a computing device 305 and a local user interface 380 (e.g., a local user interface terminal). In some embodiments, the system 300 may include a remote user interface 370 (e.g., a remote user interface terminal) and a data communication network 375.

Computing device 305 may include a processor 310, memory 315, storage 320, and security component 325. As described herein, computing device 305 may be a computing device configured to securely load a selected operating system configuration. The processor 310 may execute applications loaded into the memory 315, including a user application 330 and a trusted application 360.

Storage 320 may be a storage device, such as storage device 628 (FIG. 6). Storage 320 may store application programs for execution on computing device 305 including operating system configurations. The storage device may store, for example, user application 330, boot loader 335, operating system configuration A340, and operating system configuration B345.

User application 330 may be a software application executable by a user logged into computing device 305. In some embodiments, the user application 330 may be substantially identical and may perform the same operations as the user application discussed in FIG. 4. For example, user application 330 may be executed to enable a user to send a request to change an operating system configuration on computing device 305. In some embodiments, the user application 330 may be executed to update the configuration of the bootloader 335, as described herein.

The boot loader 335 may be a software application that is authorized to execute on the computing device 305 to initiate operating system configurations, such as operating system configuration A340 and operating system configuration B345. In some embodiments, the boot loader 335 may be signed by the private key of a public-private key pair to ensure the integrity of its executable code. After restarting the computing device 305, the bootloader 335 may be executed by a trusted application (e.g., trusted application 360) to authenticate and launch a preselected operating system configuration based on the configuration of the bootloader.

Operating system configuration A340 and operating system configuration B345 may be two different bootable operating system configurations stored on computing device 305. As described herein, each operating system configuration may be signed and may include an operating system kernel and a set of associated kernel parameter values. In some embodiments, operating system configuration A340 and operating system configuration B345 may have the same operating system kernel and different sets of kernel parameter values. In some embodiments, operating system configuration A340 and operating system configuration B345 may have different operating system kernels and similar kernel parameter values (e.g., kernel parameter values may ensure that each configuration is launched to have the same access policy execution level).

The security component 325 may include hardware and software components to ensure the integrity or authenticity of the executable code of an application program launched on the computing device 305. In some embodiments, the security component 325 may include user accessible non-volatile memory 350, protected non-volatile memory 355, trusted applications 360, and a database 365. Although illustrated as separate components, all or part of the security component 325 may be included in one or more other components of the computing device 305.

As described herein, the user-accessible non-volatile memory 350 may be any non-volatile memory for write access by at least applications executable by a user of the computing device 305. User accessible non-volatile memory 355 may be, for example, battery backed random access memory, flash memory or a region on storage 320. In some embodiments, as described herein, user-accessible non-volatile memory may be used as a staging area for temporarily storing a public key corresponding to an operating system configuration selected for booting on computing device 305.

The protected non-volatile memory 355 may be an area of non-volatile memory that is accessible only by a selected set of applications (e.g., the trusted application 360 and the boot loader 335). In some embodiments, the memory 355 may be written only by the trusted application 360 and only during a pre-boot state of the computing device 305. In some embodiments, the protected non-volatile memory 355 stores a set or database of verified public keys for authenticating applications that may be launched on the computing device 305.

The trusted application 360 may be an application having executable code that is authenticated by the computing device 305 and configured to automatically execute upon reboot of the computing device 305. In some embodiments, the trusted application 360 may be configured to automatically check and verify the validity of a new public key stored at a predetermined location in the user accessible non-volatile memory 350. The trusted application 360 may also be configured to perform the operations of the trusted application discussed herein.

Database 365 may be a repository of public keys used to authenticate applications that may be launched on computing device 305. In some embodiments, database 365 may be part of protected non-volatile memory 355. In certain embodiments, one or more public keys stored in database 365 may be written and digitally signed during manufacture of computing device 305.

Local user interface 380 may be a user interface terminal configured to enable a user to perform input and output operations with respect to computing device 305. Local user interface 380 may be physically connected to computing device 305 through a connection (e.g., a data cable, video cable, or other input-output cable or bus). According to various embodiments, the local user interface 380 may enable interaction between the trusted application 360 and a user who actually owns the computing device 305 or who actually exists in the computing device 305.

FIG. 4 illustrates a flowchart 400 of a set of computer-implemented operations for securely launching an operating system configuration selected by a user from a set of operating system configurations using hardware and software, in accordance with various embodiments. As described herein, the operations of flowchart 400 may be performed by a computing device configured to securely launch an application. Each of the operations illustrated in flowchart 400 may be performed automatically by a computing device or in response to one or more events (e.g., user actions or requests).

At operation 405, the computing device may receive a request from a user application executing under a first operating system configuration (O/S configuration A) to initiate a second operating system configuration (O/S configuration B). The request may be received from any terminal or device that enables a user to access the computing device and execute the user application. In some embodiments, a user may access a computing device and execute a user application using a set of credentials (e.g., a username and password associated with an authorized user account).

Operating system configuration B may include an operating system kernel having a set of kernel parameter values, as described herein. Operating system configuration B may be signed by a private key of a public-private key pair (e.g., an asymmetric key pair). In some embodiments, O/S configuration B may include the same operating system kernel as included in O/S configuration A. However, O/S configuration B may have a different set of core parameter values than the set of core parameter values included in O/S configuration A. Reviewing the operating system configuration example discussed above, both O/S configuration A and O/S configuration B may include a Linux kernel with a SELinux module. However, O/S configuration A may include kernel parameter values that launch the Linux kernel with a high access control execution security level, while O/S configuration B may include kernel parameter values that launch the Linux kernel with a medium access control execution security level.

At operation 410, the computing device may store in non-volatile memory a public key corresponding to a private key used to sign O/S configuration B, as described herein. In some embodiments, the user application or another application may cause the computing device to perform operation 410.

At operation 415, the computing device may be restarted. After the reboot, the computing device may perform operations 425 and 430 in a pre-boot state according to operation 420.

At operation 425, the computing device may execute a trusted (e.g., secured or guaranteed to be unmodified) application to receive a signal confirming the request to initiate O/S configuration B. In some embodiments, the trusted application may be substantially similar to the UEFI shim program. The computing system may be configured to automatically load, authenticate, and execute the trusted application after the computing system reboots. The trusted application may be configured to read a particular region of non-volatile memory (e.g., the region of non-volatile memory written in operation 410) to determine whether a new public key is added to the computing system. The trusted application may also be configured to verify that the public key corresponds to a known operating system configuration (e.g., an operating system configuration authorized to be launched on the computing system) in response to detecting the new public key. In response to verifying the public key, the trusted application may copy, transfer, or move the public key to protected memory of the computing device, as described herein. In some embodiments, the protected memory may only be written to by trusted applications. Further, the protected memory can only be written to when the computing device is in a pre-boot state.

At operation 430, the computing device may execute a boot loader to authenticate and boot the O/S configuration B. In some embodiments, a trusted application may load, authenticate, and then execute a boot loader on behalf of a computing system. The authenticated boot loader may read the public key from protected memory and use it to authenticate O/S configuration B prior to boot. When the authentication is successful, the boot loader may boot the O/S configuration B, and when the authentication is unsuccessful (e.g., when the boot loader detects that the O/S configuration B was altered after signing), the boot loader may abort the boot process.

The operations of flowchart 400 may end at operation 435.

In some embodiments, the set of kernel parameter values in O/S configuration B determines the software modules that are loadable when O/S configuration B is booted on the computing system. Additionally, in various embodiments, the set of parameter values may determine enforcement of access control permissions (e.g., access control policy enforcement levels) under the O/S configuration B. These embodiments provide the following advantages: as described herein, it is ensured that the configuration and access control policies of a computing system cannot be changed by a user using the computing system unless the user has physical access to the computing system and the integrity of the operating system configuration selected for changing the computing system is authenticated.

According to various embodiments, as described herein, the protected non-volatile memory is readable and writable only by a set of applications (including trusted applications), whose executable code integrity is certified by a hardware component of the computing system. These embodiments provide the advantage of ensuring that unauthorized public keys cannot be added to a computing system. This in turn reduces the likelihood that an unauthorized operating system configuration can be launched on the computing system.

FIG. 5 depicts an interaction diagram 500 of interactions between a user and a computing system that performs a set of computer-implemented operations for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments. Interaction diagram 500 illustrates interactions between a user 505 and elements of a computing system configured to securely initiate operating system configuration as described herein. The components of the interaction graph include a user 505, an execution environment 510 of the computing system, and a system state 515 of the computing system. The execution environment 510 may be an operating system configuration A525 that executes user applications 530, a trusted application 550, a boot loader 560, and an operating system configuration B570. The system state 515 as used in the context of FIG. 5 indicates the target of the operation: non-volatile data stored on a computing device is read or modified. The user 505 may interact with the execution environment 510 through a user interface 520 (e.g., a local or remote user interface terminal) or through a local user interface 545 (e.g., when the user has physical access to the computing system).

As illustrated by reference element 535, the first set of interactions may be performed when operating system configuration A (O/S configuration A) is launched on the computing system.

According to various embodiments, user application 530 may receive a request 531 to load operating system configuration B (O/S configuration B). Request 531 may be received from user 505 through user interface 520. User application 530 may then perform a set of operations 532 to store the public key associated with the private key used to sign O/S configuration B. The public key may be stored in a non-volatile memory of the computing system. User application 530 may further perform operation 533 to update the configuration of the boot loader of the computing system to boot O/S configuration B after the next reboot of the computing system. The O/S configuration A may then receive a request to restart the computing system 534.

The computing system may then restart, as illustrated by reference element 540.

The following interactions are performed with the computing system in a pre-boot state, as illustrated by reference element 565.

According to various embodiments, the trusted application 550 performs operation 551 to retrieve the stored public key from non-volatile memory and verify (e.g., certify) that the retrieved public key corresponds to a known (e.g., valid) signed operating system configuration. The trusted application 550 may also perform operation 552 to prompt the user 505 through the local user interface terminal 545 to confirm the request to initiate the O/S configuration B. The trusted application 550 may then perform operation 553 to receive an acknowledgement from the user 505. The trusted application may further perform operations 554 and 555 to move the public key to protected memory and authenticate and execute the boot loader 560. The boot loader 560 may perform operations 561 and 562 to retrieve the public key from protected memory and authenticate and boot the O/S configuration B. In some embodiments, the boot loader 560 may cause the trusted application 550 to perform operations 561 and 562 and, upon successful authentication (or verification), start the O/S configuration B570.

The computing system may then enter a boot state in O/S configuration B, as shown by reference element 575.

FIG. 6 illustrates a block diagram of a computing device 600 having hardware and software components for securely launching an operating system configuration selected from a set of operating system configurations using hardware and software, in accordance with various embodiments.

The components of computing device 600 may include one or more processors 606, memory 612, a terminal interface 618, a storage interface 620, an input/output ("I/O") device interface 622, and a network interface 624, all of which are communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 610, an I/O bus 616, a bus interface unit ("IF") 608, and an I/O bus interface unit 614.

Computing device 600 may include one or more general-purpose programmable Central Processing Units (CPUs) 606A and 606B, collectively referred to herein as processor 606. In one embodiment, computing device 600 may contain multiple processors; however, in another embodiment, computing device 600 may instead be a single CPU device. Each processor 606 executes instructions stored in memory 612.

Computing device 600 may include a bus interface unit 608 to handle communications between processor 606, memory 612, display system 604, and I/O bus interface unit 614. The I/O bus interface unit 614 may be coupled to the I/O bus 616 for transferring data to and from various I/O units. The I/O bus interface unit 614 may communicate with multiple I/O interface units 618,620,622 and 624, which may also be referred to as I/O processors (IOPs) or I/O adapters (IOAs), through the I/O bus 616. The display system 604 may include a display controller, a display memory, or both. The display controller may provide video, audio, or both types of data to the display device 602. The display memory may be a dedicated memory for buffering video data. Display system 604 may be coupled to display device 602, such as a stand-alone display screen, a computer monitor, a television, a tablet or handheld device display, or other displayable device. In one embodiment, the display device 602 may include one or more speakers for presenting audio. Alternatively, one or more speakers for presenting audio may be coupled to the I/O interface units. In an alternative embodiment, one or more of the functions provided by display system 604 may be an onboard integrated circuit that also includes processor 606. Further, one or more of the functions provided by the bus interface unit 608 may be an on-board integrated circuit that also includes the processor 606.

The I/O interface units support communication with various storage and I/O devices. For example, terminal interface unit 618 supports the attachment of one or more user I/O devices, which may include user output devices (e.g., a video display device, speakers, and/or a television) and user input devices (e.g., a keyboard, mouse, keypad, touchpad, trackball, buttons, light pen, or other pointing device). A user may manipulate user input devices using the user interface to provide input data and commands to user I/O device 626, and computing device 600 may receive output data via user output devices. For example, a user interface may be presented via the user I/O device 626, e.g., displayed on a display device, played through a speaker, or printed via a printer.

The storage interface 620 supports the attachment of one or more disk drives or direct access storage devices 628 (which are typically rotating disk drive storage devices, although they could alternatively be other storage devices, including arrays of disk drives configured to appear as a single large storage device to a host, or a solid state drive such as flash memory). In another embodiment, the storage device 628 may be implemented by any type of secondary storage device. The contents of the memory 612, or any portion thereof, may be stored to the storage device 628 and retrieved from the storage device 628 as needed. I/O device interface 622 provides an interface to any of a variety of other I/O devices or other types of devices (e.g., printers or fax machines). Network interface 624 provides one or more communication paths from computing device 600 to other digital devices and computer systems.

The security component 631 may be substantially similar to the security component 325 (fig. 3) and include the same functionality as the security component 325. The security component 631 may include hardware and software components for ensuring the integrity or authenticity of executable code of applications launched on the computing device 600.

Although the computing device 600 illustrated in FIG. 6 shows a particular bus structure providing a direct communication path among the processor 606, the memory 612, the bus interface 608, the display system 604, and the I/O bus interface unit 614, in alternative embodiments, the computing device 600 may include different buses or communication paths, which may be arranged in any of various forms, such as point-to-point links with hierarchical, star or mesh configurations, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Moreover, although the I/O bus interface unit 614 and the I/O bus 608 are shown as single respective units, the computing device 600 may include multiple I/O bus interface units 614 and/or multiple I/O buses 616. Although multiple I/O interface units are shown, which separate I/O bus 616 from various communications paths running to the various I/O devices, in other embodiments some or all of the I/O devices are connected directly to one or more system I/O buses.

In various embodiments, computing device 600 is a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface, but receives requests from other computer systems (clients). In other embodiments, computing device 600 may be implemented as a desktop computer, portable computer, laptop or notebook computer, tablet computer, pocket computer, telephone, smart phone, or any other suitable type of electronic device.

In one embodiment, the memory 612 may include a random access semiconductor memory, storage device, or storage medium (volatile or non-volatile) for storing or encoding data and programs. In another embodiment, the memory 612 represents the entire virtual memory of the computing device 600, and may also include the virtual memory of other computer systems coupled to the computing device 600 or connected via the network 630. The memory 612 may be a single monolithic entity, but in other embodiments the memory 612 may include a hierarchy of caches and other memory devices. For example, memory may exist in multiple levels of caches, and these caches may be further divided by function, so that one cache holds instructions while another holds non-instruction data for use by the processor. Memory 612 may further be distributed and associated with different CPUs or different sets of CPUs, as is known in any of various so-called non-uniform memory access (NUMA) computer architectures.

Memory 612 may store all or a portion of the components and data shown in fig. 1-5. In particular, one or more of a user application, a trusted application, a boot loader, and an operating system configuration may be loaded from the storage device 628 or the security component 631 into the memory 612 to be authenticated and executed to perform the operations described herein. The computer executable code may be executed by processor 606. Some or all of the components or data shown in fig. 1-5 may be on different computer systems and may be accessed remotely, e.g., via network 630. The computing device 600 may use virtual addressing mechanisms that allow the programs of the computing device 600 to behave as if they only have access to a large, single storage entity instead of access to multiple, smaller storage entities. Thus, although the components and data illustrated in FIGS. 1-5 are shown as being included in memory 612, these components and data are not necessarily all completely contained in the same storage device at the same time. Although the components and data shown in fig. 1-5 are shown as separate entities, in other embodiments some of them, portions of some of them, or all of them may be packaged together.

In one embodiment, the components and data shown in FIGS. 1-5 may include: instructions or statements executed on processor 606, or instructions or statements interpreted by instructions or statements executing processor 606 to perform functions as further described below. In another embodiment, the components shown in FIGS. 1-5 may be implemented in hardware via semiconductor devices, chips, logic gates, circuits, circuit cards, and/or other physical hardware devices in lieu of or in addition to processor-based systems. In one embodiment, the components shown in FIGS. 1-5 may include data in addition to instructions or statements.

Fig. 6 is intended to illustrate representative components of computing device 600. However, the individual components may have greater complexity than presented in FIG. 6. In fig. 6, the number, type, and configuration of these components may vary from or in addition to those shown, which may be present. Several particular examples of additional complexity or additional variations are disclosed herein; these are merely examples and are not necessarily the only such variations. In various embodiments, the various program components described as being included in FIG. 6 may be implemented in a number of different manners, including using various computer applications, routines, components, programs, objects, modules, data structures, etc., which may be referred to herein as "software," computer programs, "or simply" programs.

The present invention may be a system, method and/or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions embodied therewith for causing a processor to implement various aspects of the present invention.

The computer readable storage medium may be a tangible device that can hold and store the instructions for use by the instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, such as punch cards or in-groove projection structures having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a respective computing/processing device, or to an external computer or external storage device via a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing/processing device.

Computer program instructions for carrying out operations of the present invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine related instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present invention are implemented by personalizing an electronic circuit, such as a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA), with state information of computer-readable program instructions, which can execute the computer-readable program instructions.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable medium storing the instructions comprises an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein were chosen in order to best explain the principles of the embodiments, the practical application, or technical improvements to the techniques in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.