Verified boot of container images for hypervisor multi-container platform

A container verified boot engine using hash trees and cryptographic keys verifies the integrity of container images, addressing the vulnerability of hypervisor multi-container platforms by ensuring secure and authentic boot processes.

WO2026050915A1PCT designated stage Publication Date: 2026-03-12QUALCOMM INC +5
View PDF 1 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-09-04
Publication Date
2026-03-12

AI Technical Summary

Technical Problem

Existing hypervisor multi-container platforms lack effective methods to verify the integrity and authenticity of container images during the boot process, as bootloaders and hypervisors cannot access container partitions, leaving them vulnerable to unauthorized software installations.

Method used

Implement a container verified boot engine that utilizes a hash tree-based verification mechanism, leveraging public and private keys to authenticate and verify the integrity of container file systems, extending the secure boot process to include container images.

Benefits of technology

Ensures the authenticity and integrity of container images are verified during boot, enhancing security by preventing unauthorized software execution and maintaining a chain of trust within hypervisor multi-container platforms.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024116737_12032026_PF_FP_ABST
    Figure CN2024116737_12032026_PF_FP_ABST
Patent Text Reader

Abstract

Systems and techniques are provided for a booting a container. For instance, a process can include obtaining, from a first verified boot metadata partition of a host operating system, a first public key associated with a container; verifying a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container; accessing the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; and verifying the first file system of the container based on the first hash tree for the first file system of the container.
Need to check novelty before this filing date? Find Prior Art

Description

VERIFIED BOOT OF CONTAINER IMAGES FOR HYPERVISOR MULTI-CONTAINER PLATFORM

[0001] FIELD OF THE DISCLOSURE

[0002] The present disclosure generally relates to verified boot (e.g., secure boot) . For example, aspects of the present disclosure relate to systems and techniques for verified boot of container images (e.g., for hypervisor multi-container platforms) .

[0003] BACKGROUND OF THE DISCLOSURE

[0004] Computing devices typically store sensitive data owned by users or enterprises, with firmware or operating system software on the computing devices owned by a computing device or secure module manufacturer. To help secure computing devices, the firmware or software may include security measures to protect against, e.g., removing brute force attack mitigations, disabling secure boot / trust boot, and / or loading other unauthenticated firmware or software on the computing devices. As an example, certain platforms may support executing software using containers. Containers may be standalone software packages that include everything needed to execute the software, such as the code, runtime, libraries, etc. Software executing in the container may use a host system’s operating system kernel. Executing software from containers allows the software to execute in isolated environments to help enhance security of both the software executing in the container and the overall platform.SUMMARY

[0005] The following presents a simplified summary relating to one or more aspects disclosed herein. Thus, the following summary should not be considered an extensive overview relating to all contemplated aspects, nor should the following summary be considered to identify key or critical elements relating to all contemplated aspects or to delineate the scope associated with any particular aspect. Accordingly, the following summary has the sole purpose to present certain concepts relating to one or more aspects relating to the mechanisms disclosed herein in a simplified form to precede the detailed description presented below.

[0006] Disclosed are systems, methods, apparatuses, and computer-readable media for booting a container. In one illustrative example, an apparatus for booting a container is provided. The  apparatus includes: at least one memory; and at least one processor coupled to the at least one memory. The at least one processor is configured to: obtain, from a first verified boot metadata partition of a host operating system, a first public key associated with a container; verify a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container; access the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; and verify the first file system of the container based on the first hash tree for the first file system of the container.

[0007] As another example, a method for booting a container is provided. The method includes: obtaining, from a first verified boot metadata partition of a host operating system, a first public key associated with a container; verifying a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container; accessing the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; and verifying the first file system of the container based on the first hash tree for the first file system of the container.

[0008] In another example, a non-transitory computer-readable medium is provided. The -transitory computer-readable medium has stored thereon instructions that, when executed by at least one processor, cause the at least one processor to: obtain, from a first verified boot metadata partition of a host operating system, a first public key associated with a container; verify a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container; access the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; and verify the first file system of the container based on the first hash tree for the first file system of the container.

[0009] As another example, an apparatus for booting a container is provided. The apparatus includes: means for obtaining, from a first verified boot metadata partition of a host operating  system, a first public key associated with a container; means for verifying a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container; means for accessing the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; and means for verifying the first file system of the container based on the first hash tree for the first file system of the container.

[0010] Aspects generally include a method, apparatus, system, computer program product, non-transitory computer-readable medium, user device, user equipment, wireless communication device, and / or processing system as substantially described with reference to and as illustrated by the drawings and specification.

[0011] Some aspects include a device having a processor configured to perform one or more operations of any of the methods summarized above. Further aspects include processing devices for use in a device configured with processor-executable instructions to perform operations of any of the methods summarized above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a device to perform operations of any of the methods summarized above. Further aspects include a device having means for performing functions of any of the methods summarized above.

[0012] In some aspects, one or more of the apparatuses described herein comprises a mobile device (e.g., a mobile telephone or so-called “smart phone” , a tablet computer, or other type of mobile device) , a wearable device, an extended reality device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device) , a personal computer, a laptop computer, a video server, a television (e.g., a network-connected television) , a vehicle (or a computing device of a vehicle) , or other device. In some aspects, the apparatus (es) includes at least one camera for capturing one or more images or video frames. For example, the apparatus (es) can include a camera (e.g., an RGB camera) or multiple cameras for capturing one or more images and / or one or more videos including video frames. In some aspects, the apparatus (es) includes at least one display for displaying one or more images, videos, notifications, or other displayable  data. In some aspects, the apparatus (es) includes at least one transmitter configured to transmit one or more video frame and / or syntax data over a transmission medium to at least one device. In some aspects, the at least one processor includes a neural processing unit (NPU) , a neural signal processor (NSP) , a central processing unit (CPU) , a graphics processing unit (GPU) , any combination thereof, and / or other processing device or component.

[0013] The foregoing has outlined rather broadly the features and technical advantages of examples according to the disclosure in order that the detailed description that follows may be better understood. Additional features and advantages will be described hereinafter. The conception and specific examples disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Such equivalent constructions do not depart from the scope of the appended claims. Characteristics of the concepts disclosed herein, both their organization and method of operation, together with associated advantages will be better understood from the following description when considered in connection with the accompanying figures. Each of the figures is provided for the purposes of illustration and description, and not as a definition of the limits of the claims. The foregoing, together with other features and aspects, will become more apparent upon referring to the following specification, claims, and accompanying drawings.

[0014] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification of this patent, any or all drawings, and each claim.BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings are presented to aid in the description of various aspects of the disclosure and are provided solely for illustration of the aspects and not limitation thereof. So that the above-recited features of the present disclosure can be understood in detail, a more particular description, briefly summarized above, may be had by reference to aspects, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only certain typical aspects of this disclosure and are therefore not to be  considered limiting of its scope, for the description may admit to other equally effective aspects. The same reference numbers in different drawings may identify the same or similar elements.

[0016] FIG. 1 is a block diagram illustrating a boot chain for an operating system, in accordance with aspects of the present disclosure;

[0017] FIG. 2 is a block diagram illustrating an architecture of a hypervisor container platform, in accordance with aspects of the present disclosure;

