Study guide
8.1 Virtualization Foundations, Hypervisors & Multi-Tenant Isolation
Certificate of Cloud Security Knowledge CCSK v5
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CCSK Exam Overview & CSA Security Frameworks
1.1 CCSK v5 Exam Structure, Logistics & Open-Book Strategy 1.2 CCSK v5 Source Hierarchy & CSA Cloud Architecture 1.3 CSA Assurance Tools: CCM v4.1, CAIQ v4.1 & the STAR Registry
2 Chapter 2: Cloud Computing Concepts & Architectures
2.1 Cloud Definition, Essential Characteristics & ISO/IEC Standards 2.2 Cloud Service Models (IaaS, PaaS, SaaS) & Abstraction Layers 2.3 Cloud Deployment Models & Shared Responsibility in Practice
3 Chapter 3: Cloud Governance
3.1 Enterprise Governance, Cloud Strategy & Policy Frameworks 3.2 Contracts, Service Level Agreements (SLAs) & Vendor Due Diligence 3.3 Cloud Governance Operating Models & CCM Control Implementation
4 Chapter 4: Risk, Audit, & Compliance
4.1 Cloud Risk Management, Risk Tolerance & Shared Risk Profiles 4.2 Audit Principles, Assurance Inheritance & Third-Party Reports (SOC & ISO) 4.3 Compliance Assessment, Continuous Auditing & Regulatory Mandates
5 Chapter 5: Organization Management
5.1 Cloud Center of Excellence (CCoE) & Organizational Design 5.2 Cloud Vendor Management, Supply Chain Risk & Multi-Cloud Operations 5.3 Cloud Financial Governance (FinOps), Business Continuity & People 5.4 Provider Organization Hierarchies, Identity Mapping & Shared Services
6 Chapter 6: Identity & Access Management
6.1 Cloud IAM Architecture: Authentication, Authorization & RBAC vs. ABAC 6.2 Identity Federation: SAML 2.0, OpenID Connect, OAuth 2.0 & SCIM 6.3 Privileged Access Management (PAM), CIEM & Cloud Secrets Lifecycle
7 Chapter 7: Security Monitoring
7.1 Cloud Telemetry Architecture, Audit Logging & Control Plane Trails 7.2 Cloud Security Posture Management (CSPM) & Configuration Baselining 7.3 Centralized SIEM/SOAR Integration, Cloud Detection and Response (CDR) 7.4 Cloud Telemetry Sources, Collection Architecture & Retention 7.5 AI for Security Monitoring: Use Cases, Risks & Governance
8 Chapter 8: Infrastructure & Networking
8.1 Virtualization Foundations, Hypervisors & Multi-Tenant Isolation 8.2 Cloud Virtual Networks, Subnetting, Security Groups & Microsegmentation 8.3 Hybrid Connectivity, Software-Defined Perimeters (SDP) & DDoS/WAF Defense 8.4 Infrastructure as Code Security, Policy Gates & Drift Control
9 Chapter 9: Cloud Workload Security
9.1 Virtual Machine (VM) Hardening, Golden Images & Immutable Infrastructure 9.2 Container Security: Image Scanning, Registries & Runtime Defense 9.3 Kubernetes Orchestration Security, Serverless (FaaS) & CWPP/CNAPP 9.4 Cloud Workload Types, Security Boundaries & Control Substitution
10 Chapter 10: Data Security
10.1 Cloud Data Lifecycle (CSU-SAD) & Data Discovery/Classification 10.2 Cloud Cryptography: Data at Rest, In Transit (TLS 1.3) & In Use (Confidential Computing) 10.3 Key Management Systems (KMS), HSMs, BYOK/HYOK & Cloud DLP 10.4 Cloud Storage Models & Object Storage Security 10.5 Data Security Posture Management & AI Data Protection
11 Chapter 11: Application Security
11.1 Secure Software Development Lifecycle (SSDLC) & DevSecOps Pipelines 11.2 Application Security Testing: SAST, DAST, SCA & SBOM 11.3 Cloud API Security: OWASP API Top 10 & API Gateway Protections
12 Chapter 12: Incident Response & Resilience
12.1 Cloud Incident Response Lifecycle, Cloud Challenges & Playbooks 12.2 Cloud Digital Forensics: Ephemeral Workloads, Snapshots & Chain of Custody 12.3 Cloud Resilience, Business Continuity & Disaster Recovery Patterns
13 Chapter 13: Related Technologies & Strategies
13.1 Zero Trust Architecture in Cloud (NIST SP 800-207 Principles & Execution) 13.2 Secure Access Service Edge (SASE) & Cloud Access Security Brokers (CASB) 13.3 Artificial Intelligence & Machine Learning Security (CSA AI Safety & LLM Risks) 13.4 CCSK v5 Synthesis, Cross-Domain Scenarios & Exam-Day Strategy
8.1 Virtualization Foundations, Hypervisors & Multi-Tenant Isolation
Key Takeaways Explain This Topic AI
Type 1 (bare-metal) hypervisors execute directly on host physical hardware with no intermediary host operating system, providing the minimal attack surface and isolation boundary required for multi-tenant cloud IaaS.
MicroVM architectures such as AWS Firecracker and sandboxed runtimes like Google gVisor bridge the security boundary of hardware virtualization with the millisecond startup latency and high density of containers.
Multi-tenant co-residency introduces critical side-channel vulnerabilities including CPU microarchitectural timing attacks (Spectre, Meltdown, Foreshadow/L1TF) and noisy neighbor resource starvation.
VM escape represents a catastrophic breach of the hypervisor boundary, allowing arbitrary guest code execution directly inside the hypervisor ring 0 or parent management partition (Dom0).
Hardware-enforced isolation primitives—including AMD Secure Encrypted Virtualization (SEV-SNP) and Intel Trust Domain Extensions (TDX)—enable Confidential Computing by encrypting memory in use and removing hypervisor trust from the tenant Trusted Computing Base (TCB).
Last updated: September 2026
8.1 Virtualization Foundations, Hypervisors & Multi-Tenant Isolation
Quick Answer: Virtualization abstracts physical compute, memory, and storage hardware into logical instances, enabling the multi-tenant resource pooling that defines cloud computing. In Infrastructure as a Service (IaaS), providers rely on Type 1 (bare-metal) hypervisors (e.g., KVM, Xen, ESXi) running directly on physical silicon to enforce hardware-assisted boundaries, unlike Type 2 (hosted) hypervisors which introduce host OS attack surfaces. For lightweight, multi-tenant serverless workloads, MicroVMs (e.g., AWS Firecracker) strip legacy device emulation to achieve sub-second startup while maintaining hypervisor-level isolation. However, multi-tenancy introduces severe threats: VM escape (guest code breaking into hypervisor ring 0), microarchitectural CPU cache side-channels (Spectre, Meltdown, Foreshadow/L1TF), and noisy neighbor resource starvation . Confidential-computing technologies such as AMD SEV-SNP or Intel TDX can reduce the host and hypervisor trust required for workload confidentiality and integrity. The remaining TCB and guarantees depend on the TEE, attestation, key release, firmware, and side-channel threat model.
At the core of cloud infrastructure lies virtualization. According to the Cloud Security Alliance (CSA) Security Guidance v5, virtualization decouples software execution from physical hardware dependencies, allowing multiple independent, mutually untrusted workloads to execute concurrently on shared physical silicon. Understanding the hypervisor architecture, hardware execution rings, and multi-tenant threat vectors is essential for evaluating cloud isolation assurances.
Hypervisor Architectures: Type 1, Type 2 & MicroVMs
The hypervisor, or Virtual Machine Monitor (VMM) , mediates access between guest virtual machines (VMs) and the physical central processing unit (CPU), random-access memory (RAM), storage controllers, and network interface cards (NICs). ┌────────────────────────────────────────────────────────────────────────┐
- │ HYPERVISOR ARCHITECTURE COMPARISON │
- ├────────────────────────────────────────────────────────────────────────┤
- │ TYPE 1: BARE-METAL HYPERVISOR TYPE 2: HOSTED HYPERVISOR │
- │ ┌──────────────────────────────┐ ┌──────────────────────────────┐ │
- │ │ Guest VM 1 │ Guest VM 2 (Ten)│ │ Guest VM 1 │ Guest VM 2 │ │
- │ ├────────────┴─────────────────┤ ├────────────┴─────────────────┤ │
- │ │ Type 1 Hypervisor (Bare-Met) │ │ Type 2 Hypervisor (App) │ │
- │ ├──────────────────────────────┤ ├──────────────────────────────┤ │
- │ │ Hardware (CPU / EPT / NIC) │ │ Host Operating System │ │
- │ │ (Ring -1 / VMX Root Mode) │ ├──────────────────────────────┤ │
- │ │ │ │ Physical Hardware │ │
- │ └──────────────────────────────┘ └──────────────────────────────┘ │
- │ * Minimal Attack Surface * Heavy Context Switching │
- │ * Enterprise Multi-Tenant Standard * Unsuitable for Cloud IaaS │
- ├────────────────────────────────────────────────────────────────────────┤
- │ MICROVM ARCHITECTURE (e.g., AWS Firecracker) │
- │ ┌──────────────────────────────────────────────────────────────────┐ │
- │ │ [MicroVM Tenant 1] [MicroVM Tenant 2] │ │
- │ │ Minimal Linux Kernel Minimal Linux Kernel │ │
- │ │ Virtio-Net / Virtio-Blk Virtio-Net / Virtio-Blk │ │
- │ ├──────────────────────────────────────────────────────────────────┤ │
- │ │ Firecracker VMM Process (Rust, Seccomp, Jailer, Minimal Devices) │ │
- │ ├──────────────────────────────────────────────────────────────────┤ │
- │ │ Linux KVM Hypervisor Kernel Module (Hardware-Assisted Rings) │ │
- │ ├──────────────────────────────────────────────────────────────────┤ │
- │ │ Bare-Metal Silicon (AMD-V / Intel VT-x) │ │
- │ └──────────────────────────────────────────────────────────────────┘ │
- │ * Up to 125ms to userspace, up to 5 MiB VMM overhead, VM-Grade Isolation │
- └────────────────────────────────────────────────────────────────────────┘
- 1. Type 1 Hypervisors (Bare-Metal)
Type 1 hypervisors execute directly on the bare physical host hardware. There is no underlying general-purpose host operating system. The hypervisor initializes hardware controllers, manages CPU scheduling, and partitions memory using hardware virtualization extensions (Intel VT-x / AMD-V) operating in Ring -1 (VMX root mode) .
Examples: Xen, Kernel-based Virtual Machine (KVM), VMware ESXi, Microsoft Hyper-V.
Architecture Variants:
Monolithic Hypervisors (e.g., ESXi): Device drivers run directly within the hypervisor address space. Delivers high performance but increases the hypervisor code footprint.
Microkernel / Paravirtualized Hypervisors (e.g., Xen): The hypervisor kernel contains only the minimal code necessary for CPU scheduling and memory partitioning. Device drivers and management APIs run inside a privileged, specialized virtual machine known as Domain 0 (Dom0) or the Parent Partition . Unprivileged tenant VMs run in Domain U (DomU) .
Security Profile: Highly robust. Because there is no general-purpose host OS running background services, compilers, or graphical shells, the attack surface is minimized. This is the mandatory baseline for enterprise cloud IaaS platforms.
2. Type 2 Hypervisors (Hosted)
Type 2 hypervisors execute as software applications inside a conventional host operating system (e.g., Linux, Windows, macOS).
Examples: Oracle VirtualBox, VMware Workstation, Parallels Desktop.
Architectural Bottlenecks & Vulnerabilities: When a guest VM executes an I/O operation, the request must traverse the guest kernel, the hypervisor software, the host OS kernel, and finally the physical hardware drivers. This double-layer of kernel transitions introduces substantial latency. More critically, the hypervisor's security boundary is completely dependent on the integrity of the underlying host OS. If the host OS is compromised, every hosted VM is immediately breached.
Cloud Applicability: Type 2 hypervisors are strictly unsuitable for multi-tenant public cloud infrastructure and are confined to developer workstations and testing labs.
3. MicroVMs and Sandboxed Runtimes (Firecracker, gVisor, Kata)
Traditional enterprise VMs carry significant virtualization baggage: emulating legacy hardware devices (such as floppy controllers, IDE buses, PS/2 keyboards, and complex ACPI tables) designed for 1990s PC architectures. This results in heavy memory footprints (~150MB+ per idle VM) and slow initialization times (5 to 30 seconds).
In container environments, standard Open Container Initiative (OCI) runtimes (such as Docker, containerd, and runc ) share the host Linux kernel. A single privilege escalation vulnerability in the shared host kernel exposes every container running on that host, making multi-tenant container hosting dangerous without isolation wrappers.
To solve this, modern cloud platforms developed MicroVMs and sandboxed runtimes:
AWS Firecracker: An open-source VMM written in Rust that utilizes the Linux KVM infrastructure. Firecracker deliberately excludes legacy devices, PCI busses, and complex BIOS routines. It provides only six virtual devices: virtio-net , virtio-block , virtio-vsock , virtio-balloon , a minimal serial console, and a minimal keyboard controller (for reboot resets). Consequently, Firecracker is designed to start a microVM in up to 125 milliseconds to userspace and add up to 5 MiB of VMM memory overhead per microVM, and runs inside a multi-layered security wrapper (chroot jail, cgroups v2, and seccomp-bpf system call filters). Firecracker powers multi-tenant serverless engines including AWS Lambda and AWS Fargate .
Google gVisor: A user-space application kernel written in Go ( runsc ). Rather than virtualizing hardware, gVisor intercepts application system calls and implements the Linux kernel API in user space, creating a defensive barrier between untrusted container code and the host kernel.
Kata Containers: Integrates lightweight virtual machines (using QEMU or Cloud Hypervisor) transparently into container orchestration platforms (Kubernetes) via CRI (Container Runtime Interface), providing dedicated kernels per Kubernetes pod.
Virtualization Paradigm Isolation Mechanism Startup Latency Memory Overhead Multi-Tenant Security Rating
OCI Containers ( runc ) Linux Namespaces & Cgroups (Shared Kernel) < 100 ms < 1 MB Inadequate for Untrusted Multi-Tenancy
gVisor Sandboxing User-Space Emulated Kernel ( runsc ) < 200 ms ~15-30 MB High (Application Isolation)
MicroVMs (Firecracker) Hardware KVM + stripped minimal devices Up to 125 ms to userspace Up to 5 MiB VMM overhead Optimal (Full Hypervisor Boundary)
Type 1 Hypervisor VM Full Hardware Emulation (QEMU/KVM/ESXi) 5-30 seconds 100-500 MB Optimal (Enterprise IaaS Standard)
Type 2 Hypervisor VM Host OS Application Emulation 15-60 seconds 200-1000 MB Deprecated for Public Cloud Hosting
Multi-Tenancy Isolation Challenges & Threat Vectors
Multi-tenancy enables cloud economies of scale by packing workloads from multiple competing organizations onto identical physical host servers. However, sharing physical compute silicon creates acute security challenges.
1. VM Escape Vulnerabilities
A VM Escape represents the most catastrophic failure mode in cloud infrastructure. It occurs when malicious code executing inside a guest virtual machine bypasses the hypervisor's logical isolation boundaries, enabling arbitrary code execution within the hypervisor kernel, the host management partition (Dom0), or the host operating system.
Primary Root Causes:
Legacy Device Emulation Bugs: Virtualization platforms historically incorporated QEMU software modules to emulate legacy physical peripherals. For example, the infamous VENOM vulnerability (CVE-2015-3456) existed in the virtual Floppy Disk Controller (FDC) code present in QEMU, Xen, and KVM. An attacker with administrative privileges inside a guest VM could send crafted commands to the emulated floppy drive, triggering a buffer overflow that yielded root execution in the host hypervisor process.
Hypercall API Flaws: Guest operating systems communicate with the hypervisor via specialized assembly instructions known as hypercalls (e.g., VMCALL on Intel, VMMCALL on AMD). Memory corruption or logic errors in the hypercall validation handler allow guest privilege escalation.
Direct Memory Access (DMA) Exploits: Flawed virtual I/O device drivers allowing untrusted guests to write directly to unauthorized host memory regions.
Impact: Once an attacker achieves VM escape, they possess unconstrained access to all co-resident tenant memory, storage disks, virtual network switches, and encryption keys hosted on that physical chassis.
2. CPU Microarchitectural Side-Channel Attacks (Transient Execution)
Modern high-performance central processing units achieve performance through speculative execution (predicting the future path of conditional branches) and out-of-order execution (executing instructions as execution units become available). When a branch predictor guesses incorrectly, the CPU rolls back the architectural register state. However, the microarchitectural side effects—specifically data loaded into the L1 Data Cache , L2/L3 Last-Level Caches (LLC) , and internal execution buffers—are not cleared upon rollback.
Adversaries exploit this microarchitectural footprint using precise hardware timing measurements ( Cache Timing Attacks such as Flush+Reload and Prime+Probe ):
Spectre (CVE-2017-5753 / CVE-2017-5715): Exploits branch target injection and bounds check bypass, tricking speculative execution into accessing arbitrary memory locations across boundaries.
Meltdown (CVE-2017-5754): Breaks the fundamental privilege barrier between user applications and the operating system kernel by exploiting out-of-order execution during page permission checks, allowing unauthorized reading of kernel and physical memory.
Foreshadow / L1 Terminal Fault (L1TF - CVE-2018-3615 / CVE-2018-3620 / CVE-2018-3646): Exploits how Intel CPUs handle page table entries with the "Present" bit cleared. If a transient instruction attempts to read unmapped virtual memory, the CPU hardware still speculatively reads the physical address bits from the L1 Data Cache. In virtualized environments, a malicious guest VM can extract data from other co-resident VMs, hypervisor memory, and even Intel SGX enclaves.
Microarchitectural Data Sampling (MDS - ZombieLoad, RIDL, Fallout): Exploits internal CPU fill buffers, store buffers, and load ports to sample speculative in-flight data traversing the processor pipeline.
Warning
The Simultaneous Multi-Threading (SMT) Vulnerability: Simultaneous Multi-Threading (Intel Hyper-Threading / AMD SMT) splits a single physical CPU core into two logical cores. These logical sibling cores share physical L1 instruction/data caches, execution units, and TLBs. If Tenant A executes on Logical Thread 0 and Tenant B executes on Logical Thread 1 of the same physical core, microarchitectural side-channel attacks can leak cryptographic keys across the tenant boundary. Mitigating these attacks requires cloud providers to disable SMT, deploy core-scheduling hypervisors, or force dedicated core allocation.
3. Co-Residency Detection & The Noisy Neighbor Problem
Co-Residency Probing: Attackers intentionally map public cloud infrastructure to identify when their VM has been provisioned on the same physical server as a targeted high-value victim. Techniques include:
Analyzing sequential internal IP address allocations.
Measuring sub-millisecond network round-trip times (RTT) between instances.
Generating memory bus or cache contention and measuring access latency spikes (e.g., priming memory lines and measuring whether victim activity flushes the cache).
The Noisy Neighbor Problem: In multi-tenant environments, one VM consuming excessive CPU cycles, memory bus bandwidth, disk I/O operations per second (IOPS), or network packet buffers can severely degrade the performance and availability of neighboring VMs. Cloud providers mitigate this using cgroups v2 bandwidth throttling, CPU quota scheduling, and dedicated hardware offload cards (e.g., AWS Nitro System, Google Titanium, Microsoft Azure Boost) that offload networking, storage, and security functions away from the primary host CPU.
Hardware-Enforced Isolation & Confidential Computing
To counter hypervisor vulnerabilities and side-channel leakage, modern cloud security relies on silicon-level hardware enforcement mechanisms.
1. Hardware Virtualization Extensions
Intel VT-x & AMD-V: Introduce hardware-enforced CPU operation modes. The CPU operates in VMX Root Operation (hypervisor control) or VMX Non-Root Operation (guest VM execution). Privileged guest instructions automatically trigger a hardware intercept ( VM-Exit ), switching control to the hypervisor.
Extended Page Tables (EPT) / Nested Page Tables (NPT): Provides two-dimensional hardware memory paging. The guest OS manages Guest Virtual Addresses (GVA) to Guest Physical Addresses (GPA), while the CPU hardware MMU transparently translates GPA to Host Physical Addresses (HPA), preventing guests from accessing physical memory assigned to other tenants.
SR-IOV (Single Root I/O Virtualization): Allows a single physical PCIe network adapter or storage controller to present multiple virtual instances ( Virtual Functions - VFs ) directly into guest VMs, bypassing hypervisor software switches for near-bare-metal I/O throughput.
2. Confidential Computing: Protecting Data in Use
Traditional cloud encryption protects Data at Rest (AES-256 block storage) and Data in Transit (TLS 1.3). However, during active computation, data must be loaded into CPU registers and RAM in unencrypted plaintext. Without an applicable confidential-computing control, a sufficiently privileged compromise of the host or hypervisor can expose workload memory; actual access and mitigations depend on the platform.
Confidential Computing resolves this by enforcing hardware-based cryptographic isolation, formally defined by the Confidential Computing Consortium (CCC) as the protection of data in use by performing computation in a hardware-based Trusted Execution Environment (TEE) . ┌────────────────────────────────────────────────────────────────────────┐
- │ CONFIDENTIAL COMPUTING: MEMORY ENCRYPTION │
- ├────────────────────────────────────────────────────────────────────────┤
- │ │
- │ ┌────────────────────────────────────────────────────────────────┐ │
- │ │ UNTRUSTED CLOUD ENVIRONMENT │ │
- │ │ • Cloud Provider Infrastructure Operators │ │
- │ │ • Hypervisor (KVM / Xen / ESXi) │ │
- │ │ • Host Operating System & Firmware (UEFI / BMC) │ │
- │ └───────────────────────────────┬────────────────────────────────┘ │
- │ │ CANNOT READ PLAINTEXT MEMORY │
- │ ▼ │
- │ ┌────────────────────────────────────────────────────────────────┐ │
- │ │ CPU PACKAGE (HARDWARE TRUST BOUNDARY) │ │
- │ │ ┌──────────────────────┐ ┌──────────────────────┐ │ │
- │ │ │ Tenant Secure VM │ │ Hardware AES Engine │ │ │
- │ │ │ (Encrypted Registers)│ │ In Memory Controller │ │ │
- │ │ └──────────┬───────────┘ └──────────▲───────────┘ │ │
- │ └─────────────┼───────────────────────────────────┼──────────────┘ │
- │ │ Memory Write │ Memory Read │
- │ ▼ ▼ │
- │ ┌────────────────────────────────────────────────────────────────┐ │
- │ │ PHYSICAL SYSTEM RAM (DDR4 / DDR5) │ │
- │ │ [0xFA48B... Encrypted with Unique AES-128/256 Key Per VM] │ │
- │ └────────────────────────────────────────────────────────────────┘ │
- └────────────────────────────────────────────────────────────────────────┘
Dominant Hardware Implementations:
AMD Secure Encrypted Virtualization (SEV):
SEV: The CPU memory controller contains an integrated hardware AES encryption engine. Each VM is assigned a unique cryptographic key. Memory pages written to system RAM are automatically encrypted; reading another VM's memory returns indecipherable ciphertext.
SEV-ES (Encrypted State): Encrypts all CPU register contents when a VM-Exit occurs, preventing the hypervisor from snooping on register state during context switches.
SEV-SNP (Secure Nested Paging): Adds hardware-enforced memory integrity protection. Prevents the hypervisor from executing replay attacks, memory remapping, or bit-flipping attacks against the guest memory space.
Intel Trust Domain Extensions (TDX):
Isolates guest VMs into hardware-protected virtual machines called Trust Domains (TDs) .
Encrypts CPU registers and memory pages using Multi-Key Total Memory Encryption (MKTME), enforcing strict cryptographic separation from the hypervisor.
Intel Software Guard Extensions (SGX):
Implements application-level enclaves. Unlike SEV/TDX (which encrypt entire VMs), SGX encrypts specific memory regions ( Enclave Page Cache - EPC ) within an application process. Even the guest OS kernel cannot inspect enclave memory.
3. Tenancy Deployment Models
When regulatory, licensing, or risk profiles prohibit shared hardware, organizations select from three compute tenancy tiers:
Tenancy Model Physical Server Allocation Hypervisor Management Hardware Control Side-Channel Co-Residency Risk
Shared Tenancy (Default) Multi-tenant physical chassis shared with external accounts Managed by Cloud Provider None; instances scheduled dynamically across fleet Present (Requires Software & SMT Mitigations)
Dedicated Instances Single-tenant chassis; dedicated to one customer account Managed by Cloud Provider Logical account isolation; no control over physical placement Eliminated from External Third Parties
Dedicated Hosts / Bare Metal Physical server leased exclusively to customer Full visibility; Bare-metal permits customer-installed hypervisors Complete control over physical sockets, cores, and hyperthreading Completely Eliminated (Zero Shared Silicon)