Method for starting a computing device and system for starting a node
By executing instructions on the hardware processor of the computing device and forcing the computing device to comply with its reference operating status, the problem of difficulty in managing and controlling the startup and operation status of the computing device in the existing cloud computing system is solved, and the status management and control of the computing device is realized, and the security and stability of the system are improved.
Patent Information
- Application Number
- CN202211320155.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2022-04-28
- Filing Date
- 2022-10-26
- Publication Date
- 2025-03-07
- Estimated Expiration
- 2042-10-26
AI Technical Summary
It is difficult for existing cloud computing systems to effectively manage and control the up and running status of computing devices, especially in multi-node and multi-tenant environments, to ensure that computing devices comply with reference operating status to ensure security and stability.
By executing instructions on the hardware processor of the computing device, the computing device is forced to comply with its reference operating state, including determining a comparison of the actual computing state with the reference operating state, and in response to the verification result, controlling whether the computing device is joined to a cloud-based computing system, and whether it complies with the reference operating state in a hot plug or hot-unplug event.
The state management and control of the computing device during startup and operation is realized, ensuring that the computing device always complies with the predetermined state, improving the security and stability of the system, and preventing unauthorized state modifications and potential security vulnerabilities.
Smart Images

Figure CN117009282B_ABST
Abstract
Description
Technical Field
[0001] The present disclosure generally relates to enforcing cloud-based computing devices to comply with a reference operating state. Background Art
[0002] A cloud architecture may include a computer system domain of multiple physical server nodes (e.g., blade servers or rack-mounted servers) or "computing devices." The computing devices define a physical infrastructure domain. The physical infrastructure domain may be managed by a central management system that orchestrates software-defined logical infrastructure and services (e.g., software-defined computing (SDC) services, software-defined storage (SDS) services, and software-defined networking (SDN) services) hosted on the computing devices. The software-defined logical infrastructure relies on an abstract infrastructure layer (e.g., a hypervisor for virtual machine (VM) abstraction or an OS for container abstraction) to provide central management system control of services. Summary of the invention
[0003] According to a first aspect of the present disclosure, a method for starting a computing device is provided, comprising: at least one hardware processor of the computing device executes instructions to force the computing device to comply with a reference operating state of the computing device, wherein the computing device is part of a cloud-based computing system, and forcing compliance with the reference operating state includes, in response to the startup of the computing device: determining, by the computing device, an actual computing state of the computing device, wherein the actual computing state includes an actual physical topological arrangement of hardware components of the computing device, determining the actual computing state includes determining the physical topological arrangement of the hardware components, the computing device includes multiple physical locations in which the hardware components can be installed, and determining the physical topological arrangement of the hardware components includes identifying a specific physical location among the multiple physical locations; verifying that the actual computing state complies with the reference computing state of the computing device, wherein the verification includes converting the actual computing state into a physical topological arrangement of the hardware components; The computing state is compared with the reference computing state, and comparing the actual computing state with the reference computing state includes comparing the specific physical location with the physical location of the reference computing state; in response to the result of the verification, the computing device controls whether the computing device is part of the cloud-based computing system, including allowing the computing device to become part of the cloud-based computing system; and in response to the result of the verification, the computing device controls whether the computing device sets up a cloud tenant runtime environment, wherein the method also includes: in response to a hot plug event or a hot unplug event associated with the computing device when the computing device is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference computing state; and in response to determining whether the hot plug event or the hot unplug event complies with the reference computing state, controlling whether the computing device remains part of the cloud-based computing system.
[0004] According to a second aspect of the present disclosure, a method for starting a computing device is provided, comprising: at least one hardware processor of the computing device executes instructions to force the computing device to comply with a reference operating state of the computing device, wherein the computing device is part of a cloud-based computing system, and forcing compliance with the reference operating state includes, in response to the startup of the computing device: determining, by the computing device, an actual computing state of the computing device, wherein the actual computing state includes an actual physical topological arrangement of hardware components of the computing device, determining the actual computing state includes determining the physical topological arrangement of the hardware components, the computing device includes a plurality of physical locations in which the hardware components can be installed, and determining the physical topological arrangement of the hardware components includes identifying a specific physical location among the plurality of physical locations; verifying that the actual computing state complies with the reference computing state of the computing device, wherein the verification includes comparing the actual computing state with the reference computing state, and comparing the actual computing state with the reference computing state. The actual computing state is compared with the reference computing state, including comparing the specific physical location with the physical location of the reference computing state; and in response to the result of the verification, controlling by the computing device whether the computing device is part of the cloud-based computing system, including allowing the computing device to become part of the cloud-based computing system; wherein determining the actual computing state includes: determining a component inventory of the computing device, wherein determining the component inventory includes determining a first identifier of the hardware component; and determining a composite identifier of the hardware component based on the physical topological location and the first identifier, wherein the method further includes: in response to a hot plug event or a hot unplug event associated with the computing device when the computing device is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference computing state; and in response to determining whether the hot plug event or the hot unplug event complies with the reference computing state, controlling whether the computing device remains part of the cloud-based computing system.
[0005] According to a third aspect of the present disclosure, a system for starting a node is provided, comprising: a connector for receiving an intelligent input / output (I / O) peripheral device, wherein the intelligent I / O peripheral device is used to provide I / O services associated with a cloud operator domain of a cloud-based computing system; and a node, wherein the node comprises at least one central processing unit (CPU), hardware components and a memory, wherein the at least one CPU is used to execute instructions associated with an application operating environment and associated with a cloud tenant domain, and the at least one CPU is used to execute instructions in response to the starting of the node: determining the node based on a physical topological arrangement of the hardware components and identifiers of the hardware components other than the physical topological arrangement the actual computing state of the node; verifying that the actual computing state complies with a reference computing state of the node, wherein the verification includes comparing the actual computing state with the reference computing state; and in response to a result of the verification, controlling whether the node is part of the cloud-based computing system, including allowing the node to become part of the cloud-based computing system, in response to a hot plug event or a hot unplug event associated with the node when the node is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference computing state; and in response to determining whether the hot plug event or the hot unplug event complies with the reference computing state, controlling whether the node remains part of the cloud-based computing system.
[0006] According to a fourth aspect of the present disclosure, a non-transitory storage medium is provided, the non-transitory storage medium being used to store machine-readable instructions, the machine-readable instructions causing the machine to perform the following operations when executed by a machine: accessing data representing an actual network infrastructure state associated with a computing device, wherein the actual network infrastructure state comprises a first address of a network access point associated with the computing device and a first physical location associated with the computing device; verifying that the actual network infrastructure state complies with a reference network infrastructure state of the computing device, wherein the verification comprises: verifying whether the first address is the same as an address specified by the reference network infrastructure state, and verifying whether the first physical location is the same as a physical location specified by the reference network infrastructure state; responding In response to the verification, controlling whether the computing device is permitted to join the cloud-based computing system, including allowing the computing device to become part of the cloud-based computing system; in response to a hot plug event or a hot unplug event associated with the computing device when the computing device is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference network infrastructure state; in response to determining whether the hot plug event or the hot unplug event complies with the reference network infrastructure state, controlling whether the computing device remains part of the cloud-based computing system; and determining a performance standard of a software defined network (SDN) connection associated with the computing device, wherein verifying the compliance includes comparing the performance standard with a reference standard of the reference network infrastructure state.
[0007] According to a fifth aspect of the present disclosure, a non-transitory storage medium is provided, the non-transitory storage medium being used to store machine-readable instructions, the machine-readable instructions, when executed by a machine, causing the machine to perform the following operations: accessing data representing an actual network infrastructure state associated with a computing device, wherein the actual network infrastructure state includes a first address of a network access point associated with the computing device and a first physical location associated with the computing device; verifying that the actual network infrastructure state complies with a reference network infrastructure state of the computing device, wherein the verification includes: verifying whether the first address is the same as the address specified by the reference network infrastructure state, and verifying whether the first physical location is the same as the physical location specified by the reference network infrastructure state; in response to the verification, Verify whether the computing device is permitted to join a cloud-based computing system, including allowing the computing device to become part of the cloud-based computing system; in response to a hot plug event or a hot unplug event associated with the computing device when the computing device is part of the cloud-based computing system, determine whether the hot plug event or the hot unplug event complies with the reference network infrastructure state; in response to determining whether the hot plug event or the hot unplug event complies with the reference network infrastructure state, control whether the computing device remains part of the cloud-based computing system; and determine a geographic location associated with a software defined storage (SDS) connection, the SDS connection being associated with the computing device, wherein verifying the compliance includes comparing the geographic location with a geographic reference standard of the reference network infrastructure state. BRIEF DESCRIPTION OF THE DRAWINGS
[0008] Figure 1 is a block diagram of a computing device that forces the computing device to comply with a reference computing state according to an example implementation.
[0009] Figure 2 According to an example implementation, Figure 1 An illustration of a process performed by a computing state verification engine of a computing device.
[0010] Figure 3 is an illustration of a process performed by a domain manager to enforce compliance of a network infrastructure associated with a computing device with a reference network infrastructure state according to an example implementation.
[0011] Figure 4 is a flow chart depicting a boot process for a computing device according to an example implementation.
[0012] Figure 5A is a flow chart of a process performed by a computing state validation engine of a computing device to determine an actual computing state of the computing device according to an example implementation.
[0013] Figure 5B is a flow chart of a process performed by a computing state verification engine of a computing device to verify that the computing device complies with a reference computing state according to an example implementation.
[0014] Fig. 6A is a flow chart of a process performed by a network infrastructure state validation engine to determine an actual network infrastructure state according to an example implementation.
[0015] Figure 6B is a flow chart of a process performed by a network infrastructure state validation engine to control whether a computing device joins a cloud-based computing system based on whether an actual network infrastructure associated with the computing device complies with a reference network infrastructure state, according to an example implementation.
[0016] Figure 7 is a flow chart of an interrupt service routine for responding to a hot plug / hot unplug event occurring in a computing device according to an example implementation.
[0017] Figure 8 is a flow chart depicting a process of forcing a computing device to comply with a reference operating state according to an example implementation.
[0018] Fig. 9 is a block diagram of a system for enforcing nodes to comply with a reference operating state according to an example implementation.
[0019] Fig.10 is an illustration of a machine-readable non-transitory storage medium storing instructions that, when executed by a machine, cause the machine to enforce network infrastructure compliance with a reference network infrastructure state according to an example implementation. DETAILED DESCRIPTION
[0020] A computer platform such as a server (e.g., a blade server or a rack-mounted server) may have an architecture that may be characterized as employing a "host-centric" control model (e.g., a traditional personal computer (PC)-based architecture or "traditional architecture"). In a host-centric control model, server controls are rooted in the server's host. As used herein, "host" refers to the portion of a server that includes a main central processing unit (CPU) and main system memory. Accordingly, the host provides functionality or services through the execution of machine-readable instructions by one or more main CPUs. Thus, server controls being rooted in the server's host means that the server controls are rooted in the server's main CPU.
[0021] The server may be a compute node of a cloud-based computing system or a "cloud-based computing system." The server's host's software layer may provide a logical infrastructure abstraction and control surface via a hypervisor software stack (for virtual machines (VMs)) and / or an operating system software stack (for containers). The result of this host-centric control model is the separation of management control of the compute node's physical infrastructure from the compute node's logical infrastructure.
[0022] The central management system of a cloud computer system can be built around a hierarchical management structure. At the lowest level of the hierarchical management structure, the computing node can be divided into two different control surfaces: a first control surface for the physical infrastructure of the computing node and a second control surface for the logical infrastructure of the computing node. Each of these infrastructures can be connected to its own central manager, so that there can be two distinct associated administrators: an administrator for the physical infrastructure and a virtualization administrator for the logical infrastructure. Accordingly, there can be two different central management software stacks, and at the top of the hierarchical management structure there can be a cloud infrastructure manager to unify the software stacks. The cloud infrastructure manager can replace the role of the traditional infrastructure administrator with the following different cloud roles: operator (for physical and logical infrastructure control), tenant (for abstract instance control), and infrastructure support technician (for support).
[0023] Cloud native architecture may look similar to traditional cloud architecture, but cloud native architecture is different in one important aspect. Cloud native architecture mixes physical and logical infrastructure by using intelligent input / output (I / O) subsystems (referred to herein as "intelligent I / O peripherals") for the purpose of offloading services from the host (i.e., offloading traditional processing performed by the host) and by isolating node management controls within the intelligent I / O peripherals. The mixing of physical and logical infrastructure changes the general nature of traditional architecture servers by utilizing independent software stacks that can be managed in segments (e.g., segments aligned with the SDC layer, the SDS layer, and the SDN layer). Therefore, such servers are referred to herein as segmented servers (or "segmented computing nodes"). This segmented control model brings challenges of orchestration and control sequencing to traditional architecture servers, which are related to ensuring that all independent managers are in a "ready state" before presenting the back-end I / O services provided by the intelligent I / O peripherals. This new orchestration and sequencing produces a more vertically integrated (i.e., tightly coupled or unified) architecture. While cloud-native architectures use a hierarchical control management domain structure, the result is a unified experience around three control roles: operators, tenants, and support technicians.
[0024] As used herein, "intelligent I / O peripherals" refer to devices or components of a server that provide one or more functions that have been controlled by the host in a traditional architecture. Typically, an intelligent I / O peripheral is a hardware processor that has been assigned (e.g., programmed) a specific personality. An intelligent I / O peripheral can provide one or more back-end I / O services (or "host offload services") according to its personality. Back-end I / O services can be non-transparent services or transparent services. An example of a non-transparent host service is a hypervisor virtual switch offload service that uses PCIe direct I / O (e.g., CPU input-output memory management unit (IOMMU) mapping of PCIe device physical functions and / or virtual functions) without host control. The host transparent back-end I / O service does not involve modifying the host software. As an example, transparent back-end I / O services may include network-related services such as encryption services, overlay network access services, and firewall-based network protection services. Typically, an intelligent I / O peripheral can provide any transparent and / or non-transparent back-end network service in a plurality of transparent and / or non-transparent back-end network services for the host. As an example, network-related backend services may include overlay network services, virtual switching services, virtual routing services, and network function virtualization services. As an example, storage-related backend services may include backend storage I / O services of hosts such as storage acceleration services (e.g., services based on high-speed non-volatile memory (NVMe)), directly attached storage services, or serial attached SCSI (SAS) storage services.
[0025] A smart I / O peripheral can coordinate with another network component with the goal of providing one or more back-end I / O services. For example, a smart I / O peripheral can be a "smart NIC" connected to an Ethernet top-of-rack (ToR) switch. This combination can provide host isolation by using the smart NIC for high-speed peripheral component interconnect (PCIe) physical functions and virtual functions in a "locked state" of the smart NIC. Here, "locked state" refers to the ability to fully reconfigure the host access device based on the cloud operator's objectives. For example, the locked state can prevent the host from reconfiguring a specific infrastructure (e.g., turning off storage redundancy, turning off a graphics processing unit (GPU), etc.), which may otherwise affect, for example, the cloud operator's contractual obligations to tenants. With this arrangement, the ToR switch can be used to provide such network services as a network protection service (e.g., a firewall service) or an instance coverage service (e.g., a virtual extensible local area network (VxLAN) service).
[0026] The intelligent I / O peripheral device can take one of a variety of different physical forms and provide any of a variety of back-end I / O services. A given intelligent I / O peripheral device can provide a network connection (e.g., an Ethernet port), provide multiple CPU cores, provide a hardware acceleration engine, and provide a rich programming environment (i.e., an environment that enhances the integration of independent software components). In addition, the intelligent I / O peripheral device can provide an endpoint connection (e.g., providing one or more PCIe ports) to an in-band communication channel (e.g., a PCIe link or bus) accessible to the host. As a specific example, the components of the intelligent I / O peripheral device based on the PCIe card can be installed on a circuit card substrate with a PCIe card edge connector, and the PCIe card edge connector has a form factor that allows the intelligent I / O peripheral device to be installed in a PCIe card slot connector of a server. According to further embodiments, the intelligent I / O peripheral device can be configured to be installed in a card slot connector other than a PCIe card slot connector, and according to further example embodiments, the components of the intelligent I / O peripheral device can be installed (e.g., surface mounted) on the motherboard of the server.
[0027] The cloud-native segmented server with intelligent I / O peripherals creates a dual management control system within the server, thereby separating the control of the intelligent I / O devices from the host CPU control by adding a hardware abstraction interface to the host. The hardware abstraction interface can be presented to the host as a standard local I / O peripheral (i.e., a non-intelligent I / O peripheral).
[0028] The host can access the intelligent I / O peripheral device (e.g., using PCIe direct I / O communication to access the PCIe-based intelligent I / O peripheral device) to map physical functions and virtual functions (e.g., PCIe physical functions and virtual functions) to machine abstractions (e.g., bare metal or virtual machine abstractions). The back-end I / O services provided by the intelligent I / O peripheral device can be completely managed by the intelligent I / O peripheral device independently of the host. In addition, the life cycle of these services can be controlled by the intelligent I / O peripheral device independently of the host.
[0029] Therefore, segmented servers with cloud-native infrastructure architectures with hardware abstraction to isolate smart I / O peripherals are different from non-segmented servers with traditional architectures built around host-centric control. This difference creates an architectural gap in current server designs for both pre-boot and runtime environments. The architectural gap creates challenges in orchestrating control because the host is no longer the source of control.
[0030] One way to address this dilemma and narrow the architectural gap is to modify the traditional server hardware architecture to allow control of the server to be rooted in the server's service processor. For example, the slot connector (e.g., PCIe connector) of the traditional server hardware architecture can be modified to support a sideband communication channel with a baseboard management controller (or "BMC"). Generally speaking, a BMC is a service processor constructed to manage a computer platform. With this approach, control is rooted in the BMC, and the traditional role of the BMC is extended to manage intelligent I / O peripherals by transmitting management traffic over a sideband communication channel. Another way to narrow the architectural gap can be to modify the traditional server hardware architecture to include an additional service processor, a platform controller, and a root control in a platform controller, so that the platform controller monitors both the BMC and the intelligent I / O peripherals.
[0031] The methods described above for closing the architectural gap in segmented servers involve changes in the next generation server architecture. However, modifying the legacy server hardware architecture to accommodate the intelligent I / O peripherals in the next generation server does not provide a backward compatibility path for existing servers.
[0032] According to example embodiments described herein, the trusted domain of a host of a segmented server (referred to as a "computing device") (referred to herein as a "cloud tenant domain") is intermixed with the hardware-isolated trusted domain of the computing device's intelligent I / O peripherals (referred to herein as a "cloud operator domain"). This intermixing ensures that host services that may be offloaded to the intelligent I / O peripherals are protected and controlled both before and after the operating environment becomes operational. In other words, according to example embodiments, the host software stack is intermixed with the offloaded services. This segue of the host offload services with the host software stack may impact the machine abstractions (e.g., a bare metal OS environment and a hypervisor VM environment) supported by the intelligent I / O peripherals. According to example embodiments, the computing device includes a host monitoring service for monitoring the machine abstraction.
[0033] For a bare metal application operating environment (i.e., an environment where software has full access to the host CPU and other resources of the physical platform exposed to the software), the computing device may provide a host monitoring service that links the backend I / O services provided by the smart I / O peripherals to a single secure trusted domain in the host space. In addition, according to an example embodiment, the bare metal operating system may provide a hypervisor; and the computing device may provide a corresponding host monitoring service for the associated machine abstraction. The host monitoring service provides the ability to compensate for architectural gaps caused by the architectural opacity of the smart I / O peripherals.
[0034] Due to unauthorized modification of the "computing state" of the computing device, the computing device may experience a security breach. In this context, the "computing state" of the computing device generally refers to the configuration of the computing device. The computing device can be specifically configured to serve a specific purpose. These purposes (and corresponding configurations) can vary widely. In this way, as an example, a given computing device can be configured to control the lights of a stadium, provide database management services for commercial enterprises, manage transactions for financial institutions, etc. Depending on the use or application of the specific intention of the computing device, a specific configuration or "reference computing state" can be defined for a given computing device. The reference computing state can define any of many different configuration attributes of the computing device, such as a specific inventory of hardware components, the physical topological location of corresponding specific hardware components (e.g., a specific slot number, a specific cage number, a connection with a specific connector or wiring harness). The reference computing state can define a specific firmware version, and the reference computing state can define a specific firmware signature. The reference computing state can specify the relationship between certain hardware components (e.g., a certain DIMM group will have a certain equal size or will have a certain minimum size, or a certain storage drive group will be equal in size or meet a certain performance standard). The reference computing state may specify whether a particular component may be hot-pluggable or hot-unpluggable. The reference computing state may specify criteria for hot-plug replacement of storage drives and / or memory modules. Hot-pluggable components may be physical components or virtual components. For example, a PCIe adapter (e.g., an intelligent I / O peripheral) may provide independent hot-pluggable virtual and physical functions as part of the adapter's PCIe direct I / O capabilities for virtual machines.
[0035] As an example of an unauthorized change to a reference computing state of a computing device, an authorized PCIe card may be installed in the computing device, or an authorized dual inline memory module (DIMM) may be installed in an unauthorized memory slot of the DIMM. As another example of an unauthorized change, a particular DIMM or non-volatile memory Express (NVMe) storage drive may not be authorized for use in a computing device, but the DIMM or NVMe storage drive may still be hot-plugged into the computing device. As another example, a particular hot-pluggable component (e.g., an NVMe storage device or DIMM) may be approved for use in a particular hot-plug connector of a computing device, but the component may be hot-plugged into a particular hot-plug connector that is not authorized for use with the hot-pluggable component.
[0036] One way to ensure that a particular reference computing state is enforced for a computing device is to use an on-site technician to set up the computing device. In addition, the computing device can be placed in a secure environment to ensure that unauthorized modifications to the computing state of the computing device do not occur thereafter. However, these security measures may be quite impractical for modern cloud-based computing systems, which include a large number (e.g., thousands, tens of thousands, or even more) of computing devices (e.g., blade servers) that may be located in multiple data centers.
[0037] According to example embodiments described herein, a pre-boot monitoring service of a computing device forces the computing device to comply with a reference computing state of the computing device. More specifically, according to example embodiments, in response to a startup of the computing device (e.g., a power-on startup or a reset-initiated startup), the onboard pre-boot monitoring service verifies whether the computing device complies with a reference computing state that has been specified for the computing device. If the pre-boot monitoring service verifies compliance, the pre-boot monitoring service allows the computing device to continue to set up a tenant runtime environment (e.g., a machine abstraction), join a cluster of other computing devices of a cloud-based computing system, and provide a tenant runtime environment. However, if the verification performed by the pre-boot monitoring service fails, according to example embodiments, the pre-boot monitoring service prevents the computing device from setting up or providing any tenant runtime environment, and the pre-boot service causes the computing device to immediately isolate or separate itself from the cloud-based computing system.
[0038] According to some embodiments, in a runtime environment of a computing device, the computing device includes one or more runtime monitoring services that force the computing device to comply with a reference computing state. The one or more runtime monitoring services protect the computing device from configuration modifications that may occur, for example, due to a hot plug event (in which a component is hot plugged into a hot plug connector of the computing device) or a hot unplug event (in which a component is hot unplugged from a hot plug connector). For example, the runtime monitoring service may determine whether the reference computing state allows the event in response to a hot plug event or a hot unplug event. If the runtime monitoring service determines that the event is not allowed, then according to an example embodiment, the runtime monitoring service may cause the computing device to take one or more appropriate remedial actions. As an example, these remedial actions may include one or more of the following: the computing device stops the operation of the cloud-based computing system; the computing device is powered off; the computing device migrates to a pre-boot environment; the computing device isolates or separates itself from the cloud-based computing system; the computing device cryptographically erases the contents of the persistent memory devices and storage devices of the computing device and associated with the computing device; the computing device sends an alert message to the domain manager and the system administrator; etc.
[0039] Unauthorized modifications to the network infrastructure of a cloud-based computing system may expose the computing system to security vulnerabilities. As an example of unauthorized network infrastructure state modification, an authorized network switch may be connected to a computing device, or an otherwise authorized network switch may be relocated to an unauthorized physical location (e.g., a different floor of a building than the floor permitted for the network switch). As another example, a computing device may be connected to an authorized network switch, but the computing device may be in a different physical location than the authorized network switch. As another example, a cloud-based computing system may have a scaling policy for expanding or shrinking the computing devices of the system. For example, the policy may specify that scaling will occur in units of ten computing devices at a time. Attempts (and potentially suspicious attempts) may be made to add a single computing device to a cloud-based computing system without meeting the necessary scaling criteria.
[0040] Security vulnerabilities due to unauthorized modification of computing state or network infrastructure state may result in non-compliance with strict specifications of computing state or network infrastructure state; introduce security concerns for cloud tenant software; and potentially compromise the integrity of cloud-based computing systems.
[0041] According to example implementations described herein, a reference computing state includes a set of composite identifications (IDs) that may define, for example, properties of specific hardware components in a computing device and the physical topological locations of those hardware components.
[0042] According to an example embodiment, the composite ID has two components: an anchor ID and a public ID. According to an example embodiment, the anchor ID is a unique identifier of a specific component (e.g., a PCIe card), such as a media access control (MAC) address of a component, an encrypted MAC address of a component, etc. According to some embodiments, the anchor ID may define a specific category or level of a hardware component without identifying a unique hardware component. As an example, according to an example embodiment, the anchor ID may identify the minimum storage size of the hardware component. As another example, the anchor ID may identify a specific manufacturer of the hardware component. As another example, the anchor ID may identify the minimum processor specification of the hardware component. As another example, the anchor ID may identify a model of the hardware component or a range of models of the hardware component. As another example, the anchor ID may identify a specific attribute of the hardware component. As another example, the anchor may identify a serial number range of the hardware component. In general, the anchor ID may identify any of a plurality of other attributes that are indirectly or directly attributable to the hardware component, such as the maximum power consumption of the hardware component, the electromagnetic interference rating range of the hardware component, etc.
[0043] According to an example implementation, the public ID identifies a specific physical topological arrangement associated with a hardware component. For example, the physical topological arrangement associated with a PCIe card may be that the PCIe card should be located in slot 2 of PCIe input / output (I / O) cage B of a computing device. Because the composite ID uniquely identifies the component and the physical topological arrangement of the component, the composite ID may be used to prove the computing state of a computing device in an actual deployment.
[0044] The reference computing state may include data representing configuration standards for the computing device in addition to data representing composite IDs of certain hardware components. For example, the reference computing state may specify a strategy for the computing device to respond to hot plug events and / or hot unplug events. As another example, the reference computing state may specify a strategy for failing over to redundant devices, a strategy for reporting audit logs, a strategy for handling program execution crashes, a minimum firmware version, a specific firmware version, an access control strategy for updating firmware, etc.
[0045] The reference computing state of a given computing device may be defined by a digital certificate signed by an administrator with appropriate credentials. For example, the certificate may contain data representing the identity of the computing device (e.g., the serial number of the computing device, a reference to an endorsement key of a trusted platform module (TPM), etc.), and the certificate may contain data representing a composite ID and other configuration standards of the computing device. The certificate defining the reference computing state is distinct from a platform certificate, which may, for example, enumerate an inventory of a server without specifying how those components are actually physically deployed in the server (e.g., without specifying their corresponding physical topology) and without specifying other configuration standards of the server.
[0046] If the computing device does not comply (as described herein), then the computing device is forced to comply with the reference computing state, so that the computing device provides cloud tenant runtime services, protects cloud tenant space (i.e., the leased space of the computing device), and generally, protects cloud-based computing systems from security intrusions. According to example embodiments, the protection prevents the occurrence of security intrusions, as compared to security detection measures that detect when a security intrusion (and potential compromise) has occurred so that remedial actions can be taken to mitigate future compromises and / or recover from the security intrusion.
[0047] According to example embodiments, a reference network infrastructure state may be defined for a network infrastructure associated with a given computing device. The reference network infrastructure state defines an expected configuration of a network infrastructure associated with the computing device. According to example embodiments, the reference network infrastructure state includes an expected address (e.g., an Internet Protocol (IP) address) of a network access point (e.g., a ToR switch, a gateway, etc.) of the computing device. The network access point may or may not be the first network component to which the computing device is connected. For example, a network administrator may limit the visibility of the computing device to one or more network components that are closest to the computing device in order to allow replacement of these network components without affecting the operation of the computing device. In turn, such a restriction may affect which particular network component the computing device considers to be a network access point. Because the network access point location is part of the reference network infrastructure state, the computing device may be locked to a specific physical network connection.
[0048] The reference network infrastructure state may also include location information associated with the computing device. According to an example embodiment, the location information may include one or more of the following location attributes of the network access point and / or the computing device; Global Navigation Satellite System (GNSS) coordinates; Building address (e.g., building number of the physical address of the building); Floor number of the building where the computing device and / or the network access point is located (e.g., 5th floor); Data center identifier; Altitude (e.g., height relative to sea level); etc. Due to the location information, even if the physical network connection does not change from the location information represented by the reference network infrastructure state, the computing device and / or the network switch may not be moved to a location that deviates from the location information of the reference network infrastructure state. Thus, for example, a computing device may not be physically moved to a less secure, unauthorized location and still comply with a reference network infrastructure state that specifies a different location.
[0049] According to example embodiments, the reference network infrastructure state may include data representing other configuration standards of the network infrastructure associated with the computing device. For example, according to example embodiments, the reference network infrastructure state may specify a network computing device scaling policy. As another example, the reference network infrastructure state may specify that a specific computing device group may be added one at a time or that the specific group may be added to a cloud-based system all at once. As another example, the reference network infrastructure set may specify SDN connection standards for computing devices. For example, the reference network infrastructure set may specify a minimum bandwidth for the SDN connection of the computing device. For example, such a minimum bandwidth standard may be used to protect against denial of service attacks. As another example, the reference network infrastructure state may specify standards for the SDS connection of the computing device. For example, if the computing device is located in a jurisdiction with strict privacy regulations, the reference network infrastructure state may specify that the data storage of the computing device will not be located outside the jurisdiction. As another example, the reference network infrastructure state may specify a specific SDC machine instance signature for the computing device.
[0050] According to some embodiments, reference Figure 1 As a more specific example, a cloud-based computing system 100 affiliated with a particular cloud operator can provide multi-tenant cloud services to multiple clients or tenants. The cloud service can be any of a number of different cloud services, such as software as a service (SaaS), infrastructure as a service (IaaS), platform as a service (PaaS), etc. In addition, depending on the specific implementation, the cloud service can be affiliated with one of several different cloud infrastructures, such as a public cloud that is generally available to all potential users through a public network; a limited access private cloud provided through a dedicated network (e.g., a cloud service provided by an on-site data center); or a hybrid cloud that combines public and private clouds.
[0051] Tenants can access computing devices 110 (eg, computing nodes) of cloud computer system 100 via cloud clients (eg, laptop computers, desktop computers, smart phones, tablet computers, wearable computers, etc.). Figure 1 As depicted in , computing devices 110 may be interconnected via a physical network fabric 184. In general, physical network fabric 184 may be associated with one or more types of communication networks, such as, for example, a Fibre Channel network, a Gen-Z fabric, a dedicated management network, a local area network (LAN), a wide area network (WAN), a global network (e.g., the Internet), a wireless network, or any combination thereof. Figure 1 As depicted in , computing devices 110 may be interconnected via logical connections 194 (eg, SDN, SDC, and SDS connections) overlaid on a physical network structure 184 .
[0052] According to an example implementation, Figure 1 Depicted are details of a particular computing device 110-1 of the cloud-based computing system 100. As further described herein, computing device 110-1 has onboard features to force computing device 110-1 to comply with a reference computing state of computing device 110-1.
[0053] According to an example implementation, at a given time, computing device 110-1 is in one of a pre-boot environment or a runtime environment. Figure 1 Both pre-boot components and runtime components of computing device 110-1 are depicted, but it should be understood that the pre-boot components do not exist in the runtime environment, and the runtime components do not exist in the pre-boot environment. For example, pre-boot monitoring service 156 of computing device 110-1 executes in the pre-boot environment and not in the runtime environment. As another example, tenant runtime environment 120 and runtime monitoring service 150 exist in the runtime environment and not in the pre-boot environment.
[0054] According to an example implementation, the computing device 110-1 boots up in a pre-boot environment (e.g., in response to a power-on startup, a reset, a power-up controlled via a remote management network, a reset controller via a remote management network, etc.). In this context, the "pre-boot environment" of the computing device 110-1 refers to the environment of the computing device 110-1 before the computing device 110-1 provides one or more tenant runtime environments 120 to one or more cloud tenants. The pre-boot monitoring service 156 operates in the pre-boot environment. The CPU 116 of the computing device 110-1 may execute BIOS 165 or UEFI 169 instructions to provide at least some functions of the pre-boot monitoring service 156. These functions may include the CPU 116 communicating with one or more intelligent I / O peripherals 180 of the computing device 110-1 and communicating with the BMC 123 of the computing device 110-1. According to some implementations, the one or more intelligent I / O peripherals 180 may be installed in corresponding slot connectors 181 (e.g., PCIe connectors).
[0055] According to an example embodiment, the pre-boot monitoring service 156 can set the tenant visibility of the resources of the computing device 110-1. Resources may be hidden from tenants for a variety of different reasons, such as the tenant not wanting to pay for the resources, controlling the quality of service (because exposing the resources may affect the performance of the computing device 110-1), etc. According to some embodiments, the pre-boot monitoring service 156 can control the visibility of one or more physical functions and / or one or more virtual functions of the smart I / O peripherals 180 accordingly, so that one or more functions are not exposed to the domain manager 190. The hidden resources can be any of a plurality of different resources, such as a device (e.g., a graphics processing unit (GPU), a CPU, an NVMe drive, etc.), a memory exceeding a certain capacity, a CPU core frequency exceeding a certain limit, etc.
[0056] In general, the pre-boot monitoring service 156 may compile an inventory of logical infrastructure resources and physical infrastructure resources of the computing device 110-1; control visibility of resources of the computing device 110-1; and set up the tenant runtime environment 120. According to an example implementation, the pre-boot monitoring service 156 searches for a domain manager 190 (e.g., the pre-boot monitoring service 156 searches on an encrypted overlay network) and binds the computing device 110-1 to the domain manager 190 for control. As part of executing the pre-boot monitoring service 156, the CPU 116 may, for example, set up a PCIe configuration space for one or more smart I / O peripherals 180.
[0057] According to an example embodiment, pre-boot monitoring service 156 has a component that enforces computing device 110-1 to comply with reference computing state 138 of computing device 110-1, namely computing state verification engine 157. According to some embodiments, computing state verification engine 157 may be provided by one or more CPUs 116 executing host operating system instructions 163.
[0058] According to example embodiments, computing devices 110 of cloud-based computing system 100 may or may not have architectures similar to or identical to computing device 110-1. In addition, according to example embodiments, one or more of these other computing devices 110 may or may not have features for forcing computing device 110 to comply with a corresponding reference operating state.
[0059] The cloud-based computing system 100 may include one or more domain managers 190. The domain manager 190 may be coupled to the physical network structure 184 and the logical connection 194. Depending on the specific implementation, the domain manager 190 may be located on the computing device 110-1, on another computing device 110, on a dedicated management node, distributed across multiple nodes of the cloud computer system 100, etc. In general, the domain manager 190 includes physical hardware resources and logical software resources for managing a group of computing devices 110 referred to as a "domain". The cloud-based computing system 100 may have one or more domains. According to some embodiments, the domain manager 190 may be associated with a database that stores data about the computing devices 110, such as data representing computing device configurations, telemetry logs, audit logs, etc. The domain manager 190 may include an orchestration engine that manages the operation of the leaf managers of the cloud computing system 100, with the purpose of controlling the life cycle and configuring the leaf resources of the system 100 (e.g., the intelligent input / output (I / O) peripherals 180 described herein). According to some embodiments, domain manager 190 can communicate intent-based commands (e.g., Redfish commands) with one or more vendor root managers (not shown). The vendor root manager includes physical hardware resources and logical software resources for converting intent-based commands into vendor-specific commands associated with a specific vendor for leaf resources, and these vendor-specific commands can be processed by leaf resource managers (not shown) of leaf resources. According to specific embodiments, the vendor root manager and leaf resource managers can be set on one or more management nodes, can be distributed on one or more computing devices 110, etc.
[0060] According to an example embodiment, the domain manager 190 includes a network infrastructure state verification engine 193. According to an example embodiment, the network infrastructure state verification engine 193 enforces the network infrastructure of the cloud-based computing system to comply with an expected or reference network infrastructure state. According to an example embodiment, the enforcement may include enforcing the network infrastructure associated with a given computing device 110 to comply with a reference network infrastructure state of the network infrastructure.
[0061] According to an example embodiment, computing device 110-1 may be a computer platform. In this context, a "computer platform" refers to a unit that includes a chassis and hardware mounted to the chassis, wherein the hardware is capable of executing machine-executable instructions (or "software"). According to an example embodiment, a blade server is an example of a computer platform. However, according to further embodiments, the computer platform may be a platform other than a blade server, such as a rack-mounted server, a client, a desktop computer, a smart phone, a storage array, a laptop computer, a tablet computer, etc.
[0062] For example embodiments where the computer platform is a blade server, the server may have a frame or chassis; one or more motherboards may be mounted to the chassis; and each motherboard may contain one or more multi-core central processing unit (CPU) semiconductor packages (or "sockets" or "chips"). According to example embodiments, the blade server may have a form factor, one or more mechanical latches, and corresponding electrical connectors for the purpose of allowing the server blades to be installed in or removed from corresponding server blade openings or slots in a rack-mounted blade enclosure.
[0063] According to further example embodiments, computing device 110-1 may have a disaggregated or distributed architecture. In this manner, for these embodiments, components of computing device 110-1 are not co-located on a single computer platform, but rather, components of computing device 110-1 may be distributed across multiple computer platforms. Furthermore, components of computing device 110-1 may be distributed across multiple geographic locations (e.g., distributed across multiple data centers with different geographic locations).
[0064] According to an example implementation, computing device 110-1 may have a cloud segmentation architecture, wherein a smart I / O peripheral 180 of computing device 110-1 may control different logical connection segments independently of a host of computing device 110-1. Computing device 110-1 may provide one or more tenant runtime environments 120 within cloud tenant domain 111. As an example, tenant runtime environment 120 may be a machine abstraction provided for one or more cloud tenants. As a more specific example, tenant runtime environment 120 may include one or more operating system (OS) bare metal abstractions, one or more virtual machine abstractions, and the like.
[0065] In this context, a "virtual machine" or "VM" (also referred to as a "guest virtual machine," "virtual machine instance," or "guest virtual machine instance") refers to a virtual environment that acts as a machine-level abstraction or virtual computer system with its own physical resources (e.g., one or more CPUs, system memory, one or more network interfaces, and storage). In addition, a VM can have its own abstraction of an operating system; and typically, a VM is a virtual abstraction of the hardware and software resources of computing device 110-1. The lifecycle of a VM (e.g., deployment and termination) can be managed by a virtual machine monitor (VMM) or hypervisor 167 of computing device 110-1. Alternatively, a VM can be managed by a kernel-based VM (or "KVM").
[0066] According to an example embodiment, each tenant runtime environment 120 may have an OS, a hypervisor, or a KVM interface 121 (referred to as an "OS / hypervisor / KVM interface 121"), and in general, the OS / hypervisor / KVM interface 121 may form a tenant workload isolation barrier 197 between the cloud tenant domain 111 and the cloud operator domain 113 of the computing device 110-1. According to an example embodiment, the cloud tenant domain 111 is considered an untrusted domain of the cloud computing system 100 because the domain 111 is associated with cloud tenant software. The cloud operator domain 113 may be considered a trusted domain relative to the cloud tenant domain 111.
[0067] According to an example embodiment, the cloud operator domain 113 includes a hybrid physical and logical infrastructure including physical hardware components and trusted monitoring software components. Components associated with the monitoring services described herein are isolated from tenant workloads by a tenant workload isolation barrier 197 and a tenant workload isolation barrier 198 formed by a host interface of an intelligent I / O peripheral 180. According to an example embodiment, the intelligent I / O peripheral 180 forms a network isolation barrier 199 for the computing device 110-1. As an example, the physical hardware components associated with the monitoring services may include one or more central processing units (CPUs) 116 and memory components forming a system memory 118.
[0068] According to example implementations, the system memory 118 and other memories discussed herein are non-transitory storage media that may be formed of semiconductor memory devices, memristor-based memory devices, magnetic memory devices, phase-change memory devices, combinations of devices of one or more of these memory technologies, etc. The system memory may represent a collection of both volatile memory devices and non-volatile memory devices.
[0069] One or more CPUs 116 may execute machine-executable instructions 117 to form various trusted monitoring software components of computing device 110-1, such as basic input / output system (BIOS) 165, unified extensible firmware interface (UEFI) 169, host operating system 163, and hypervisor 167. Figure 1, the smart I / O peripherals 180 are within the cloud operator domain 113. According to example embodiments, the cloud operator domain 113 may include one or more host monitoring services provided by one or more trusted monitoring software components. For example, according to example embodiments, the cloud operator domain 113 may include a pre-boot monitoring service 156 and one or more runtime monitoring services 150 that operate during runtime of the computing device 110-1. In general, as described herein, the monitoring services 150 and 156 may serve a variety of purposes of bridging the architectural gap between a host-centric control model and a cloud-native control model of the computing device 110-1.
[0070] As an example, according to some embodiments, runtime host monitoring service 150 may include one or more of the following: hypervisor VM runtime monitoring service 150 (e.g., a service as a privileged virtual machine in a hypervisor) and OS-bare metal runtime monitoring service 150 (e.g., a service provided by UEFI 169 and / or BIOS 165). Pre-boot monitoring service 156 may be provided by UEFI 169 and / or BIOS 165. For example, pre-boot monitoring service 156 may be provided by an embedded operating system such as a smart provisioning operating system.
[0071] According to example embodiments, computing state verification engine 157 determines an actual computing state of computing device 110-1 in response to the startup of computing device 110-1. According to some embodiments, computing state verification engine 157 provides a barrier that prevents computing device 110-1 from providing tenant runtime environment 120 until computing state verification engine 157 verifies that computing device 110-1 complies with the reference computing state. According to example embodiments, data representing reference computing state 138 of computing device 110-1 may be stored in secure memory 134 of computing device 110-1. Figure 1 In the example implementation depicted in , secure memory 134 may be a memory to which access is controlled by a secure gateway component, such as BMC 123. According to further implementations, other secure memories may be used.
[0072] As further described herein, in the runtime environment of computing device 110-1, runtime monitoring service 150 of computing device 110-1 may force computing device 110-1 to comply with the reference computing state in response to a hot plug / hot unplug event. According to some embodiments, runtime monitoring service 150 may be formed by CPU 116 executing instructions of operating system 163. Forcing computing device 110-1 to comply with the reference computing state may involve runtime monitoring service 150 taking one or more actions in response to detected non-compliance, such as actions involving stopping operation of computing device 110-1 with cloud-based computing system 100; powering off computing device 110-1; returning computing device 110-1 to a pre-boot environment; isolating or separating computing device 110-1 from cloud-based computing system 110-1; ceasing to provide tenant runtime environment 120; cryptographically erasing persistent storage devices and memory devices on and associated with computing device 110-1; etc. In this context, "cryptographically erasing" a device refers to removing access to cryptographic keys that would potentially allow recovery of corresponding plaintext content. For example, a self-encrypting drive (e.g., an NVMe drive) may internally store and use a media access key to encrypt and decrypt data stored in the drive, and, for example, cryptographically erasing the self-encrypting drive may include removing or erasing the drive's media access key.
[0073] According to some embodiments, event notifications for computing device 110-1 (e.g., failure notifications, error notifications, hot plug events, security-related event notifications, etc.) are directed to a management controller of computing device 110-1. For example, the management controller is BMC 123. However, according to further embodiments, the management controller may be another component, such as a chassis management controller, a platform controller, a domain manager 190, etc.
[0074] Typically, as used herein, a "BMC" is a dedicated service processor that uses sensors to monitor the physical state of a server, node, or other hardware entity and communicates with a management system through a management network. According to an example embodiment, the BMC operates under the control of a monitoring service (e.g., monitoring service 150 or 156) or a domain manager (e.g., domain manager 190) that acts as a BMC owner. The BMC can communicate with an application program executed at the operating system level through the following: an input / output controller (IOCTL) interface driver, a representative state transfer (REST) application program interface (API), or some other system software agent that facilitates communication between the BMC and the application program. The BMC can perform hardware-level access to the hardware devices (including system memory, local memory, etc.) of the hardware entity. The BMC can be able to modify the hardware device directly. The BMC can operate independently of any operating system instance of the hardware entity. The BMC can be located on a motherboard or main circuit board of the hardware entity. The fact that the BMC is mounted on a motherboard or otherwise connected or attached to the motherboard does not prevent the BMC from being considered as "separated" from the processor that the BMC is monitoring / managing. As used herein, a BMC has management capabilities for a subsystem of hardware entities and is separate from the processing resources that execute the operating system of the computing device.
[0075] As described herein, regardless of its specific form or implementation, the BMC 123 may include one or more embedded processors 124 that execute machine-readable instructions 125 (stored in a memory 126 of the BMC 123) for the purpose of performing actions by the BMC 123. According to example embodiments, these actions may include receiving and managing host notifications. In addition, according to some embodiments, the BMC 123 may control access to a secure memory 134. The secure memory 134 may be a non-volatile memory, and according to example embodiments, the secure memory 134 may store data representing an audit log 136 and a reference computing state 138.
[0076] The audit log 136 may be used to record events for the computing device 110-1. According to an example embodiment, the audit log 136 (daily or summary) contains data describing security / control updates to the node infrastructure reference set 138 and the network infrastructure reference set 142. By analyzing / tracking the complete aggregate audit log records, the audit log 136 may be used as a proof of the operational state of the computing device 110-1. According to some embodiments, the records in the audit log 136 may be time-stamped. According to some embodiments, the records in the audit log 136 may be stamped or marked with one of a plurality of values from one or more operating time meters 135 (or "Hobbes meters"). As an example, according to some embodiments, the BMC 123 may maintain an operating time meter 135 to track the total on time of the computing device 110-1 since the computing device 110-1 entered service and maintain another odometer 135 to keep a running count of the total number of power cycles of the computing device 110-1. According to an example embodiment, the BMC 123 may maintain the audit log 136.
[0077] According to some embodiments, the reference computing state 138 may specify an aggregation component of the computing device 110-1, which is used to collect information related to the network infrastructure state (for example, specific network infrastructure reference state information about the computing device 110-1, such as the network access point IP address, location information of the computing device 110-1, SDN connection attributes, SDS connection attributes, etc.) and report the information to the domain manager 190.
[0078] In addition to those described above, BMC 123 may provide a variety of other management services, such as monitoring sensors (e.g., temperature sensors, cooling fan speed sensors); monitoring operating system status; monitoring power supply status; controlling power on and off of the computer system; logging computer system events; allowing remote management of the computer system; performing recovery operations after an operating system or computer system failure, etc. According to some embodiments, BMC 123 may also have a security plane, wherein BMC 123 performs various security-related functions for computing device 110-1, such as verifying firmware before it is allowed to load and be executed by processor 124; storing, generating and providing cryptographic keys, etc. According to some embodiments, BMC 123 may manage audit log 136 as part of its security plane. According to example embodiments, BMC 123 is under the control of a monitoring service (e.g., monitoring service 150 or 156) or domain manager 190, with the only exception that compliance with reference computing state 138 is not verified. In this way, if the computing state verification engine 157 fails to verify the reference computing state 138 (i.e., the computing device 110-1 does not comply with the reference computing state 138), then according to an example embodiment, after the computing device 110-1 is separated or isolated from the cloud-based computing system 100, the service password can be used to activate the server administrator role for the purpose of managing the computing device 110-1 via the BMC 123.
[0079] According to example embodiments, computing device 110-1 may have one or more sensors that provide data representative of properties of computing device 110-1. For example, according to some embodiments, computing device 110-1 may include one or more GNSS radios 102 that provide data representative of the physical location of computing device 110-1 or the physical location of specific components of computing device 110-1. As another example, according to some embodiments, computing device 110-1 may include an altimeter that provides data representative of the altitude of computing device 110-1 or the altitude of specific components of computing device 110-1. As another example, according to some embodiments, computing device 110-1 may include a tampering sensor that provides data representative of whether a component or portion of computing device 110-1 has been tampered with. Although Figure 1 Not depicted in the figure, in a similar manner, the physical network structure 184 may include one or more sensors that provide data representing properties (e.g., altitude, GNSS coordinates, etc.) of one or more network devices (e.g., network switches, gateways, ToR switches, etc.) of the physical network structure 184.
[0080] Figure 2FIG. 2 illustrates a process 200 for verifying a computing state of a computing device 110 - 1 according to an example implementation. Figure 1 refer to Figure 2 , the process 200 includes a computing state validation engine 157 determining an actual computing state 201 of a computing device 110-1. According to an example embodiment, the actual computing state 201 includes a set of composite IDs 210. According to an example embodiment, each composite ID 210 may include an anchor ID 214 and a public ID 212. The actual computing state 201 may include additional configuration information 215 for the computing device 110-1, such as specifying an aggregation component of the computing device 110-1 to collect data representing a network infrastructure state specific to the computing device 110-1 and send the data to the domain manager 190; one or more hot plug / hot unplug policies for the computing device 110-1; a policy for a resiliency subsystem (e.g., a RAID subsystem) of the computing device 110-1; specifying a component to transmit an audit log 136 to the domain manager 190; a cryptographic erase policy for persistent memory and / or storage devices; a policy for handling program execution crashes; a minimum firmware version; a specific firmware version, an access control list that authorizes updating specific credentials to update firmware, and the like.
[0081] According to an example embodiment, the anchor ID 214 identifies the corresponding component of the computing device 110-1. As an example, the anchor ID 214 may include one or more of the following attributes of the component: a serial number, a model number, a media access control (MAC) address, a unique identifier, etc. In addition, according to an example embodiment, the anchor ID 214 may be formed by a concatenation of the aforementioned elements, and according to some embodiments, the concatenation may be encrypted using a private portion (or "private key") of an asymmetric key so that the corresponding public portion (or "public key") can be used to decrypt the anchor ID 214 into plain text. The anchor ID 214 may also represent a specific category or type of hardware component without identifying a unique hardware component. For example, according to an example embodiment, the anchor ID 214 may identify a minimum storage size of a hardware component, a specific manufacturer of a hardware component, a minimum processor specification of a hardware component, a model number of a hardware component, a model range of a hardware component, a specific attribute of a hardware component, a serial number range of a hardware component, a maximum power consumption of a hardware component, an electromagnetic interference rating range of a hardware component, etc.
[0082] According to an example embodiment, the public ID 212 represents a physical topological or spatial attribute of a component. According to an example embodiment, the physical topological attribute may correspond to a manufacturing process ID location (e.g., a motherboard silk screen label). As a more specific example, Figure 2Various hardware components 207 of computing device 110-1 are depicted according to an example implementation. At least some of hardware components 207 may be located on or installed in relation to motherboard 241 of computing device 110-1. Figure 2 1 is depicted as an example, but it should be understood that according to example embodiments, computing device 110-1 may have other circuit card substrates or circuit boards, such as a mezzanine board, one or additional motherboards, an adapter card, etc.; and the hardware components corresponding to a particular composite ID 210 may be located on one or more of these circuit boards.
[0083] for Figure 2 In the example embodiment depicted in , the NVMe device 256 is installed in a corresponding bay 251, which is mounted to the motherboard 241. The bays 251 can be sequential or numbered, such that a particular NVMe device 256 can be installed in bay number one, another NVMe device 256 can be installed in bay number four, and so on. It should be noted that some of the bays 251 can be empty, that is, the bay 251 may not have an installed NVMe device 256. According to the example embodiment, the corresponding composite ID 210 of the NVMe device 256 includes an anchor ID 214 (e.g., an encrypted serial number of the NVMe device 256) and a public ID 212 (e.g., an identifier of the particular bay 251 in which the NVMe device 256 is installed). Therefore, according to the example embodiment, the composite ID 210 of a given component of the computing device 110-1 uniquely identifies the component and identifies the physical topological location of the component in the computing device 110-1. An NVMe device 256 installed into a particular bay 251 has a corresponding public ID 212 that is different from the public ID 212 of the same NVMe device 256 when installed in another bay 251 (and, correspondingly, a different composite ID 210).
[0084] According to an example implementation, the composite ID 210 may correspond to many different types of components of the computing device 110-1 and their corresponding physical topological locations. For example, the actual node infrastructure set 201 may include a composite ID 210 for a PCIe device 279. For example, a particular composite ID 210 may uniquely identify the corresponding PCIe device 279, as well as the PCIe I / O cage 278 and PCIe slot 277 in which the PCIe device 279 is installed.
[0085] As another example, another set of composite IDs 210 may represent DIMMs 263. In this manner, a given composite ID 210 may include an anchor ID 214 that uniquely identifies a particular DIMM 263, and a corresponding public ID 212 may identify a bank 260 and a particular slot 261 within the particular bank 260 in which the DIMM 263 is installed.
[0086] As another example, a particular set of compound IDs 210 may be associated with serially attached small computer system interface (SCSI) or "SAS" devices 254. For the set of compound IDs 210, the anchor ID 214 of the particular compound ID 210 may uniquely identify the particular SAS device 254, and the corresponding public ID 212 may identify the number of the bay 255 in which the SAS device 254 is installed.
[0087] As another example, a particular compound ID 210 may correspond to a smart array 268. In this manner, the compound ID 210 may include an anchor ID 214 that uniquely identifies the smart array 268. The corresponding public ID 212 may identify the particular cage 274 in which the smart array 268 is installed and the particular number of the slot 270 within the cage 274.
[0088] According to some embodiments, the specific composite ID 210 may correspond to a network controller sideband interface (NC-SI) controller 285 and the public ID 212 may represent the specific slot 287 in which the NC-SI controller 285 is installed.
[0089] According to example embodiments, one or more composite IDs 210 may correspond to components of the computing device 110-1 that are not installed in a particular slot connector. For example, according to some embodiments, one or more composite IDs 210 may correspond to a universal serial bus (USB) connector 288. Additionally, according to some embodiments, one or more composite IDs 210 may correspond to a high-definition multimedia interface (HDMI) connector 289, one or more video graphics adapter (VGA) connectors 290, and the like.
[0090] One or more composite IDs 210 may correspond to power supplies 292 of computing device 110-1. In this manner, each power supply 292 may be connected to a specific power harness connector in a set of sequential harness connectors, and the public ID 212 of a specific power supply 292 may identify a specific power harness number of the power supply 292. As another example, according to some embodiments, one or more composite IDs 210 may correspond to fans 284 of computing device 110-1. In this manner, fans 284 of computing device 110-1 may be connected to different harnesses in a set of sequential harnesses. The public ID 212 of a specific fan 284 indicates the specific harness number to which the fan 284 is connected.
[0091] According to further example implementations, computing device 110 - 1 may have various and / or different components as specified herein and corresponding composite IDs 210 for those components.
[0092] like Figure 2 , according to an example embodiment, a process 200 for verifying a computing node state of a computing device 110-1 includes a computing state verification engine 157 determining (decision block 224) whether an actual computing state 201 matches a reference computing state 138. According to an example embodiment, the determination may involve determining whether each compound ID 220 of a node infrastructure reference set 138 has a matching compound ID 210 of the actual computing state 201. Furthermore, according to an example embodiment, the decision 224 of whether the actual computing state 201 matches the reference computing state 138 may involve determining whether there are additional compound IDs 210 of the actual node infrastructure set 200 that do not have corresponding compound IDs 220 in the node infrastructure reference set 138. The decision 224 may also involve determining whether configuration information 215 of the actual computing state 201 matches configuration information 221 of the reference computing state 138. According to an example embodiment, the composite ID and other configuration items may have a specific order in which these elements will appear in states 201 and 138 (e.g., in this order, DIMMs are listed before PCIe devices and NVMe devices, etc.).
[0093] Determining whether actual computing state 201 matches reference computing state 138 may involve determining a hash or hash value of reference computing state 138 and a corresponding hash value of actual computing state 201. According to an example implementation, if the hash values are the same, then a match has occurred. Otherwise, if the hash values are different, then actual computing state 201 is considered not to match reference computing state 138. According to further implementations, other means may be used to determine whether actual computing state 201 matches reference computing state 138.
[0094] According to an example embodiment, if the actual computing state 201 matches the reference computing state 138, the verification is passed, as depicted at reference numeral 224. Conversely, if the actual computing state 201 does not match the reference computing state 138, the verification is not passed, as depicted at reference numeral 239.
[0095] Figure 3 A process 300 is depicted for verifying a network infrastructure associated with a computing device 110-1 by a network infrastructure state verification engine 193 of a domain manager 190, according to an example implementation. The domain manager 190 may include one or more hardware processors 380 (e.g., CPUs) and a memory 384 that may store instructions 388 that, when executed by the domain manager 190, cause the domain manager 190 to perform the actions described herein. Further, according to an example implementation, execution of the instructions 388 by the one or more processors 380 causes the one or more processors 380 to form the network infrastructure state verification engine 193.
[0096] According to some embodiments, in combination Figure 1 refer to Figure 3 , the computing device 110-1 may be a plurality of computing devices (for example, including Figure 3 The computing devices 110-1 and 110-2 depicted in FIG. 1 and the computing devices 110-2 and the other computing devices 110 are one of a group of computing devices 100 located at a particular physical site 305 (e.g., a data center). Figure 3 As depicted in FIG. 3 , a given domain 304 may include computing devices 110 from one or more physical sites 305. Typically, computing devices 110 may be physically connected to a network structure 320. These connections may include logical connections 328 and physical and network connections 324. Figure 3 As depicted in FIG. 1 , the logical connection 328 and the physical network connection 324 are established through the intelligent I / O peripherals 180 of each computing device 110 .
[0097] According to an example embodiment, the reference network infrastructure state 302 of the network infrastructure associated with the computing device 110-1 may include an access point IP address 356. In this manner, according to an example embodiment, the access point IP address 356 may be an IP address of a first network component visible to the computing device 110-1. According to an example embodiment, the network infrastructure reference set 142 may further include data representing location information 357 associated with the computing device 110-1. Depending on the particular embodiment, the location information 357 may represent the location of the computing device 110-1, the location of the network access point device, or the location of the computing device 110-1 and the network access point device. For example, the location information 357 may represent a specific floor (e.g., the second floor), an office or suite number, a GNSS coordinate, an altitude, a data center identifier or location, a rack number, etc.
[0098] According to an example implementation, the reference network infrastructure state 302 may include other configuration information 358 of the network infrastructure associated with the computing device 110-1. For example, the other configuration information 358 may include configuration attributes such as computing device scaling policies, SDN connection standards of the computing device 110-1, SDS connection standards of the computing device 110-1, signatures of SDC machine instances of the computing device 110-1, and the like.
[0099] In accordance with process 300, network infrastructure state validation engine 193 determines (decision block 360) whether reference network infrastructure state 302 matches actual network infrastructure state 349. In this manner, actual network infrastructure state 349 may represent information collected by network infrastructure state validation engine 193 and include information such as data representing actual IP address 351 of network access point device of computing device 110-1, data representing location information 353 of computing device 110-1 and / or location information of network access point device, etc. In addition, actual network infrastructure state 349 may include other network information configuration information 354, such as the criteria for other information 358 of reference network infrastructure state 302 discussed above.
[0100] According to an example embodiment, for the purpose of comparing the actual network infrastructure state 349 with the reference network infrastructure state 302, the network infrastructure state verification engine 193 may determine whether the access point IP address 351 matches the access point IP address 356, whether the location information 353 matches the location information 357, and whether the other network infrastructure information 354 matches the other network infrastructure information 358. For example, if any information is not the same (e.g., a difference in the access point IP address, a difference in the location information, or a difference in other configuration information), a match may not occur. Pursuant to decision block 360, if a match does not occur, according to an example embodiment, the verification fails and the domain manager 190 does not allow the computing device 110-1 to join the cloud-based computing system 100, as depicted at reference numeral 366. If a match occurs, according to an example embodiment, the verification passes and the domain manager 190 allows the computing device 110-1 to join the cloud-based computing system 100, as depicted at reference numeral 363.
[0101] Figure 4 A process 400 is depicted that is performed by a computing state verification engine 157 of a computing device 110 in response to the startup of a computing device 110-1, according to an example embodiment. According to an example embodiment, the computing state verification engine 157 determines (decision block 428) whether the computing state of the computing device 110-1 has passed verification. If not, then in accordance with block 407, the computing state verification engine 157 isolates the computing device 110-1 from the cloud computing-based system 100 (block 408) and prevents the computing device 110-1 from migrating to any of the tenant runtime environments 120. In addition, according to an example embodiment, the computing state verification engine 157 may record (block 408) the verification failure. In this manner, according to an example embodiment, for example, the computing state verification engine 157 may update the audit log 136 with an entry detailing the verification failure. In addition, the computing state verification engine 157 may take one or more additional actions, such as, for example, transmitting (box 412) one or more alarm messages (e.g., transmitting the alarm message to a system administrator of the computing device 110-1, transmitting the alarm message to the domain manager 190, etc.).
[0102] In accordance with decision box 428, if the computing state verification engine 157 determines that the computing device 110-1 complies with the reference computing state 138, the computing state verification engine 157 sets up (block 434) one or more tenant runtime environments 120 and allows the computing device 110-1 to join the cloud-based computing system, as depicted in box 436.
[0103] Figure 5A Depicted is a diagram of a computational state verification engine 157 ( Figure 1) Example process 500 performed in response to a startup (eg, power on or reset of computing device 110-1). Figure 1 refer to Figure 5A According to an example implementation, process 500 includes computing state verification engine 157 determining (block 504) an anchor identifier of an infrastructure component of computing device 110-1 and determining (block 508) a public identifier of an infrastructure component of computing device 110-1. The computing state verification engine 157 may then determine a composite identifier based on the anchor identifier and the public identifier in accordance with block 512. The computing state verification engine 157 may further determine (block 514) other computing state information as described herein. The computing state verification engine 157 may then generate (block 516) data representing an actual computing state of computing device 110-1.
[0104] Figure 5B An example process 530 is depicted that may be performed by computing state verification engine 157 for the purpose of verifying that computing device 110-1 complies with a reference computing state, according to an example implementation. Figure 1 refer to Figure 5B According to an example embodiment, the computing state verification engine 157 determines (decision box 534) whether the reference computing infrastructure certificate of the specific computing device 110-1 is valid. Depending on the specific embodiment, the confirmation of the certificate can take into account multiple factors or criteria. For example, the computing state verification engine 157 can first evaluate the signature of the certificate. According to an example embodiment, in this way, an administrator with appropriate credentials for the computing device 110-1 can have a private part (or private key) of an asymmetric cryptographic key such as an RSA key. The administrator can cryptographically sign the certificate based on the private key and the content of the certificate. The content of the certificate can include, for example, the reference computing state of the computing device 110-1. Using the public part of the RSA key (i.e., the public key), the computing state verification engine 157 can verify the signature of the certificate by determining a hash value of the certificate content using the public key and comparing the resulting hash value with the signature. According to an example embodiment, if the two hashes are the same, the certificate signature has been verified.
[0105] According to example implementations, computing state verification engine 157 may consider one or more additional measures to verify a reference computing state certificate. For example, after verifying the signature of the certificate, computing state verification engine 157 may determine whether the signer has the appropriate credentials to issue the certificate, whether the signer's authorization to issue the certificate has been revoked, etc. In addition, for the purpose of verifying the certificate, computing state verification engine 157 may verify the content of the certificate.
[0106] In accordance with block 538, if the reference computing state certificate is invalid, the computing state verification engine 157 records the certificate verification failure and sets (block 539) a computing state verification failed indication to prevent the computing device 110-1 from migrating from the pre-boot environment to provide one or more tenant runtime environments 120. In accordance with decision block 534, if the reference computing state certificate is verified, the computing state verification engine 157 compares the actual computing state with the reference computing state as specified by the contents of the certificate (block 544). As determined at decision block 548, if the actual computing state matches the reference computing state, the computing state verification engine 157 records (block 540) that the computing state verification passed. Otherwise, in accordance with decision block 548, if the comparison of the actual computing state to the reference computing state fails, the computing state verification engine 157 records (block 550) that the computing state verification failed and sets (block 552) a computing state verification failed indication to prevent the computing device 110-1 from migrating from the pre-boot environment to one or more tenant runtime environments 120.
[0107] Fig. 6A Depicted is a diagram of a network infrastructure state verification engine 193 ( Figure 1 ) performs the example process 600. Figure 1 refer to Fig. 6A According to an example embodiment, the process 600 includes the network infrastructure state verification engine 193 determining (block 604) an IP address of a network access point of a computing device 110 and determining (block 608) location information associated with the respective computing device 110. Per block 614, according to an example embodiment, the network infrastructure state verification engine 193 may determine other network infrastructure state information, such as other network infrastructure information 354 ( Figure 3 ). According to block 616, the network infrastructure state verification engine 193 generates data representing the actual network infrastructure state of the computing device 110.
[0108] Figure 6B An example process 650 is depicted that is performed by the network infrastructure state verification engine 193 for the purpose of enforcing the state of the network infrastructure associated with the computing device 110-1 to comply with the corresponding reference network infrastructure state according to an example implementation. According to some implementations, the network infrastructure state verification engine 193 may perform the process 650 as part of determining whether to allow the computing device 110-1 to join the cloud-based computing system 100. Figure 1 refer to Figure 6B, the network infrastructure state verification engine 193 receives (block 654) or accesses data representing the actual network infrastructure state, and the network infrastructure state verification engine 193 compares the actual network infrastructure state to the reference network infrastructure state (block 662). If, based on the comparison, the network infrastructure state verification engine 193 determines (decision block 666) that the actual network infrastructure state matches the reference network infrastructure state, the network infrastructure state verification engine 193 allows (block 680) the computing device 110-1 to join the cloud-based computing system 100. Otherwise, if the network infrastructure state verification engine 193 determines (decision block 666) that the actual network infrastructure state does not match the reference network infrastructure state, the network infrastructure state verification engine 193 prevents (block 670) the computing device 110-1 from joining the cloud-based computing system 100.
[0109] Reference return Figure 1 , a component can potentially be hot-plugged into a hot-plug connector of computing device 110-1, and a component can potentially be hot-unplugged from a hot-plug connector of computing device 110-1. In this context, "hot plugging" refers to the actual or simulated installation of a component into a connector of computing device 110-1 while the connector is receiving power. Here, a "component" can be an actual hardware component or a virtual component. For example, an "actual" installation can correspond to the installation of a physical card or adapter into a physical connector of computing device 110-1. For example, a "simulated" installation can correspond to a hardware component (e.g., a PCIe adapter) providing an indication to an operating system or hypervisor that a particular function (e.g., a virtual PCIe function or a physical PCIe function) is now available or has been activated. "Hot unplugging" of a component refers to the actual or simulated removal of a component from a connector while power is provided to the connector. For example, a "actual" removal can correspond to the removal of a physical card or adapter from a physical connector of computing device 110-1. For example, a "simulated" removal may correspond to a hardware component (e.g., a PCIe adapter) providing an indication to an operating system or hypervisor that a particular function (e.g., a virtual PCIe function or a physical PCIe function) is no longer available or has been deactivated. Events corresponding to hot plugging of a component or hot unplugging of a component are referred to herein as "hot plug / hot unplug events." A component may be a physical component or a virtual component.
[0110] According to an example embodiment, BMC 123 utilizes OS bare metal runtime monitoring service 150 to intercept hot plug / hot unplug events and coordinates to handle the event. More specifically, in conjunction with the operating system 163 components of BIOS 165 and OS-bare metal runtime monitoring service 156, BMC 123 can handle hot plug / hot unplug events of computing device 110-1.
[0111] For example, according to some embodiments, when a component (e.g., a USB drive) is hot plugged into a connector (e.g., a USB connector) of computing device 110-1, BMC 123 detects the insertion of the component into the connector and alerts BIOS 165. BIOS 165 enumerates the components (e.g., allocates memory space for the components) and notifies operating system 163 of the presence of the components. Thereafter, operating system 163 may manage the components. A hot plug event may or may not comply with reference computing state 138. In this manner, reference computing state 138 may specify one or more conditions. For example, reference computing state 138 may specify that a particular hot plug connector will receive components with a particular identification, model, serial number, performance characteristics, features comparable to other installed components, and the like. As another example, reference computing state 138 may specify that a particular hot plug connector does not receive hot plug components.
[0112] The runtime monitoring service 150 (through its operating system 163 component) can detect when a particular component is hot-unplugged. For example, a component may be unexpectedly removed from its connector (i.e., an "accidental removal"). For this scenario, the operating system 163 is the first to detect the removal because the operating system 163 may be using the component. Depending on the configuration of the computing device 110-1, the computing device 110-1 may or may not accommodate hot-unplug events. For example, the computing device 110-1 may be configured to fail over from one DIMM (e.g., a DIMM that has failed and has been hot-unplugged) to a redundant DIMM. Conversely, hot-plugging a component (e.g., a DIMM) may cause the operating system 163 or application using the DIMM to crash. An accidental removal may or may not comply with the reference computing state 138.
[0113] The hot unplug event may or may not be detected by the operating system 163. For example, the computing device 110-1 may be configured with a resilient subsystem (e.g., a redundant array of inexpensive disks (RAID)) that includes redundant physical components (e.g., storage drives) behind logical components (e.g., logical units (LUNs)) such that if a given physical component fails, the subsystem may fail over to another physical component in a manner that is transparent to the operating system 163. For this scenario, the BMC 123 may be informed of the hot unplug event. Additionally, the hot unplug event may or may not comply with the reference computing state 138.
[0114] For various reasons, components may be hot-plugged and hot-unplugged from computing device 110-1. For example, a memory module (e.g., DIMM) or storage device (e.g., NVMe drive) may fail or may be upgraded, a memory module or storage device may be downgraded in capacity, etc. According to an example embodiment, reference computing state 138 contains data identifying information related to hot-plug / hot-unplug events in computing device 110-1 according to an example embodiment. For example, reference computing state 138 may specify a specific connector (e.g., a DIMM connector) in which hot-plugging and hot-unplugging are permitted, prohibit hot-plugging or hot-unplugging from a specific connector, etc. As a more specific example, for example, a specific connector slot may be associated with the redundant capability of computing device 110-1. As a more specific example, according to an example embodiment, reference computing state 138 may allow hot-plugging or hot-unplugging from a specified connector to occur and further specify a manufacturer, a specific serial number (and thus specifically identifies one or more permitted components), the permitted capacity of a component, etc.
[0115] Figure 7 A process 700 is depicted as being performed in association with an interrupt service routine for servicing an interrupt caused by a hot plug / hot unplug event according to an example embodiment. According to an example embodiment, the process 700 may be performed at least in part by the runtime monitoring service 150, and the process 700 may involve the BMC 123. Figure 1 refer to Figure 7 According to some embodiments, process 700 includes clearing (box 702) the corresponding interrupt flag and determining (box 704) the change in actual computing state caused by the hot plug / hot unplug event. In addition, according to box 704, process 700 may include updating the actual computing state as a result of the hot plug / hot unplug event. According to decision box 710, a determination is made whether the reference computing state permits the change in the actual computing state. In other words, according to example embodiments, decision box 710 may include determining whether computing device 110-1 is still complying with the reference computing state. If so, the interrupt routine service process 700 terminates. Otherwise, according to box 722, the runtime monitoring service 150 stops the operation of the cloud-based computing system 100 and isolates the computing device 110-1. In addition, according to example embodiments, according to box 726, the runtime monitoring service 156 may log the event and generate one or more appropriate alarm messages.
[0116] refer to Figure 8According to an example embodiment, in accordance with block 804, process 800 includes at least one hardware processor of a computing device executing instructions to force the computing device to comply with a reference operating state of the computing device. The computing device is part of a cloud-based computing system. Forcing compliance with the reference operating state includes determining, by the computing device, an actual computing state of the computing device in response to startup of the computing device. The actual computing state includes an actual physical topological arrangement of hardware components of the computing device, and the determination includes comparing the actual computing state to the reference computing state. Forcing compliance with the reference operating state includes controlling, by the computing device, whether the computing device is part of the cloud-based computing system in response to a result of the verification.
[0117] refer to Fig. 9 According to an example embodiment, the system 900 includes a connector 904 and a node 910. The connector 904 receives an intelligent input / output (I / O) peripheral device. The intelligent I / O peripheral device provides an I / O service associated with a cloud operator domain of a cloud-based computing system. The node 910 includes at least one central processing unit (CPU 920), a hardware component 918, and a memory 914. One or more CPUs 920 execute instructions 916 associated with a tenant runtime environment and associated with a cloud tenant domain. One or more CPUs execute instructions 916 to determine the actual computing state of the node based on an identifier of the hardware component 918 and a physical topological arrangement of the hardware component 918 in response to the startup of the node. One or more CPUs 920 are used to execute instructions 916 to verify whether the actual computing state complies with the reference computing state of the node 910. Verifying whether the reference computing state is complied with includes comparing the actual computing state with the reference computing state. One or more CPUs 920 are used to execute instructions 916 to control whether the node 910 is part of the cloud-based computing system in response to the result of the verification.
[0118] refer to Fig.10 According to an example embodiment, the non-transitory storage medium 1010 stores machine-readable instructions 1014, which, when executed by a machine, cause the machine to access data representing an actual network infrastructure state associated with a computing device. The actual network infrastructure state includes an address of a network access point associated with the computing device and a physical location associated with the computing device. The instructions 1014, when executed by the machine, further cause the machine to verify whether the actual network infrastructure state complies with a reference network infrastructure state of the computing device. The instructions 1014, when executed by the machine, further cause the machine to control whether the computing device is permitted to join the cloud-based computing system in response to the verification.
[0119] According to an example embodiment, the process further includes controlling whether the computing device sets up the cloud tenant runtime environment in response to the result.A particular advantage is that the computing device can protect the cloud computing system from security attacks that might otherwise originate from the computing device through actions taken on the computing device.
[0120] According to an example implementation, controlling whether a computing device is part of a cloud-based computing system includes allowing the computing device to become part of the cloud-based computing system. The process further includes determining whether to allow the hot plug event in response to a hot plug event associated with the computing device when the computing device is part of the cloud-based computing system. The process further includes controlling whether the computing device remains part of the cloud-based computing system in response to determining whether to allow the hot plug event. A particular advantage is that the computing device can protect the cloud computing system from security attacks that may otherwise originate from the computing device through actions taken on the computing device.
[0121] According to an example implementation, determining whether to allow a hot plug event for a computing device includes identifying a hot plug connector associated with the hot plug event and determining whether to allow the hot plug event based on the identification and an operational state of the hot plug connector. A particular advantage is that the computing device can protect the cloud computing system from security attacks that may otherwise originate from the computing device through actions taken on the computing device.
[0122] According to an example embodiment, determining the actual computing state includes determining a component inventory of the computing device. Determining the component inventory includes determining a first identifier of the hardware component. Determining the actual computing state further includes determining a composite identifier of the hardware component based on the physical topological location and the first identifier. Transmitting data representing the actual computing state includes transmitting data representing the composite identifier to a validator. A particular advantage is that the computing device can protect the cloud computing system from security attacks that may otherwise originate from the computing device through actions taken on the computing device.
[0123] According to an example embodiment, the first identifier comprises a cryptographic identifier.A particular advantage is that the computing device may, through actions taken on the computing device, protect the cloud computing system from security attacks that may otherwise originate from the computing device.
[0124] According to an example embodiment, a computing device includes a plurality of connectors capable of receiving hardware components. The connectors are arranged according to an order such that each connector has an associated index representing a position of the connector in the order, and a physical topological position identifies an associated index of the connector in which the hardware component is installed. A particular advantage is that the computing device can protect a cloud computing system from security attacks that might otherwise originate from the computing device through actions taken on the computing device.
[0125] According to an example embodiment, the physical topological location includes at least one of: a storage cage number, a storage slot number, a drive cage number, a drive bay number, a harness number, a bus connector number, a bus connector cage number, a port number, or a central processing unit (CPU) socket number. A particular advantage is that the computing device can protect the cloud computing system from security attacks that might otherwise originate from the computing device through actions taken on the computing device.
[0126] According to an example implementation, the process includes isolating the computing device from the cloud-based computing system in response to the result. A particular advantage is that the computing device can protect the cloud computing system from security attacks that might otherwise originate from the computing device through actions taken on the computing device.
[0127] While the present disclosure has been described with respect to a limited number of embodiments, those skilled in the art having the benefit of this disclosure will appreciate numerous modifications and variations therefrom. The appended claims are intended to cover all such modifications and variations.
Claims
1. A method for starting a computing device, comprising: At least one hardware processor of the computing device executes instructions to force the computing device to comply with a reference operating state of the computing device, wherein the computing device is part of a cloud-based computing system and forcing compliance with the reference operating state comprises, in response to the booting of the computing device: determining, by the computing device, an actual computing state of the computing device, wherein the actual computing state includes an actual physical topological arrangement of hardware components of the computing device, determining the actual computing state includes determining the physical topological arrangement of the hardware components, the computing device includes a plurality of physical locations in which the hardware components can be installed, and determining the physical topological arrangement of the hardware components includes identifying a particular physical location of the plurality of physical locations; verifying that the actual computing state complies with a reference computing state of the computing device, wherein the verifying comprises comparing the actual computing state to the reference computing state, and comparing the actual computing state to the reference computing state comprises comparing the particular physical location to a physical location of the reference computing state; In response to a result of the verifying, controlling, by the computing device, whether the computing device is part of the cloud-based computing system, including allowing the computing device to become part of the cloud-based computing system; and In response to the result of the verification, the computing device controls whether the computing device sets a cloud tenant runtime environment, Wherein, the method further comprises: In response to a hot plug event or a hot unplug event associated with the computing device when the computing device is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference computing state; and In response to determining whether the hot plug event or the hot unplug event complies with the reference computing state, controlling whether the computing device remains part of the cloud-based computing system.
2. The method of claim 1, further comprising: In response to the result of the verification, the computing device controls whether the computing device provides a cloud tenant runtime environment.
3. The method of claim 1, wherein: Determining whether the hot plug event or the hot pull event complies with the reference calculation state includes: Determining information describing the hot plug event or the hot unplug event, wherein the information includes at least one of: an identification of a connector associated with the hot plug event or the hot unplug event or an identification of a component associated with the hot plug event or the hot unplug event; and A determination is made based on the information whether the hot plug event or the hot unplug event complies with the reference computing state.
4. The method of claim 1, further comprising: In response to determining whether the hot plug event or the hot unplug event complies with the reference computing state, operation of the computing device is stopped.
5. The method of claim 1, wherein: The computing device includes a plurality of connectors capable of receiving the hardware component, the plurality of connectors being arranged according to a sequence such that each of the plurality of connectors has an associated index representing a position of the connector in the sequence, and the physical topological position identifies an associated index of a connector of the plurality of connectors in which the hardware component is installed.
6. The method of claim 1, wherein: The physical topological location includes at least one of a memory cage number, a memory slot number, a drive cage number, a drive bay number, a harness number, a bus connector number, a bus connector cage number, a port number, or a central processing unit (CPU) socket number.
7. The method of claim 1, wherein: Determining the actual computing state includes at least one of an identification of the hardware component or a category associated with the hardware component.
8. The method of claim 1, further comprising: Responsive to the result of the verifying, the computing device is isolated from the cloud-based computing system.
9. A method for starting a computing device, comprising: At least one hardware processor of the computing device executes instructions to force the computing device to comply with a reference operating state of the computing device, wherein the computing device is part of a cloud-based computing system and forcing compliance with the reference operating state comprises, in response to the booting of the computing device: determining, by the computing device, an actual computing state of the computing device, wherein the actual computing state includes an actual physical topological arrangement of hardware components of the computing device, determining the actual computing state includes determining the physical topological arrangement of the hardware components, the computing device includes a plurality of physical locations in which the hardware components can be installed, and determining the physical topological arrangement of the hardware components includes identifying a particular physical location of the plurality of physical locations; verifying that the actual computing state complies with a reference computing state of the computing device, wherein the verifying comprises comparing the actual computing state to the reference computing state, and comparing the actual computing state to the reference computing state comprises comparing the particular physical location to a physical location of the reference computing state; and In response to a result of the verifying, controlling, by the computing device, whether the computing device is part of the cloud-based computing system, including allowing the computing device to become part of the cloud-based computing system; Wherein, determining the actual computing state includes: determining a parts inventory of the computing device, wherein determining the parts inventory comprises determining a first identifier of the hardware part; and determining a composite identifier for the hardware component based on the physical topological location and the first identifier, Wherein, the method further comprises: In response to a hot plug event or a hot unplug event associated with the computing device when the computing device is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference computing state; and In response to determining whether the hot plug event or the hot unplug event complies with the reference computing state, controlling whether the computing device remains part of the cloud-based computing system.
10. The method of claim 9, wherein: The first identifier comprises a cryptographic identifier.
11. A system for starting a node, comprising: a connector for receiving an intelligent input / output (I / O) peripheral device, wherein the intelligent I / O peripheral device is used to provide I / O services associated with a cloud operator domain of a cloud-based computing system; and A node comprising at least one central processing unit (CPU), hardware components, and memory, wherein the at least one CPU is configured to execute instructions associated with an application operating environment and associated with a cloud tenant domain, and wherein the at least one CPU is configured to execute instructions in response to the launching of the node: determining an actual computing state of the node based on a physical topological arrangement of the hardware components and identifiers of the hardware components other than the physical topological arrangement; verifying that the actual computing state complies with a reference computing state of the node, wherein the verifying comprises comparing the actual computing state to the reference computing state; and In response to a result of the verifying, controlling whether the node is part of the cloud-based computing system, including allowing the node to become part of the cloud-based computing system, In response to a hot plug event or a hot unplug event associated with the node when the node is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference computing state; and In response to determining whether the hot-plug event or the hot-unplug event complies with the reference computing state, controlling whether the node remains part of the cloud-based computing system.
12. The system of claim 11, wherein: The physical topological location includes a slot number or a cage number associated with the hardware component.
13. The system of claim 11, wherein: The at least one CPU is configured to execute the instructions to determine to isolate the node from the cloud-based computing system in response to the result of the verifying.
14. The system of claim 11, wherein: The node includes multiple physical locations in which the hardware components can be installed, determining the physical topological arrangement of the hardware components includes identifying a specific physical location among the multiple physical locations, and verifying that the actual computing state complies with the reference computing state further includes comparing the specific physical location with the physical locations of the reference computing state.
15. A non-transitory storage medium for storing machine-readable instructions, which, when executed by a machine, cause the machine to perform the following operations: accessing data representing an actual network infrastructure state associated with the computing device, wherein The actual network infrastructure state includes a first address of a network access point associated with the computing device and a first physical location associated with the computing device; verifying that the actual network infrastructure state complies with a reference network infrastructure state of the computing device, wherein the verification comprises: verifying that the first address is the same as an address specified by the reference network infrastructure state, and verifying that the first physical location is the same as a physical location specified by the reference network infrastructure state; In response to the verification, controlling whether the computing device is permitted to join the cloud-based computing system, including allowing the computing device to become part of the cloud-based computing system; In response to a hot plug event or a hot unplug event associated with the computing device when the computing device is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference network infrastructure state; In response to determining whether the hot-plug event or the hot-unplug event complies with the reference network infrastructure state, controlling whether the computing device remains part of the cloud-based computing system; and determining a performance metric for a software defined network (SDN) connection associated with the computing device, Wherein verifying the compliance comprises comparing the performance standard with a reference standard of the reference network infrastructure state.
16. The storage medium according to claim 15, wherein: The instructions, when executed by the machine, further cause the machine to: determining a signature of a software defined computing (SDC) image of the computing device, Wherein verifying the compliance comprises comparing the signature to a reference signature of the reference network infrastructure state.
17. The storage medium according to claim 15, wherein: The instructions, when executed by the machine, further cause the machine to: determining computing device scaling criteria for said reference network infrastructure state, Wherein verifying the compliance comprises evaluating scaling of a cloud-based computing system associated with the computing device based on the computing device scaling criteria.
18. A non-transitory storage medium for storing machine-readable instructions, the machine-readable instructions, when executed by a machine, causing the machine to perform the following operations: accessing data representing an actual network infrastructure state associated with the computing device, wherein The actual network infrastructure state includes a first address of a network access point associated with the computing device and a first physical location associated with the computing device; verifying that the actual network infrastructure state complies with a reference network infrastructure state of the computing device, wherein the verification comprises: verifying that the first address is the same as an address specified by the reference network infrastructure state, and verifying that the first physical location is the same as a physical location specified by the reference network infrastructure state; In response to the verification, controlling whether the computing device is permitted to join the cloud-based computing system, including allowing the computing device to become part of the cloud-based computing system; In response to a hot plug event or a hot unplug event associated with the computing device when the computing device is part of the cloud-based computing system, determining whether the hot plug event or the hot unplug event complies with the reference network infrastructure state; In response to determining whether the hot-plug event or the hot-unplug event complies with the reference network infrastructure state, controlling whether the computing device remains part of the cloud-based computing system; and determining a geographic location associated with a software defined storage (SDS) connection associated with the computing device, Wherein verifying the compliance comprises comparing the geographic location to a geographic reference standard of the reference network infrastructure state.
Citation Information
Patent Citations
Discovering, validating, and configuring hardware-inventory components
CN104704775A
Secure OS boot as per reference platform manifest and data sealing
CN109614769A