[0018] FIG. 3 is a block diagram illustrating a logical organization of a hypervisor container platform, in accordance with aspects of the present disclosure;

[0019] FIG. 4 is a block diagram illustrating a boot sequence for containers with verified boot, in accordance with aspects of the present disclosure;

[0020] FIG. 5 is a sequence diagram illustrating a sequence for enabling the dm-verity features for containers with verified boot, in accordance with aspects of the present disclosure;

[0021] FIG. 6 is a sequence diagram illustrating an alternate sequence for enabling the dm-verity features for containers with verified boot, in accordance with aspects of the present disclosure;

[0022] FIG. 7 is a flow diagram illustrating an example of a process for booting a container, in accordance with some examples; and

[0023] FIG. 8 is a block diagram illustrating an example of a computing system, which may be employed by the disclosed systems and techniques, in accordance with some examples.DETAILED DESCRIPTION

[0024] Certain aspects of this disclosure are provided below for illustration purposes. Alternate aspects may be devised without departing from the scope of the disclosure. Additionally, well-known elements of the disclosure will not be described in detail or will be omitted so as not to obscure the relevant details of the disclosure. Some of the aspects described herein may be applied independently and some of them may be applied in combination as would be apparent to those of skill in the art. In the following description, for the purposes of explanation, specific details are set  forth in order to provide a thorough understanding of aspects of the application. However, it will be apparent that various aspects may be practiced without these specific details. The figures and description are not intended to be restrictive.

[0025] The ensuing description provides example aspects, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the example aspects will provide those skilled in the art with an enabling description for implementing an example aspect. It should be understood that various changes may be made in the function and arrangement of elements without departing from the scope of the application as set forth in the appended claims.

[0026] The term “computing device” is used herein to refer to any of a variety of computing devices including smartphones, wireless or mobile computing devices (e.g., tablets, laptops, wearable devices, etc. ) , cellular-based wireless hotspots, IoT devices, eMTC devices, desktops, workstations, serves, embedded systems of electromechanical systems (e.g., vehicles, industrial and agricultural machinery, medical devices, control systems, etc. ) , and the like. Wireless communication devices are also commonly referred to as user equipment (UE) , mobile devices, and cellular devices. Computing devices may receive and / or transmit communications via a variety of wired and / or wireless communication networks, including wide area networks (e.g., mobile communication networks) , local area networks (e.g., Wi-Fi, Bluetooth, etc. ) , geolocation networks (e.g., Global Positioning System ( “GPS” ) ) , personal area networks (e.g., Wireless USB, Bluetooth, ZigBee, etc. ) , near-field communication, etc.

[0027] In some cases, device manufacturers may equip their devices with secure boot features that could be used to prevent criminals and nefarious actors from using flashing tools, OEM over-the-air software updates, or other similar technologies to install unauthorized or unauthenticated software images on the device.

[0028] Secure boot may be a security feature where each software image in a boot sequence is authenticated by a different previously verified software image. As such, secure boot builds a chain of trust, starting with a first piece of software that operates from non-volatile storage or read-only-memory (ROM) . The first piece of software, which in certain software architectures is referred to as the first ROM bootloader or a primary bootloader (PBL) , verifies a signature of the next  bootloader in the chain, which may, in turn, cryptographically verify the signature of the next software image, which may be a feature-rich application bootloader that is specific to the operating system that will subsequently be loaded on the mobile device. These operations may be repeated until all the of software images in the boot sequence, and the operating system, are evaluated, installed, discarded, loaded or executed on the mobile device. In some cases, the bootloader may not be able to access images inside of hypervisors or partitions inside containers. A partition may be a logical division of storage space (e.g., virtual disk) of a container into separate sections. In some cases, a hypervisor may be able to verify images of virtualized machines. However, the hypervisor and / or bootloader may not be able to access partitions of containers.

[0029] Systems, apparatuses, electronic devices, methods (also referred to as processes) , and computer-readable media (collectively referred to herein as “systems and techniques” ) are described herein for accessing containers. For example, systems and techniques can verify that authenticity and / or integrity of a container when booting (e.g., starting) the container. In some cases, a container system for operating / managing / booting containers may execute on a host operating system. This host operating system may be virtualized via a hypervisor and the hypervisor may be executing on hardware without using an operating system (e.g., as a type 1 hypervisor) . The host operating system may include a verified boot metadata (e.g., vbmeta) partition that includes information for verifying the host operating system, as well as a chained partition indicator, such as a public key, for a chained partition. The chained partition indicator may identify a partition that may also be verified for booting. The chained partition indicator may also delegate authority for verifying a partition for booting to another service, such as a hypervisor system or container system.

[0030] A service of the host operating system may access the vbmeta partition of the host operating system to obtain the public key for a chained partition of a container. The service of the host operating system may then access a vbmeta partition of the container associated with the public key and verify the vbmeta partition of the container using the public key. The vbmeta partition may be signed using a private key of the container associated with the public key. In some cases, the vbmeta partition of the container may also include a public key (e.g., another chained partition indicator) for a supervisor vbmeta partition of the container. In such cases, the service of  the host operating system may access a vbmeta partition of the supervisor partition and verify the vbmeta of the supervisor partition using the public key of the supervisor vbmeta partition.

[0031] In some cases, the vbmeta partition of the container may include a hash tree for a file system of the container (e.g., a partition such as the vendor partition) . The hash tree may be a tree of hash values, where nodes of the hash tree include the hash values and the hash values correspond a hash of a block of a linear device represented by the hash tree. The service of the host operating system may access the file system of the container and verify the file system of the container. Similarly, the supervisor vbmeta partition may include a hash tree for a file system of a supervisor partition of the container. The service of the host operating system may access the file system of the supervisor partition of the container and verify the file system of the supervisor partition of the container.

[0032] Various aspects of the application will be described with respect to the figures.

[0033] The term “hypervisor” is used herein to refer to any hardware or software component that supports virtualization technology and / or enables the abstraction (or virtualization) of computing resources, and which operates within an execution environment (e.g., within the rich / normal execution environment, etc. ) . A hypervisor may create and operate virtual machines (VMs) and / or host multiple operating systems (called guest operating systems) and may act as Virtual Machine Manager. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Each guest operating system may interact with the virtual operating platform as if it was operating on the physical hardware. This allows each guest operating system to operate under the illusion of having exclusive access to the processors, peripherals, memory and I / O of the computing system.

[0034] The term “monitor” is used herein to refer to any hardware or software component that may support virtualization technology and / or enables the abstraction (or virtualization) of computing resources, and which operates across execution environments (e.g., across a non-secure or rich / normal execution environment and a trusted / secure execution environment, etc. ) . This is used herein as the highest privilege level execution environment. A monitor may include any one or all of hardware monitors, specialized hardware fabricated on the chip, virtual machine monitors (VMMs) , monitor software running outside of a high level operation system (HLOS) ,  and software monitors running as part of device drivers, which may be outside the HLOS, its memory management systems, and / or its allocator functions. In some aspects, an example of a monitor is a “secure monitor, ” which refers to software that is designed to securely transition a processor between different security states of the processor (e.g., when supported such as in ARM processors with TrustZone technology) in order to separate the software running at lower privilege levels.

