COMP200 · Unit 4 · Section 1
System software sits between applications and hardware. An operating system manages CPU time, memory, storage, devices, networking, users, and permissions. It hides hardware-specific details behind interfaces that applications can use consistently. A file is an operating-system abstraction over blocks, sectors, drivers, and storage controllers; a process is an abstraction over an executing program and its resources.
application
| libraries and runtime
| system calls
operating system and device drivers
| CPU, memory, storage, network, devices
hardwareA system call crosses the application-to-OS boundary. Examples include opening a file, creating a process, allocating memory, or sending network data. The OS checks permissions, schedules work, and invokes a driver. The application receives a result or an error rather than directly controlling the device.
A program is a passive set of instructions; a process is a running instance with an address space, open files, security identity, and other resources. Threads are execution paths within a process that share its address space. The scheduler switches runnable threads so many tasks appear to run concurrently on one or more CPUs.
Virtual memory gives each process a logical address space. The memory-management unit translates virtual addresses to physical frames, while page tables record mappings and permissions. This supports isolation: one process should not read or overwrite another process's memory. A page fault occurs when a needed page is not currently mapped in physical memory; the OS may load it from storage, but excessive paging can severely reduce performance.
virtual address -> page-table translation -> physical frame
|
permission checkA virtual machine (VM) presents a software-defined computer to a guest operating system. A hypervisor allocates virtual CPUs, memory, storage, and devices to guests and mediates access to the physical host. A Type 1 hypervisor runs directly on hardware; a Type 2 hypervisor runs as an application on a host operating system.
Type 1: hardware -> hypervisor -> guest OS -> applications
Type 2: hardware -> host OS -> hypervisor application -> guest OS -> applicationsVMs improve portability, consolidation, snapshotting, and isolation, but isolation is not absolute. A vulnerable hypervisor, misconfigured virtual network, exposed management interface, shared credential, or unsafe guest tool can create risk. Virtual CPUs also compete for physical resources, so overcommitment can cause contention and unpredictable performance.
Containers usually isolate application processes while sharing the host kernel. Namespaces restrict what a process can see; control groups limit and measure resource use. Containers start quickly and package dependencies, but a kernel vulnerability or excessive privilege can affect the host and other containers. A VM generally provides a stronger operating-system boundary at higher resource cost.
A language runtime provides a different abstraction. The Java Virtual Machine executes bytecode; a Python runtime interprets or compiles Python instructions. A runtime improves portability across operating systems but is not automatically a security boundary. Application permissions, dependency safety, and OS isolation still matter.
| Abstraction | What it isolates | Strength | Typical cost |
|---|---|---|---|
| Process | Address space and OS resources | Lightweight application isolation | Shares kernel |
| Container | Process view and resource limits | Fast packaging and deployment | Shares kernel; configuration-sensitive |
| Virtual machine | Guest OS and virtual hardware | Stronger boundary and portability | More memory and startup overhead |
| Language runtime | Language execution model | Source or bytecode portability | Runtime overhead and dependency surface |
Virtualization changes where resources are controlled, not whether they are finite. A VM needs CPU scheduling, memory reservations, storage throughput, and network bandwidth. Define quotas and monitor actual use. Security controls include least-privilege guest accounts, patched hypervisors and guests, protected management planes, encrypted images and snapshots, isolated networks, and tested recovery.
Use the smallest abstraction that meets the requirement. A process may be enough for a local tool; a container may fit a stateless service; a VM may be appropriate when different kernels or stronger isolation are needed. The decision should state threat model, portability requirement, performance target, operational skill, and recovery plan.
1. Which layer normally schedules CPU time and enforces process permissions?
2. What does a Type 1 hypervisor run on?
3. Why can a container be less isolated than a VM?
4. What is virtual memory's key protection benefit?
5. Which is usually the strongest reason to choose a VM over a container?
6. What problem can host overcommitment cause?
7. Is a JVM automatically a sandbox for arbitrary code?
A defensible design might use containers for stateless application processes, a managed or isolated VM for a database requiring a separate kernel boundary, and a protected management plane. The file-read path is application to runtime library, system call, OS permission check, filesystem, driver, controller, and storage media. A baseline includes MFA, least privilege, patching, signed images, encrypted snapshots, private management access, network segmentation, host and guest logging, protected secrets, resource quotas, backups, restore tests, and incident procedures. Paging and storage contention can be tested with memory pressure, page-fault rate, disk latency, queue depth, CPU steal time, and guest response latency. Virtualization packages and separates environments, but the hypervisor, guest, images, identities, applications, and operations remain part of the security boundary.