[0035] FIG. 1 is a block diagram illustrating a boot chain 100 for an operating system, in accordance with aspects of the present disclosure. In some cases, a bootloader (e.g., PBL) for a device may access a verified boot metadata (vbmeta) 102 partition of a memory and use the vbmeta 102 partition to verify the authenticity of other memory partitions on the device. The vbmeta 102 partition may include a vbmeta data structure. The vbmeta data structure may include verification information for verified boot of partitions and may include descriptors (and other metadata) , such as hashes / hash trees for partitions of a file system of the device that may be used to boot the device. The vbmeta 102 partition may be cryptographically signed via a vbmeta signature 104 and the bootloader may verify an authenticity of the vbmeta 102 partition by checking (e.g., hashing) the vbmeta signature 104 with key0. In some cases, key0 may be based on a set of values stored in hardware embedded one-time programmable bits (e.g., fuses) that once “blown” cannot be readily reverted to an “unblown” state. These one-time programmable bits may be written by the OEM / ODM as a part of a manufacturing process (e.g., during configuration, testing, etc. ) . Verifying the vbmeta signature104 with key0 indicates that the bootloader may trust the hash / hash trees for additional partitions stored in the vbmeta 102 partition, such as the hash for the boot partition 106.

[0036] The kernel may also verify the boot partition 106, system partition 108, and vendor partition 110 using, for example, a dm-verity feature in the kernel. The dm-verity feature may generate a hash / hash tree for those partitions and comparing the generated hash / hash tree against the hash / hash tree metadata stored in the vbmeta 102 partition. In some cases, the bootloader may verify hashes and a device-mapper-verity (dm-verity) feature may verify hash trees. The dm-verity feature may look at blocks of the underlying storage layer of the file system to determine if these blocks match an expected configuration (e.g., the block tree) . The dm-verity feature may hash  blocks of an image, such as a system image and compare these hashes to expected hashes from the block tree. In some cases, as hash values may be stored in a tree of pages, if a top-level “root” hash matches an expected hash from the hash tree, the rest of the tree may be verified.

[0037] In some cases, the vbmeta 102 partition may also include a chained partition indicator 112 indicating another partition (e.g., xyz partition114) in the boot chain 100 to verify. The chained partition indicator 112 may also include a public key 116 of the xyz partition 114 and information that allows the bootloader to locate the xyz partition 114 along with a footer of the xyz partition 114. The footer of the xyz partition 114 may include a vbmeta structure for the xyz partition 114 along with a hash tree for the xyz partition 114 signed using the private key of the xyz partition 114. The bootloader may verify the xyz partition 114 based on the public key of the xyz partition114. Additional partitions may be verified in a substantially similar manner.

[0038] In some cases, the vbmeta structure and / or partition may include the chained partition indicator (e.g., description) which may be used to create a link between a partition, such as xyz partition 114, and a public key. The chain partition indicator may also delegate authority to verify a partition, such as to a hypervisor service or container system. For example, the bootloader may only be able to verify a vbmeta and boot partition used by a hypervisor and may not be able to verify the system image used by the hypervisor. In such cases, boot verification may be delegated to a service of the hypervisor, such as a verified boot service of the hypervisor, such as QVB. The verified boot service of the hypervisor may boot a guest OS and pass along parameters to a feature of a kernel of the guest OS. chained to verify a vbmeta and hash image or partition of a guest OS. The feature of the guest OS kernel (e.g., dm-verity feature of Android verified boot) that may provide integrity checking of block devices using a cryptographic digest provided by the kernel crypto API and the verified boot service that may be used as a part of verified boot.

[0039] To help isolate software packages and provide flexibility with respect to usage of available computing resources, certain systems, such as mission critical and / or real-time systems like automotive software systems, may use a hypervisor container platform. FIG. 2 is a block diagram illustrating an architecture 200 of a hypervisor container platform, in accordance with aspects of the present disclosure. In FIG. 2, a SoC 202 may execute a hypervisor 204. In some cases, the hypervisor may be a type 2 hypervisor which does not need to be installed on a host  operating system (OS) . The host operating system may be an operating system from which containers or virtual machines may be executed. In some cases, the hypervisor 204 may be integrated with components typically found in an OS, such as those for interacting with hardware components and the SoC 202 may boot the hypervisor 204 rather than a general purpose OS. In some cases, the hypervisor 204 may be a hypervisor container platform. A hypervisor container platform may integrate container management and operation along with traditional virtualization of a hypervisor to allow both virtual machines (VMs) and containers to be deployed. Providing both VMs and containers may allow for increased flexibility for resource allocation and management and / or the ability to run containerized applications along with other software directly in a virtualized environment.

[0040] In FIG. 2, the hypervisor 204 may access a boot image 206 to start a virtualized guest OS 208. The guest OS 208 may include a container provider 210 which may execute one or more containers, such as containers 212A, 212B, …212N (collectively containers 212) . The containers 212 may share the guest OS’s 208 kernel but run in isolated spaces. Each container 212 may have their own root file system 214A, 214B, …214N (collectively rootfs 214) .

[0041] In some cases, a secure boot process may pass feature parameters, such as parameters for dm-verity, to a kernel of a guest OS, such as a guest boot dm-init driver. The dm-verity may provide integrity checking of block devices using a cryptographic digest.

[0042] In some cases, while the guest OS 208 boot image 206 is verified, there may not yet exist a way to verify the integrity of the rootfs 214 of the containers 212. For example, the bootloader may not have access into containers and existing solutions ineffective as containers may share access to a guest OS kernel. To allow container images within a virtualized guest OS to be verified, a container verified boot engine 216 (e.g., AVBLoader) may be included with the guest OS (e.g., as a part of the container provider 210) . In some cases, the container verified boot engine 216 may be chained to extend secure boot to containers of a hypervisor container platform.

[0043] FIG. 3 is a block diagram illustrating a logical organization 300 of a hypervisor container platform, in accordance with aspects of the present disclosure. In FIG. 3, a bootloader 302 of a device may verify a vbmeta 304 partition of bootloader 302 and other partitions of a hypervisor 306 in a manner substantially similar to that discussed above with respect to FIG. 1. The hypervisor  306 may include a verified boot service 308. The verified boot service 308 may include a software verified boot library 310 (e.g., LibAVB) . The verified boot library 310 may include software tools (e.g., features) that may be used for verified boot, such as a dm-verity. The dm-verity feature, as discussed above, may be used to verify a system image of another system, such as a virtualized guest OS 312 that may be booted by the hypervisor 306. For example, as indicated above, a bootloader may verify a vbmeta and boot partition of the guest OS 312. The dm-verity feature may then be chained to verify the system image of the guest OS 312 using a public key 314 of the guest OS 312 in the vbmeta 304 partition of the hypervisor 306. The dm-verity feature may verify the system partition of the guest OS 312 using the public key 314 of the guest OS 312 against a hash tree of the system partition stored in the vbmeta 304 partition of the hypervisor 306.

[0044] The guest OS 312 may support running containers and the guest OS 312 may include a guest OS root file system 316 for booting, managing, controlling, etc. the guest OS 312. The guest OS root file system 316 may include the system image / partition for the guest OS 312, which includes the code, library, services of the guest OS 312. The guest OS root file system 316 may include a container verified boot engine 321 and a DP loader service 334. The container verified boot engine 320 may boot one or more containers, such as container 318. In some cases, the guest OS root file system 316 may be executing in a kernel space of the guest OS 312 and was verified by the hypervisor 306 against tampering. Upon starting a container (e.g., container 318) , the DP loader service 334 may parse a container rootfs (super image) to load logic partition, system 336 and vendor 338 logic partitions of a container system boot metadata boot partition 332. The DP loader service 334 may also create dm-liner device dm-0 and dm-1 for the system 336 and vendor 338 partitions The DP loader service 334 may also use a dm-verity IOCTL API to create a dm-verity device for the container 318. The dm-verity device may be used to verify the

[0045] In some cases, a container 318 may include a vbmeta 328 and a vbmeta_system 330 partition. In some cases, a vbmeta 328 partition may be configured to chain additional partitions (e.g., vbmeta_system 330) to update other partitions without changing the top-level vbmeta 328 partition. In some cases, the vbmeta 328 partition may include a hash-tree and public key for the system image of the container and the vbmeta_system 330 partition may include a hash-tree and public key for a system image of a container system 332. The container verified boot engine 320  may include a feature for verifying the vbmeta 328 and vbmeta_system 330 partitions, such as an AVBLoader feature. In some cases, software tools (e.g., features) may be used to verify linear devices for verified boot, such as dm-verity device. The dm-verity device may be used to verify the system images, as well as other images (e.g., vendor, product, system_ext, odm, etc. ) for the container 318 and the container system 332. The dm-verity feature may hash specified images and compare the hashes to corresponding hash trees to verify the container 318 and container system 332.

[0046] FIG. 4 is a block diagram illustrating a boot sequence for containers with verified boot 400, in accordance with aspects of the present disclosure. For verified boot of a container, a guest OS 402 may include a container verified boot engine 404 (e.g., container loader or service, such as container_avb service, AVBLoader service, etc. ) that may be used to load and verify a container.

[0047] To verify a container, the container verified boot engine 404 may access a guest OS vbmeta 406 (e.g., of guest OS 208 of FIG. 2, guest OS 312 of FIG. 3, etc. ) . The guest OS vbmeta 406 may include (e.g., in a chained partition indicator) a public key 408 of a container vbmeta 410 partition of a container along with location information for the partitions used by the container. In some cases, the container vbmeta 410 partition may be cryptographically signed via a private key of the container and the container verified boot engine 404 may verify the signature using the public key 408 to verify the container vbmeta 410 partition. In some cases, the container vbmeta 410 partition may include a hash tree for a file system partition (s) used by the container, such as a hash tree for a container vendor partition 412. The container verified boot engine 404 may obtain the hash tree for the container vendor partition 412 and may also obtain location information for the partition.

[0048] In some cases, the container verified boot engine 404 may be delegated to verify partitions of a container via chained partition indicators. For example, the container vbmeta 410 partition may also include a chained partition indicator, such as a public key 414, for a supervisor partition vbmeta 416 partition (e.g., system vbmeta partition) for the container. The container verified boot engine 404 may verify a signature of the supervisor partition vbmeta 416 partition using the public key 414 in a manner substantially similar to verifying the container vbmeta 410 partition. In some cases, the supervisor partition vbmeta 416 partition may include a hash tree for  partition (s) used by the supervisor partition, such as a hash tree for a system partition 418 of the supervisor partition. The container verified boot engine 404 may obtain the hash tree for the system partition 418.

[0049] In some cases, the container verified boot engines 404 includes a container AVB service (AVBLoader) and DPLoader service (DPLoader) 420. In some cases, the AVBLoader service may be used to verify a guest OS vbmeta 406, include the container vbmeta 410 partition images and 416. The DPLoader service may be used to parse container super image (container type LA) to logic partitions, such as a system 424 partition, and vendor 426 partition. The DPLoader service may then create a dm-liner device dm-0 (e.g., dm-1 430 for the system 424 partition and dm-2 432 for the vendor 426 partition) and dm-1 (e.g., dm-3 434 for the system 424 partition and dm-4 436 for the vendor 426 partition) for the system 424 partition and the vendor 426 partition. The DPLoader service 420 may then use the dm-verity IOCTL API to create dm-verity service 422 (e.g., dm-verity device) In some cases, the DPLoader service 420 may use a dm-linear service 422 to map a linear range of the indicated partitions (e.g., system 424 partition, and vendor 426 partition) device onto a linear range of another device (e.g., a linear range of a memory accessible to the container) to provide access to the indicated partitions, such as a mapped system 424 partition and a mapped vendor 426 partition. The container verified boot engine 404 may enable a dm-verity service 428 to verify the mapped system 424 partition and the mapped vendor 426 partition. In some cases, the dm-verity service 428 may verify the mapped system 424 partition and the mapped vendor 426 partition by looking at blocks of the mapped system 424 partition and the mapped vendor 426 partition to determine if these blocks match an expected configuration indicated by the hash tree for a container vendor partition 412 and the hash tree for a system partition 418. In some cases, the dm-verity feature may be enabled for container file systems using different techniques.

[0050] FIG. 5 is a sequence diagram illustrating a sequence for enabling the dm-verity features for containers with verified boot 500, in accordance with aspects of the present disclosure. In FIG. 5, a container verified boot engine 502 may start 504 a DPLoader service 506 after the container verified boot engine 502 has accessed the partitions indicated by the hash trees in vbmeta partitions (e.g., container vbmeta 410 partition, supervisor partition vbmeta 416 partition, etc. ) . The  DPLoader service 506 may parse the partitions indicated by the hash trees in vbmeta partitions to create dm linear devices 508 for the partitions. For example, the DPLoader service 506 may determine what linear devices are used by a partition and create logical linear devices and map the linear devices used by the partitions to the created logical linear devices. In some cases, a linear device may be a linear range of blocks of a storage device that may be used, for example, as a file system and the DPLoader service 506 may map blocks of the linear devices used by the partitions to blocks of a storage device accessible by the container. The DPLoader service 506 may then indicate that the logical linear devices have been created to an LXC service 512. The LXC service 512 may be a runtime library that includes tools, templates, library and language bindings, etc. and the LXC service 512 may be used to mount 514 the logical linear devices (e.g., mapped system 424 partition and the mapped vendor 426 partition) . Mounting 514 the logical linear devices associates the logical linear devices with appropriate locations in a file system of the containers. After mounting 514 the logical linear devices, the container may be booted 516. During boot of the container, a first stage may be initialized 518 to create (e.g., initiate) dm-verity devices 520 for a file system (e.g., partitions represented by hash trees in the vbmetas) of the container. For example, dm-verity parameters may be obtained from the vbmeta of the container (e.g., container vbmeta 410 partition of FIG. 4) . A kernel of the host OS may be called (e.g., via a dm-ioctl API) to setup a dm-verity device (e.g., enable dm-verity) for the container. The dm-verity device may be a logical linear device that uses dm-verity to verify blocks of the logical device (e.g., file system for the container) . In some cases, nodes of the hash tree may correspond to blocks of the logical linear device and a hash in a node may correspond to an expected hash for the block. In some cases, a higher-level node may be a hash of expected hashes of lower level nodes. A top-level hash may be a based on all of the hashes in the hash tree and verifying a top-level hash may verify the entire logical linear device. A container_dm service 522 may then mount 524 the file system for the container.

[0051] In some cases, creating the dm-verity device for the mapped partitions allows the container to execute on the logical linear devices. In some cases, dm-verity cannot provide runtime detection of verity device. While verity devices may be mounted 524 after container boot 516, the mounting 524 operation may read superblock information of blocks, and dm-verity will may detect integrity of that block. In some cases, the superblock information may be metadate for a file system  metadata and the superblock information may defines the file system type, size, status, and information about other metadata structures (metadata of metadata) . However, blocks out of a range of a superblock may be tampered with and dm-verity may not detect such tampering.

[0052] FIG. 6 is a sequence diagram illustrating an alternate sequence for enabling the dm-verity features for containers with verified boot 600, in accordance with aspects of the present disclosure. In FIG. 6, a container verified boot engine 602 may start 604 a DPLoader service 606 after the container verified boot engine 602 has accessed the partitions indicated by the hash trees in vbmeta partitions (e.g., container vbmeta 410 partition, supervisor partition vbmeta 416 partition, etc. ) . The DPLoader service 606 may parse the partitions indicated by the hash trees in vbmeta partitions to create dm linear devices 608 for the partitions. The DPLoader service 606 may also obtain dm-verity parameters from the vbmeta (s) and enable (e.g., create, initiate) dm-verity devices for the partitions (e.g., system and vendor partitions) . After the dm-verity devices are ready, an LXC service 612 may be used to launch the container. The container 616 may then be booted. In some cases, the alternate sequence for enabling the dm-verity features shown in FIG. 6 may allow a lxc. service of a host OS to directly mount dm-verity devices, so the container 616 may be running in dm-verity devices to provide the runtime detection.

[0053] In some cases, anti-rollback protection may be supported for the host OS and container verified images. For example, anti-rollback protection may be implemented by using roll-back protected memory block (RPMB) storage to record a most recent version number associated with the Anti-Rollback Protection for the host OS and verified containers on a per partition basis. In some cases, the most recent version number may be stored in the partitions of the container and in the RPMB storage. Upon boot, the most recent version number of a partition may be verified as against the most recent version number in the RPMB for the partition. If the most recent version number of the partition is lower than the most recent version number in the RPMB for the partition, booting the container may be stopped or not started (e.g., refused) .

[0054] FIG. 7 is a flow diagram illustrating an example of a process 700 for booting a container, in accordance with aspects of the present disclosure. The process 700 may be performed by a computing device (or apparatus) (e.g., computing system 800 of FIG. 8) or a component (e.g., a chipset, codec, processor 810 of FIG. 8, etc. ) of the computing device. The computing device may  be a mobile device (e.g., a mobile phone) , a network-connected wearable such as a watch, an extended reality (XR) device such as a virtual reality (VR) device or augmented reality (AR) device, a vehicle or component or system of a vehicle, or other type of computing device. The operations of the process 700 may be implemented as software components that are executed and run on one or more processors.

[0055] At block 702, the computing device (or component thereof) may obtain, from a first verified boot metadata partition (e.g., guest OS vbmeta 406 of FIG. 4) of a host operating system, a first public key (e.g., public key 408 of FIG. 4) associated with a container (e.g., containers 212 of FIG. 2) . In some cases, the host operating system executes in a virtual machine. In some examples, the virtual machine is verified by a hypervisor before boot of the virtual machine.

[0056] At block 704, the computing device (or component thereof) may verify a second verified boot metadata partition (e.g., container vbmeta 410 partition of FIG. 4) of the container using the first public key. In some cases, the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container. In some cases, the second verified boot metadata partition of the container is verified by a process of the host operating system.

[0057] At block 706, the computing device (or component thereof) may access the second verified boot metadata partition of the container to obtain a first hash tree (e.g., hash tree for a container vendor partition 412 of FIG. 4) for a first file system (e.g., file system of vendor 426 partition of FIG. 4) of the container. In some cases, the second verified boot metadata partition of the container includes a second private key associated with a second file system. In some examples, the second file system is associated with a supervisor of the container. In some cases, the computing device (or component thereof) may verify, by the host operating system, a third verified boot metadata partition associated with the supervisor of the container; access the third verified boot metadata partition associated with the supervisor of the container to obtain a second hash tree for the second file system; and verify the second file system based on the second hash tree for the second file system.

[0058] At block 708, the computing device (or component thereof) may verify the first file system of the container based on the first hash tree for the first file system of the container. In some cases, the computing device (or component thereof) may verify the first file system, by creating a logical linear device for the first file system of the container; and verifying blocks of the logical linear device with the first hash tree, wherein nodes of the first hash tree correspond with blocks of the logical linear device. For example, a dm-verity device for a file system may be created, for example, by the host OS, and the dm-verity device may be a logical linear device that uses dm-verity to verify blocks of the logical device (e.g., file system for the container) . In some examples, the computing device (or component thereof) may mount the logical linear device; and initiate verification of the blocks of the logical linear device using a kernel of the host operating system. For example, a container_dm service may mount the file system for the container. In some examples, initiating verification of the blocks of the logical linear device is performed before mounting the logical linear device.

[0059] In some examples, the techniques or processes described herein may be performed by a computing device, an apparatus, and / or any other computing device. In some cases, the computing device or apparatus may include a processor, microprocessor, microcomputer, or other component of a device that is configured to carry out the steps of processes described herein. In some examples, the computing device or apparatus may include a camera configured to capture video data (e.g., a video sequence) including video frames. For example, the computing device may include a camera device, which may or may not include a video codec. As another example, the computing device may include a mobile device with a camera (e.g., a camera device such as a digital camera, an IP camera or the like, a mobile phone or tablet including a camera, or other type of device with a camera) . In some cases, the computing device may include a display for displaying images. In some examples, a camera or other capture device that captures the video data is separate from the computing device, in which case the computing device receives the captured video data. The computing device may further include a network interface, transceiver, and / or transmitter configured to communicate the video data. The network interface, transceiver, and / or transmitter may be configured to communicate Internet Protocol (IP) based data or other network data.

[0060] The processes described herein can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the processes.

[0061] In some cases, the devices or apparatuses configured to perform the operations of the process 700 and / or other processes described herein may include a processor, microprocessor, micro-computer, or other component of a device that is configured to carry out the steps of the process 700 and / or other process. In some examples, such devices or apparatuses may include one or more sensors configured to capture image data and / or other sensor measurements. In some examples, such computing device or apparatus may include one or more sensors and / or a camera configured to capture one or more images or videos. In some cases, such device or apparatus may include a display for displaying images. In some examples, the one or more sensors and / or camera are separate from the device or apparatus, in which case the device or apparatus receives the sensed data. Such device or apparatus may further include a network interface configured to communicate data.

[0062] The components of the device or apparatus configured to carry out one or more operations of the process 700 and / or other processes described herein can be implemented in circuitry. For example, the components can include and / or can be implemented using electronic circuits or other electronic hardware, which can include one or more programmable electronic circuits (e.g., microprocessors, graphics processing units (GPUs) , digital signal processors (DSPs) , central processing units (CPUs) , and / or other suitable electronic circuits) , and / or can include and / or be implemented using computer software, firmware, or any combination thereof, to perform the various operations described herein. The computing device may further include a display (as an example of the output device or in addition to the output device) , a network interface configured to communicate and / or receive the data, any combination thereof, and / or other component (s) . The  network interface may be configured to communicate and / or receive Internet Protocol (IP) based data or other type of data.

[0063] The process 700 is illustrated as a logical flow diagram, the operations of which represent sequences of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the processes.

[0064] Additionally, the processes described herein (e.g., the process 700 and / or other processes) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. As noted above, the code may be stored on a computer-readable or machine-readable storage medium, for example, in the form of a computer program including a plurality of instructions executable by one or more processors. The computer-readable or machine-readable storage medium may be non-transitory.

[0065] Additionally, the processes described herein may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. As noted above, the code may be stored on a computer-readable or machine-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable or machine-readable storage medium may be non-transitory.

[0066] FIG. 8 is a block diagram illustrating an example of a computing system 800, which may be employed by the disclosed systems and techniques. In particular, FIG. 8 illustrates an example of computing system 800, which can be, for example, any computing device making up internal computing system, a remote computing system, a camera, or any component thereof in which the components of the system are in communication with each other using connection 805. Connection 805 can be a physical connection using a bus, or a direct connection into processor 810, such as in a chipset architecture. Connection 805 can also be a virtual connection, networked connection, or logical connection.

[0067] In some aspects, computing system 800 is a distributed system in which the functions described in this disclosure can be distributed within a datacenter, multiple data centers, a peer network, etc. In some aspects, one or more of the described system components represents many such components each performing some or all of the function for which the component is described. In some aspects, the components can be physical or virtual devices.

[0068] Example system 800 includes at least one processing unit (CPU or processor) 810 and connection 805 that communicatively couples various system components including system memory 815, such as read-only memory (ROM) 820 and random-access memory (RAM) 825 to processor 810. Computing system 800 can include a cache 812 of high-speed memory connected directly with, in close proximity to, or integrated as part of processor 810.

[0069] Processor 810 can include any general-purpose processor and a hardware service or software service, such as services 832, 834, and 836 stored in storage device 830, configured to control processor 810 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. Processor 810 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

[0070] To enable user interaction, computing system 800 includes an input device 845, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech, etc. Computing system 800 can also include output device 835, which can be one or more of a number of output  mechanisms. In some instances, multimodal systems can enable a user to provide multiple types of input / output to communicate with computing system 800.

[0071] Computing system 800 can include communications interface 840, which can generally govern and manage the user input and system output. The communication interface may perform or facilitate receipt and / or transmission wired or wireless communications using wired and / or wireless transceivers, including those making use of an audio jack / plug, a microphone jack / plug, a universal serial bus (USB) port / plug, an AppleTM LightningTM port / plug, an Ethernet port / plug, a fiber optic port / plug, a proprietary wired port / plug, 3G, 4G, 5G and / or other cellular data network wireless signal transfer, a BluetoothTM wireless signal transfer, a BluetoothTM low energy (BLE) wireless signal transfer, an IBEACONTM wireless signal transfer, a radio-frequency identification (RFID) wireless signal transfer, near-field communications (NFC) wireless signal transfer, dedicated short range communication (DSRC) wireless signal transfer, 802.11 Wi-Fi wireless signal transfer, wireless local area network (WLAN) signal transfer, Visible Light Communication (VLC) , Worldwide Interoperability for Microwave Access (WiMAX) , Infrared (IR) communication wireless signal transfer, Public Switched Telephone Network (PSTN) signal transfer, Integrated Services Digital Network (ISDN) signal transfer, ad-hoc network signal transfer, radio wave signal transfer, microwave signal transfer, infrared signal transfer, visible light signal transfer, ultraviolet light signal transfer, wireless signal transfer along the electromagnetic spectrum, or some combination thereof.

[0072] The communications interface 840 may also include one or more range sensors (e.g., LIDAR sensors, laser range finders, RF radars, ultrasonic sensors, and infrared (IR) sensors) configured to collect data and provide measurements to processor 810, whereby processor 810 can be configured to perform determinations and calculations needed to obtain various measurements for the one or more range sensors. In some examples, the measurements can include time of flight, wavelengths, azimuth angle, elevation angle, range, linear velocity and / or angular velocity, or any combination thereof. The communications interface 840 may also include one or more Global Navigation Satellite System (GNSS) receivers or transceivers that are used to determine a location of the computing system 800 based on receipt of one or more signals from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, the US- based GPS, the Russia-based Global Navigation Satellite System (GLONASS) , the China-based BeiDou Navigation Satellite System (BDS) , and the Europe-based Galileo GNSS. There is no restriction on operating on any particular hardware arrangement, and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0073] Storage device 830 can be a non-volatile and / or non-transitory and / or computer-readable memory device and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, a floppy disk, a flexible disk, a hard disk, magnetic tape, a magnetic strip / stripe, any other magnetic storage medium, flash memory, memristor memory, any other solid-state memory, a compact disc read only memory (CD-ROM) optical disc, a rewritable compact disc (CD) optical disc, digital video disk (DVD) optical disc, a blu-ray disc (BDD) optical disc, a holographic optical disk, another optical medium, a secure digital (SD) card, a micro secure digital (microSD) card, a Memory  card, a smartcard chip, a EMV chip, a subscriber identity module (SIM) card, a mini / micro / nano / pico SIM card, another integrated circuit (IC) chip / card, random access memory (RAM) , static RAM (SRAM) , dynamic RAM (DRAM) , read-only memory (ROM) , programmable read-only memory (PROM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , flash EPROM (FLASHEPROM) , cache memory (e.g., Level 1 (L1) cache, Level 2 (L2) cache, Level 3 (L3) cache, Level 4 (L4) cache, Level 5 (L5) cache, or other (L#) cache) , resistive random-access memory (RRAM / ReRAM) , phase change memory (PCM) , spin transfer torque RAM (STT-RAM) , another memory chip or cartridge, and / or a combination thereof.

[0074] The storage device 830 can include software services, servers, services, etc., that when the code that defines such software is executed by the processor 810, it causes the system to perform a function. In some aspects, a hardware service that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as processor 810, connection 805, output device 835, etc., to carry out the function. The term “computer-readable medium” includes, but is not limited to,  portable or non-portable storage devices, optical storage devices, and various other mediums capable of storing, containing, or carrying instruction (s) and / or data. A computer-readable medium may include a non-transitory medium in which data can be stored and that does not include carrier waves and / or transitory electronic signals propagating wirelessly or over wired connections. Examples of a non-transitory medium may include, but are not limited to, a magnetic disk or tape, optical storage media such as compact disk (CD) or digital versatile disk (DVD) , flash memory, memory or memory devices. A computer-readable medium may have stored thereon code and / or machine-executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, or the like.

[0075] Specific details are provided in the description above to provide a thorough understanding of the aspects and examples provided herein, but those skilled in the art will recognize that the application is not limited thereto. Thus, while illustrative aspects of the application have been described in detail herein, it is to be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations, except as limited by the prior art. Various features and aspects of the above-described application may be used individually or jointly. Further, aspects can be utilized in any number of environments and applications beyond those described herein without departing from the broader scope of the specification. The specification and drawings are, accordingly, to be regarded as illustrative rather than restrictive. For the purposes of illustration, methods were described in a particular order. It should be appreciated that in alternate aspects, the methods may be performed in a different order than that described.

[0076] For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software. Additional  components may be used other than those shown in the figures and / or described herein. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the aspects in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the aspects.

[0077] Further, those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0078] Individual aspects may be described above as a process or method which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0079] Processes and methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer-readable media. Such instructions can include, for example, instructions and data which cause or otherwise configure a general-purpose computer, special purpose computer, or a processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries,  intermediate format instructions such as assembly language, firmware, source code. Examples of computer-readable media that may be used to store instructions, information used, and / or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

[0080] In some aspects the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bitstream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0081] Those of skill in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof, in some cases depending in part on the particular application, in part on the desired design, in part on the corresponding technology, etc.

[0082] The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed using hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and can take any of a variety of form factors. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks (e.g., a computer-program product) may be stored in a computer-readable or machine-readable medium. A processor (s) may perform the necessary tasks. Examples of form factors include laptops, smart phones, mobile phones, tablet devices or other small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

[0083] The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are example means for providing the functions described in the disclosure.

[0084] The techniques described herein may also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques may be implemented in any of a variety of devices such as general purposes computers, wireless communication device handsets, or integrated circuit devices having multiple uses including application in wireless communication device handsets and other devices. Any features described as modules or components may be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be realized at least in part by a computer-readable data storage medium comprising program code including instructions that, when executed, performs one or more of the methods, algorithms, and / or operations described above. The computer-readable data storage medium may form part of a computer program product, which may include packaging materials. The computer-readable medium may comprise memory or data storage media, such as random-access memory (RAM) such as synchronous dynamic random access memory (SDRAM) , read-only memory (ROM) , non-volatile random access memory (NVRAM) , electrically erasable programmable read-only memory (EEPROM) , FLASH memory, magnetic or optical data storage media, and the like. The techniques additionally, or alternatively, may be realized at least in part by a computer-readable communication medium that carries or communicates program code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer, such as propagated signals or waves.

[0085] The program code may be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs) , general purpose microprocessors, an application specific integrated circuits (ASICs) , field programmable logic arrays (FPGAs) , or other equivalent integrated or discrete logic circuitry. Such a processor may be configured to perform any of the techniques described in this disclosure. A general-purpose processor may be a microprocessor; but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of  computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Accordingly, the term “processor, ” as used herein may refer to any of the foregoing structure, any combination of the foregoing structure, or any other structure or apparatus suitable for implementation of the techniques described herein.

[0086] One of ordinary skill will appreciate that the less than ( “<” ) and greater than ( “>” ) symbols or terminology used herein can be replaced with less than or equal to ( “≤” ) and greater than or equal to ( “≥” ) symbols, respectively, without departing from the scope of this description.

[0087] Where components are described as being “configured to” perform certain operations, such configuration can be accomplished, for example, by designing electronic circuits or other hardware to perform the operation, by programming programmable electronic circuits (e.g., microprocessors, or other suitable electronic circuits) to perform the operation, or any combination thereof.

[0088] The phrase “coupled to” or “communicatively coupled to” refers to any component that is physically connected to another component either directly or indirectly, and / or any component that is in communication with another component (e.g., connected to the other component over a wired or wireless connection, and / or other suitable communication interface) either directly or indirectly.

[0089] Claim language or other language reciting “at least one of” a set and / or “one or more” of a set indicates that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, claim language reciting “at least one of A and B” or “at least one of A or B” means A, B, or A and B. In another example, claim language reciting “at least one of A, B, and C” or “at least one of A, B, or C” means A, B, C, or A and B, or A and C, or B and C, A and B and C, or any duplicate information or data (e.g., A and A, B and B, C and C, A and A and B, and so on) , or any other ordering, duplication, or combination of A, B, and C. The language “at least one of” a set and / or “one or more” of a set does not limit the set to the items listed in the set. For example, claim language reciting “at least one of A and B” or “at least one of A or B” may  mean A, B, or A and B, and may additionally include items not listed in the set of A and B. The phrases “at least one” and “one or more” are used interchangeably herein.

[0090] Claim language or other language reciting “at least one processor configured to, ” “at least one processor being configured to, ” “one or more processors configured to, ” “one or more processors being configured to, ” or the like indicates that one processor or multiple processors (in any combination) can perform the associated operation (s) . For example, claim language reciting “at least one processor configured to: X, Y, and Z” means a single processor can be used to perform operations X, Y, and Z; or that multiple processors are each tasked with a certain subset of operations X, Y, and Z such that together the multiple processors perform X, Y, and Z; or that a group of multiple processors work together to perform operations X, Y, and Z. In another example, claim language reciting “at least one processor configured to: X, Y, and Z” can mean that any single processor may only perform at least a subset of operations X, Y, and Z.

[0091] Where reference is made to one or more elements performing functions (e.g., steps of a method) , one element may perform all functions, or more than one element may collectively perform the functions. When more than one element collectively performs the functions, each function need not be performed by each of those elements (e.g., different functions may be performed by different elements) and / or each function need not be performed in whole by only one element (e.g., different elements may perform different sub-functions of a function) . Similarly, where reference is made to one or more elements configured to cause another element (e.g., an apparatus) to perform functions, one element may be configured to cause the other element to perform all functions, or more than one element may collectively be configured to cause the other element to perform the functions.

[0092] Where reference is made to an entity (e.g., any entity or device described herein) performing functions or being configured to perform functions (e.g., steps of a method) , the entity may be configured to cause one or more elements (individually or collectively) to perform the functions. The one or more components of the entity may include at least one memory, at least one processor, at least one communication interface, another component configured to perform one or more (or all) of the functions, and / or any combination thereof. Where reference to the entity performing functions, the entity may be configured to cause one component to perform all  functions, or to cause more than one component to collectively perform the functions. When the entity is configured to cause more than one component to collectively perform the functions, each function need not be performed by each of those components (e.g., different functions may be performed by different components) and / or each function need not be performed in whole by only one component (e.g., different components may perform different sub-functions of a function) .

[0093] Illustrative aspects of the disclosure include:

[0094] Aspect 1. An apparatus for booting a container, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to: obtain, from a first verified boot metadata partition of a host operating system, a first public key associated with a container; verify a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container; access the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; and verify the first file system of the container based on the first hash tree for the first file system of the container.

[0095] Aspect 2. The apparatus of Aspect 1, wherein, to verify the first file system, the at least one processor is configured to: create a logical linear device for the first file system of the container; and verify blocks of the logical linear device with the first hash tree, wherein nodes of the first hash tree correspond with blocks of the logical linear device.

[0096] Aspect 3. The apparatus of Aspect 2, wherein the at least one processor is configured to: mount the logical linear device; and initiate verification of the blocks of the logical linear device using a kernel of the host operating system.

[0097] Aspect 4. The apparatus of Aspect 3, wherein initiating verification of the blocks of the logical linear device is performed before mounting the logical linear device.

[0098] Aspect 5. The apparatus of any of Aspects 1-4, wherein the host operating system executes in a virtual machine.

[0099] Aspect 6. The apparatus of Aspect 5, wherein the virtual machine is verified by a hypervisor before boot of the virtual machine.

[0100] Aspect 7. The apparatus of any of Aspects 1-6, wherein the second verified boot metadata partition of the container includes a second private key associated with a second file system, wherein the second file system is associated with a supervisor of the container, and wherein the at least one processor is configured to: verify, by the host operating system, a third verified boot metadata partition associated with the supervisor of the container; access the third verified boot metadata partition associated with the supervisor of the container to obtain a second hash tree for the second file system; and verify the second file system based on the second hash tree for the second file system.

[0101] Aspect 8. The apparatus of any of Aspects 1-7, wherein the second verified boot metadata partition of the container is verified by a process of the host operating system.

[0102] Aspect 9. A method for booting a container, the method comprising: obtaining, from a first verified boot metadata partition of a host operating system, a first public key associated with a container; verifying a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container; accessing the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; and verifying the first file system of the container based on the first hash tree for the first file system of the container.

[0103] Aspect 10. The method of Aspect 9, wherein verifying the first file system comprises: creating a logical linear device for the first file system of the container; and verifying blocks of the logical linear device with the first hash tree, wherein nodes of the first hash tree correspond with blocks of the logical linear device.

[0104] Aspect 11. The method of Aspect 10, further comprising: mounting the logical linear device; and initiating verification of the blocks of the logical linear device using a kernel of the host operating system.

[0105] Aspect 12. The method of Aspect 11, wherein initiating verification of the blocks of the logical linear device is performed before mounting the logical linear device.

[0106] Aspect 13. The method of any of Aspects 9-12, wherein the host operating system executes in a virtual machine.

[0107] Aspect 14. The method of Aspect 13, wherein the virtual machine is verified by a hypervisor before boot of the virtual machine.

[0108] Aspect 15. The method of any of Aspects 9-14, wherein the second verified boot metadata partition of the container includes a second private key associated with a second file system, wherein the second file system is associated with a supervisor of the container, and further comprising: verifying, by the host operating system, a third verified boot metadata partition associated with the supervisor of the container; accessing the third verified boot metadata partition associated with the supervisor of the container to obtain a second hash tree for the second file system; and verifying the second file system based on the second hash tree for the second file system.

[0109] Aspect 16. The method of any of Aspects 9-15, wherein the second verified boot metadata partition of the container is verified by a process of the host operating system.

[0110] Aspect 17. A non-transitory computer-readable medium having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to: obtain, from a first verified boot metadata partition of a host operating system, a first public key associated with a container; verify a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container; access the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; and verify the first file system of the container based on the first hash tree for the first file system of the container.

[0111] Aspect 18. The non-transitory computer-readable medium of Aspect 17, wherein, to verify the first file system, the instructions further cause the at least one processor to: create a logical linear device for the first file system of the container; and verify blocks of the logical linear  device with the first hash tree, wherein nodes of the first hash tree correspond with blocks of the logical linear device.

[0112] Aspect 19. The non-transitory computer-readable medium of Aspect 18, wherein the instructions further cause the at least one processor to: mount the logical linear device; and initiate verification of the blocks of the logical linear device using a kernel of the host operating system.

[0113] Aspect 20. The non-transitory computer-readable medium of Aspect 19, wherein initiating verification of the blocks of the logical linear device is performed before mounting the logical linear device.

[0114] Aspect 21. A non-transitory computer-readable medium having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to perform operations according to any of Aspects 9-16.

[0115] Aspect 22. An apparatus comprising one or more means for performing operations according to any of Aspects 9 to 16.

Claims

1.An apparatus for booting a container, the apparatus comprising:a memory; anda processor coupled to the memory and configured to:obtain, from a first verified boot metadata partition of a host operating system, a first public key associated with a container;verify a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container;access the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; andverify the first file system of the container based on the first hash tree for the first file system of the container.2.The apparatus of claim 1, wherein, to verify the first file system, the processor is configured to:create a logical linear device for the first file system of the container; andverify blocks of the logical linear device with the first hash tree, wherein nodes of the first hash tree correspond with blocks of the logical linear device.3.The apparatus of claim 2, wherein the processor is configured to:mount the logical linear device; andinitiate verification of the blocks of the logical linear device using a kernel of the host operating system.4.The apparatus of claim 3, wherein the processor is configured to initiate verification of the blocks of the logical linear device before mounting the logical linear device.5.The apparatus of claim 1, wherein the host operating system executes in a virtual machine.6.The apparatus of claim 5, wherein the virtual machine is verified by a hypervisor before boot of the virtual machine.7.The apparatus of claim 1, wherein the second verified boot metadata partition of the container includes a second private key associated with a second file system, wherein the second file system is associated with a supervisor of the container, and wherein the processor is configured to:verify, by the host operating system, a third verified boot metadata partition associated with the supervisor of the container;access the third verified boot metadata partition associated with the supervisor of the container to obtain a second hash tree for the second file system; andverify the second file system based on the second hash tree for the second file system.8.The apparatus of claim 1, wherein the second verified boot metadata partition of the container is verified by a process of the host operating system.9.A method for booting a container, the method comprising:obtaining, from a first verified boot metadata partition of a host operating system, a first public key associated with a container;verifying a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container;accessing the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; andverifying the first file system of the container based on the first hash tree for the first file system of the container.10.The method of claim 9, wherein verifying the first file system comprises:creating a logical linear device for the first file system of the container; andverifying blocks of the logical linear device with the first hash tree, wherein nodes of the first hash tree correspond with blocks of the logical linear device.11.The method of claim 10, further comprising:mounting the logical linear device; andinitiating verification of the blocks of the logical linear device using a kernel of the host operating system.12.The method of claim 11, wherein initiating verification of the blocks of the logical linear device is performed before mounting the logical linear device.13.The method of claim 9, wherein the host operating system executes in a virtual machine.14.The method of claim 13, wherein the virtual machine is verified by a hypervisor before boot of the virtual machine.15.The method of claim 9, wherein the second verified boot metadata partition of the container includes a second private key associated with a second file system, wherein the second file system is associated with a supervisor of the container, and further comprising:verifying, by the host operating system, a third verified boot metadata partition associated with the supervisor of the container;accessing the third verified boot metadata partition associated with the supervisor of the container to obtain a second hash tree for the second file system; andverifying the second file system based on the second hash tree for the second file system.16.The method of claim 9, wherein the second verified boot metadata partition of the container is verified by a process of the host operating system.17.A non-transitory computer-readable medium having stored thereon instructions that, when executed by a processor, cause the processor to:obtain, from a first verified boot metadata partition of a host operating system, a first public key associated with a container;verify a second verified boot metadata partition of the container using the first public key, wherein the second verified boot metadata partition of the container is signed using a first private key corresponding to the first public key associated with the container;access the second verified boot metadata partition of the container to obtain a first hash tree for a first file system of the container; andverify the first file system of the container based on the first hash tree for the first file system of the container.18.The non-transitory computer-readable medium of claim 17, wherein, to verify the first file system, the instructions further cause the processor to:create a logical linear device for the first file system of the container; andverify blocks of the logical linear device with the first hash tree, wherein nodes of the first hash tree correspond with blocks of the logical linear device.19.The non-transitory computer-readable medium of claim 18, wherein the instructions further cause the processor to:mount the logical linear device; andinitiate verification of the blocks of the logical linear device using a kernel of the host operating system.20.The non-transitory computer-readable medium of claim 19, wherein initiating verification of the blocks of the logical linear device is performed before mounting the logical linear device.

Citation Information

Patent Citations

  • Secure computing mechanism

    US20220413883A1