Final Examination

Question

A1

Which of the following executes in kernel mode?

A user application performing arithmetic on local variables.
The handler for a system call.
A library function such as printf, while it formats a string.
A shell script parsing its arguments.

Answer 1

B — The handler for a system call. System-call handlers run in kernel mode. User arithmetic, library formatting, and shell argument parsing all run in user mode.

Answer 2

C — A blocking I/O request. The process enters the Blocked state while waiting for the I/O to complete. A timer interrupt causes Running → Ready; exit() causes Running → Terminated; a higher-priority process becoming ready causes Running → Ready.

Answer 3

D — The address space (text, data, heap). Threads of the same process share the address space, open files, and credentials. The program counter, register set, and stack are private to each thread.

Answer 4

C — FCFS. Once a process is dispatched, it runs until it blocks or terminates. Round Robin preempts on quantum expiry; SRTF preempts when a shorter job arrives; preemptive priority preempts when a higher-priority process becomes ready.

Answer 5

A — wait(full), wait(mutex), remove item, post(mutex), post(empty). The consumer waits on full to claim a filled slot, then on mutex to enter the critical section; after removing the item it releases mutex and signals empty. Option B would deadlock if the buffer is empty (the consumer holds mutex while waiting for full).

Answer 6

C — Preemption. The four necessary conditions are mutual exclusion, hold and wait, no preemption, and circular wait. Preemption is the opposite of the actual condition.

Answer 7

B — Best-fit. It scans the entire free list and selects the smallest hole that is large enough, leaving the smallest possible leftover.

Answer 8

C — FIFO. FIFO does not satisfy the stack property, so increasing the number of frames can increase the fault count. LRU and Optimal do satisfy the stack property; Clock is an approximation of LRU and in practice does not exhibit the anomaly on the standard test strings.

Answer 9

B — The file name. Names are stored in directory entries that map names to inode numbers. The inode stores metadata (size, owner, permissions, timestamps, link count) and block pointers, but not the name.

Answer 10

C — Approximately 4 TB. P = 4096 / 4 = 1024 pointers per indirect block. Direct = 12 × 4 KB = 48 KB. Single = 1024 × 4 KB = 4 MB. Double = 1024² × 4 KB = 4 GB. Triple = 1024³ × 4 KB = 4 TB. Total ≈ 4.004 TB.

Answer 11

C — data=journal. Both metadata and data are written to the journal before being applied. This is the strongest guarantee and the slowest mode. data=ordered journals metadata and orders data writes before metadata; data=writeback journals only metadata and may lose data after a crash.

Answer 12

B — It never overwrites live data, so consistency is maintained without a journal. New data is written to fresh blocks and a single atomic pointer update makes the new tree live; after a crash the file system is either on the old tree or the new one, never a mix.

Answer 13

C — Direct memory access (DMA). The CPU programs the DMA controller with the source, destination, and length; the controller performs the transfer in the background. Polling and programmed I/O both require per-byte CPU involvement; interrupt-driven I/O reduces but does not eliminate CPU involvement.

Answer 14

C — FCFS. It serves requests in arrival order, without reordering. SSTF, SCAN, and C-LOOK all reorder requests to minimise head movement.

Answer 15

B — 10 TB. RAID 5 capacity = (N − 1) × S = (6 − 1) × 2 TB = 10 TB.

Answer 16

B — RAID 6 maintains two independent parity blocks (P and Q), so a small write must read the old data, read both parity blocks, write the new data, and write both new parity blocks — six I/Os. RAID 5 has only one parity block, so the cost is four I/Os.

Answer 17

C — Discretionary access control (DAC). The owner of a resource decides who may access it (for example, Linux mode bits and POSIX ACLs). MAC enforces a global policy that the owner cannot override; RBAC assigns permissions to roles; ABAC uses attributes.

Answer 18

B — A capability grants a specific, fine-grained privilege rather than the full root privilege set. A setuid root binary runs with all of root's privileges; a capability binary runs with only the capabilities it has been granted (for example, CAP_NET_BIND_SERVICE to bind a low port).

Answer 19

A — The kernel. A container shares the host's kernel; namespaces isolate its view of the file system, network, and process ID space, but the kernel itself is the same. This is why a kernel vulnerability can allow a container escape.

Answer 20

B — It compares the desired state stored in etcd to the observed state and takes action to converge them. The scheduler (A), service discovery and load balancing (C), and image management (D) are separate components; the reconciliation loop is the control-loop mechanism implemented by the controllers.

Answer 21

An inode (index node) is the data structure that describes a file. It contains the file's metadata — owner UID and GID, permissions, size in bytes, timestamps (atime, mtime, ctime), link count, and file type — and the block pointers that locate the file's data blocks (12 direct, one single-indirect, one double-indirect, and one triple-indirect in the classical ext2/3/4 scheme).

The file name is not stored in the inode because names are a property of the directory, not of the file. Storing the name in the inode would (a) make hard links impossible, because two directory entries pointing at the same inode would need to be reconciled with a single name field; (b) require a variable-length field inside the fixed-size inode structure; and (c) break the abstraction that separates the file (an inode plus its data blocks) from the namespace (directories). Names live in directory entries, which map names to inode numbers.

Marking: 1 mark for the definition; 1 mark for the correct contents (at least three fields); 1 mark for the reason the name is not in the inode (hard links or the separation of namespace from file).

Answer 22

Journaling is a technique in which the file system writes metadata (and optionally data) to a log before applying the changes to the file system's structures. It solves the problem that a crash during a multi-step update (allocating a block, updating the inode, updating the free-block bitmap) can leave the file system in an inconsistent state. After a crash, the file system replays the journal to bring the structures to a consistent state — a fast operation compared to a full fsck pass over the entire volume.

The three ext4 data modes are:

data=journal: both metadata and data are written to the journal before being applied to the file system. The strongest consistency guarantee; the slowest, because data is written twice.
data=ordered (default): only metadata is journaled, but data blocks are written to disk before the metadata that references them. The file system and the data remain consistent; performance is close to writeback.
data=writeback: only metadata is journaled; data may be written at any time. The fastest, but after a crash the metadata may reference data blocks that were never written, so a file may contain stale or garbage data.

Marking: 1 mark for the definition of journaling and the problem it solves; 1.5 marks for the three modes (0.5 each); 0.5 marks for stating which is the default or which is strongest.

Answer 23

The RAID 5 small-write penalty is the extra I/O cost of a small random write. RAID 5 stores one parity block per stripe, and the parity block is computed as the XOR of all the data blocks in the stripe. When one data block is updated, the parity block must also be updated. Because the parity depends on all data blocks in the stripe, the file system cannot compute the new parity from the new data alone; it must read the old data and the old parity, XOR them with the new data, and write the new data and new parity. This is four I/O operations per logical write (two reads and two writes) instead of one.

This is a problem for write-intensive workloads because a workload that issues many small random writes (for example, a database performing row-level updates) pays a fourfold I/O amplification. The effective write throughput of the array is roughly one quarter of what the raw disks could deliver. It is also a problem during rebuild: if a disk fails, the array is in a degraded state and every read must reconstruct the missing data from parity. RAID 6 has an even worse small-write penalty (six I/Os) because it maintains two parity blocks. This is why RAID 5 is a poor choice for write-intensive workloads and why RAID 10 (striping of mirrors) is preferred for those workloads.

Marking: 1 mark for the definition of the penalty; 1 mark for the four-I/O explanation; 1 mark for the impact on write-intensive workloads (amplification, throughput, or rebuild).

Answer 24

The flash translation layer (FTL) is the firmware layer in an SSD that hides the physical constraints of NAND flash from the host. Flash is written in pages (typically 4 KB) and erased in blocks (typically hundreds of KB to a few MB); a page cannot be overwritten in place until the whole erase block containing it has been erased. The FTL maps logical block addresses (LBAs) to physical pages and, when a logical block is rewritten, writes the new data to a fresh page and updates the mapping — the old page becomes invalid. The host sees a fast, overwrite-in-place block device.

Garbage collection (GC) is the process by which the FTL reclaims space from erase blocks that contain many invalid pages. The FTL selects a block, copies its remaining valid pages to a fresh block, and erases the original, returning it to the free pool. Without GC, the drive would run out of free pages. GC is also the cause of the write cliff: once the free-page pool is nearly exhausted, every new write triggers GC, and write throughput collapses.

Wear levelling is the technique of distributing writes evenly across all erase blocks. Flash cells have a limited number of program-erase cycles (typically 1,000–100,000 depending on the cell type). Without wear levelling, a block that is written more often than others will fail first, and the drive's usable capacity will shrink over time. Wear levelling is implemented by the FTL, which tracks each block's erase count and prefers blocks with low counts. Both GC and wear levelling are necessary for the drive to function correctly over its lifetime.

Marking: 1 mark for the FTL; 1 mark for GC; 1 mark for wear levelling (with a note on why each is necessary).

Answer 25

The three access-control models differ in who makes the access decision and how the policy is expressed:

Discretionary access control (DAC): the owner of a resource decides who may access it. The decision is discretionary because the owner can grant or revoke access at will. Linux example: file mode bits (rwxr-x---) and POSIX ACLs (setfacl, getfacl).
Mandatory access control (MAC): the system enforces a global policy that even the owner cannot override. Each process and object has a label, and the policy defines which labels may interact. Linux example: SELinux and AppArmor. A process labelled httpd_t cannot read a file labelled shadow_t even if the file's DAC permissions allow it.
Role-based access control (RBAC): permissions are assigned to roles, and users are assigned to roles. Linux example: sudo. The /etc/sudoers file defines which users or groups may run which commands as which other users; a user in the webadmin group may be allowed to restart nginx but nothing else.

The three models are complementary and are typically used together: DAC governs ordinary file access, RBAC governs administrative privilege, and MAC provides a system-wide policy that restricts even privileged processes.

Marking: 1 mark for each model correctly defined, with a Linux example. Award partial marks for a correct definition without an example, or an example without a clear definition.

Answer 26

A setuid binary is an executable whose setuid bit is set and whose owner is a user other than the caller (typically root). When the binary is executed, the process runs with the owner's effective UID rather than the caller's. This allows an unprivileged user to perform a privileged operation — for example, passwd is setuid root so that a user can change their own password, which requires writing to /etc/shadow.

Setuid is dangerous because any bug in the binary — a buffer overflow, a command injection, a race condition (TOCTOU), a failure to sanitise the environment or the input — can be exploited by an unprivileged caller to gain the binary's privileges. A setuid root program that invokes system() or execlp() with caller-controlled input gives the caller a root shell. The attack surface is large because the binary runs with full root privileges even if it only needs one privileged operation.

Capabilities mitigate the risk by granting only the specific privileges the binary needs. For example, instead of setuid root, a program that needs to bind a low-numbered port can be granted CAP_NET_BIND_SERVICE with setcap. The binary runs with that one capability and no other root privileges; a compromise of the binary exposes only the capability it holds. Linux also supports a capability bounding set and ambient capabilities, which further restrict what a process can acquire. Capabilities are a direct application of the principle of least privilege.

Marking: 1 mark for the definition of setuid; 1 mark for the danger (attack surface, example exploit); 1 mark for the capability mitigation.

Answer 27

The four dimensions are:

Isolation. Virtual machines are better. A VM runs its own kernel inside a hypervisor, so a bug in one VM's kernel cannot affect another VM or the host. Containers share the host kernel and rely on namespaces, cgroups, and LSM policies; a kernel vulnerability can allow a container escape. VMs therefore provide a stronger security boundary and are preferred in multi-tenant environments.
Density. Containers are better. A container does not need its own kernel, so it consumes far less memory and CPU for the same workload. Many more containers than VMs can run on the same host. Containers also share the host's page cache, so multiple containers running the same base image consume the image only once.
Startup time. Containers are better. A container starts in milliseconds because it is just a process with its own namespaces; there is no kernel to boot, no device initialisation, and no full user-space start-up. A VM must boot a guest operating system, which takes seconds to tens of seconds. This is why containers are preferred for elastic workloads and serverless platforms.
Performance. Containers are better. A container's processes execute directly on the host CPU with no hypervisor in the data path. A VM incurs the cost of every privileged instruction trapping to the hypervisor and every memory access going through the nested page tables. The overhead is modest for CPU-bound workloads (a few percent) but can be larger for I/O unless virtio or device passthrough is used.

In summary, VMs win on isolation, containers win on density, startup time, and performance. Modern platforms often combine them — running containers inside VMs — to get the best of both, and microVMs (Firecracker, Kata Containers) are an attempt to provide VM-grade isolation with container-like speed and density.

Marking: 0.75 marks per dimension (3 marks total): 0.25 for the correct winner and 0.5 for the justification. Award partial marks for correct winners with weak justifications.

Answer 28

The Kubernetes control plane consists of four main components, plus a cloud controller manager in cloud environments:

API server (kube-apiserver): the front end of the cluster. All communication — from kubectl, from the nodes, and from the controllers — goes through it. It validates requests, persists them to etcd, and serves watch events to controllers and nodes.
etcd: a distributed, consistent key-value store that holds the entire cluster's desired and observed state. It is the single source of truth; if etcd is lost, the cluster's configuration is lost.
Scheduler (kube-scheduler): watches for newly created Pods with no assigned node and selects a node for each, based on resource requests, node affinity, taints and tolerations, and other constraints.
Controller manager (kube-controller-manager): runs the reconciliation loops that implement Kubernetes's declarative model. For example, the Deployment controller ensures that the desired number of replicas is running; the Node controller detects and responds to node failures.

The reconciliation loop is the mechanism by which the declarative model is enforced. Each controller watches the observed state of the resources it owns and compares it to the desired state stored in etcd. Whenever the two differ, the controller takes action to close the gap. For example, the ReplicaSet controller creates a new Pod if a Pod fails, and deletes one if there are too many. Because the loop runs continuously, the cluster is self-healing: it recovers automatically from Pod crashes, node failures, and configuration drift. This is a direct application of control-loop theory to distributed systems.

Marking: 2 marks for the four control-plane components with their roles (0.5 each); 1 mark for the reconciliation loop and its role in the declarative model.

Answer 29

(a) Maximum file size (3 marks). Block size = 4 KB = 4096 bytes; pointer size = 4 bytes; so P = 4096 / 4 = 1024 pointers per indirect block.

Direct:           12 × 4 KB           = 48 KB
Single-indirect:   1024 × 4 KB         = 4 MB
Double-indirect:   1024² × 4 KB        = 4 GB
Triple-indirect:   1024³ × 4 KB        = 4 TB
Total = 48 KB + 4 MB + 4 GB + 4 TB ≈ 4.004 TB

Marking: 1 mark for computing P = 1024; 1 mark for the direct + single-indirect + double-indirect calculation; 1 mark for the triple-indirect and the total.

(b) Data and indirect blocks for a 10 MB file (5 marks). 10 MB = 10 × 1,048,576 = 10,485,760 bytes. With 4096-byte blocks:

Data blocks = ceil(10,485,760 / 4096) = 2560 blocks

How are these addressed?

Direct:           12 blocks (blocks 0–11)
Single-indirect:  1024 blocks (blocks 12–1035)
Subtotal:         1036 blocks
Remaining:        2560 − 1036 = 1524 blocks

The remaining 1524 blocks are addressed through the double-indirect pointer. The double-indirect block points to single-indirect blocks, each holding 1024 data-block addresses. 1524 data blocks require:

ceil(1524 / 1024) = 2 single-indirect blocks
  First  single-indirect block: 1024 data blocks
  Second single-indirect block:  500 data blocks

The total indirect blocks allocated are:

1 single-indirect block (from the inode's single-indirect pointer)
1 double-indirect block
2 single-indirect blocks (under the double-indirect pointer)
= 4 indirect blocks

Total blocks used = 2560 data + 4 indirect = 2564 blocks = 2564 × 4 KB = 10,502,144 bytes ≈ 10.02 MB.

Marking: 1 mark for the data block count (2560); 1 mark for the direct + single-indirect subtotal (1036); 1 mark for the remaining 1524 blocks; 1 mark for correctly attributing the remaining blocks to the double-indirect path with 2 single-indirect blocks; 1 mark for the final indirect-block count (4) and total.

Answer 30

Start at cylinder 50, moving towards higher-numbered cylinders. Queue: 82, 170, 43, 140, 24, 16, 190.

(a) FCFS (2 marks). Served in arrival order:

50 → 82 → 170 → 43 → 140 → 24 → 16 → 190
Movements: 32 + 88 + 127 + 97 + 116 + 8 + 174
Total head movement = 642 cylinders

Marking: 1 mark for the correct service order; 1 mark for the correct total (642).

(b) SSTF (3 marks). Always serve the closest request:

50 → 43 (7)   closest to 50
43 → 24 (19)  closest to 43
24 → 16 (8)   closest to 24
16 → 82 (66)  closest remaining to 16
82 → 140 (58) closest to 82
140 → 170 (30) closest to 140
170 → 190 (20) closest to 170
Total head movement = 7 + 19 + 8 + 66 + 58 + 30 + 20 = 208 cylinders

Marking: 2 marks for the correct service order; 1 mark for the correct total (208). Award partial marks for a single ordering error if the method is correct.

(c) SCAN (3 marks). The head moves up from 50, serves all higher requests in increasing order, reaches the end of the disk (199), then reverses and serves the lower requests in decreasing order:

Up:   50 → 82 → 140 → 170 → 190 → 199
      Movements: 32 + 58 + 30 + 20 + 9 = 149
Down: 199 → 43 → 24 → 16
      Movements: 156 + 19 + 8 = 183
Total head movement = 149 + 183 = 332 cylinders

Note: if the algorithm reverses at the last pending request rather than at the physical end of the disk, it is LOOK, not SCAN, and the total is:

Up:   50 → 82 → 140 → 170 → 190 = 140
Down: 190 → 43 → 24 → 16 = 174
Total = 314 cylinders

Accept either 332 (SCAN) or 314 (LOOK) if the reasoning is consistent with the definition used. The standard textbook SCAN goes to the end of the disk, so 332 is the expected answer.

Marking: 2 marks for the correct upward service order and movement (149); 1 mark for the downward movement and the total (183 → 332). Deduct 1 mark if the candidate uses LOOK without saying so.

Answer 31

Eight disks of 3 TB each. N = 8, S = 3 TB.

(a) RAID 0 (1 mark): N × S = 8 × 3 = 24 TB. Failures tolerated: 0.
(b) RAID 1 (1 mark): (N / 2) × S = 4 × 3 = 12 TB. Failures tolerated: 4 (one per mirror pair). A second failure within the same pair would lose that pair's data, but each pair can tolerate one failure independently.
(c) RAID 5 (1 mark): (N − 1) × S = 7 × 3 = 21 TB. Failures tolerated: 1.
(d) RAID 6 (1 mark): (N − 2) × S = 6 × 3 = 18 TB. Failures tolerated: 2.

(e) Small-write I/O count (2 marks): A single 4 KB random write under RAID 5 requires 4 physical I/Os: read the old data block, read the old parity block, write the new data block, write the new parity block. Under RAID 6 the same write requires 6 physical I/Os: read the old data, read the old P parity, read the old Q parity, write the new data, write the new P parity, write the new Q parity. The difference is that RAID 6 maintains two independent parity blocks (P and Q) to tolerate two disk failures, so both parities must be updated on every write. The extra read and extra write give RAID 6 a 50% higher small-write penalty than RAID 5.

Marking: 1 mark per part (a)–(d); 1 mark for the RAID 5 count (4) and 1 mark for the RAID 6 count (6) with the explanation.

Answer 32

Page size = 4 KB = 2¹², so the offset is the low 12 bits. The page number is the high 20 bits, split into a 10-bit PDE index and a 10-bit PTE index.

(a) 0x0000A3C8 (2 marks).

0x0000A3C8 = 0000 0000 0000 0000 1010 0011 1100 1000
  offset = 0x3C8 = 968
  page number = 0x000A3 = 163
  PDE index = top 10 bits of 163 = 0
  PTE index = bottom 10 bits of 163 = 163

PDE[0] → page table at frame 5
PTE[163] in that table → frame 23
Physical address = (23 << 12) | 0x3C8 = 0x17000 + 0x3C8 = 0x173C8

(b) 0x0000A004 (2 marks).

0x0000A004 = 0000 0000 0000 0000 1010 0000 0000 0100
  offset = 0x004
  page number = 0x000A0 = 160
  PDE index = 0
  PTE index = 160

PDE[0] → page table at frame 5
PTE[160] → frame 20
Physical address = (20 << 12) | 0x004 = 0x14000 + 0x004 = 0x14004

(c) 0x0004B000 (2 marks).

0x0004B000 = 0000 0000 0000 0100 1011 0000 0000 0000
  offset = 0x000
  page number = 0x4B0 = 1200
  PDE index = top 10 bits of 1200 = 1
  PTE index = bottom 10 bits of 1200 = 176

PDE[1] is not present → page fault

The page directory entry for index 1 is not present, so the address translation cannot proceed. The kernel's page-fault handler is invoked. If the address is not part of the process's valid address space, the process receives SIGSEGV and is terminated.

Marking: For each part, 1 mark for the correct PDE and PTE indices; 1 mark for the correct physical address (or the correct identification of a page fault). Award partial marks for correct decomposition with an arithmetic error.

Answer 33

Reference string: 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5

(a) FIFO with 3 frames (2 marks):

Ref  Frames (oldest → newest)   Fault?
1    [1]                         F
2    [1 2]                       F
3    [1 2 3]                     F
4    [2 3 4]  (evict 1)          F
1    [3 4 1]  (evict 2)          F
2    [4 1 2]  (evict 3)          F
5    [1 2 5]  (evict 4)          F
1    [1 2 5]                     H
2    [1 2 5]                     H
3    [2 5 3]  (evict 1)          F
4    [5 3 4]  (evict 2)          F
5    [5 3 4]                     H
Total faults = 9

Marking: 1 mark for the correct frame contents; 1 mark for the correct total (9).

(b) FIFO with 4 frames (2 marks):

Ref  Frames                      Fault?
1    [1]                         F
2    [1 2]                       F
3    [1 2 3]                     F
4    [1 2 3 4]                   F
1    [1 2 3 4]                   H
2    [1 2 3 4]                   H
5    [2 3 4 5]  (evict 1)         F
1    [3 4 5 1]  (evict 2)         F
2    [4 5 1 2]  (evict 3)         F
3    [5 1 2 3]  (evict 4)         F
4    [1 2 3 4]  (evict 5)         F
5    [2 3 4 5]  (evict 1)         F
Total faults = 10

Marking: 1 mark for the correct frame contents; 1 mark for the correct total (10).

(c) LRU with 3 frames (2 marks):

Ref  Frames (LRU → MRU)        Fault?
1    [1]                         F
2    [1 2]                       F
3    [1 2 3]                     F
4    [2 3 4]  (evict 1)          F
1    [3 4 1]  (evict 2)          F
2    [4 1 2]  (evict 3)          F
5    [1 2 5]  (evict 4)          F
1    [2 5 1]                     H
2    [5 1 2]                     H
3    [1 2 3]  (evict 5)          F
4    [2 3 4]  (evict 1)          F
5    [3 4 5]  (evict 2)          F
Total faults = 9

(The exact set of frames may differ depending on tie-breaking, but LRU always produces 9 faults on this string with 3 frames.)

Marking: 1 mark for the correct frame contents on at least the first six references; 1 mark for the correct total (9).

(d) Belady's anomaly (2 marks): Parts (a) and (b) demonstrate Belady's anomaly: increasing the number of frames from 3 to 4 increases the number of page faults, from 9 to 10. The anomaly occurs because FIFO does not satisfy the stack property: the set of pages retained with n+1 frames is not always a superset of the set retained with n frames, so the extra frame can lead to a worse sequence of evictions. LRU and Optimal do satisfy the stack property and are not subject to this anomaly.

Marking: 1 mark for naming Belady's anomaly; 1 mark for the explanation (non-stack property or the specific effect).

Answer 34

(a) Authentication of administrators (2 marks). Mechanism: Public-key authentication for SSH, with mandatory multi-factor authentication (MFA). Password authentication is disabled. Access is restricted to a bastion host, and administrator accounts are separate from any accounts used by the application. PAM is configured with a strong password policy for any fallback passwords. Threat mitigated: Credential theft, password guessing, and reuse of compromised passwords. MFA prevents an attacker who has stolen a password from logging in without the second factor. Limitation: MFA can be bypassed by a sophisticated attacker through session-token theft or a phishing attack that relays the second factor in real time. It also does not protect against an attacker who has already obtained a valid SSH private key and can use it from an allowed IP.

(b) Authorization of the web application (3 marks). DAC: The web application runs as a dedicated, unprivileged user (for example, www-data) with no login shell. Its files are owned by that user with restrictive permissions (640 for configuration, 750 for directories). The application cannot read or write files outside its own directories. MAC: An LSM policy (SELinux or AppArmor) confines the web server process to a specific domain. The domain is allowed to read its own content directory and bind to the HTTP port; it is denied access to /etc/shadow, /root, and other system files, even if the DAC permissions would allow it. Threat mitigated: A compromise of the web application cannot be used to read arbitrary files or modify the system, because the MAC policy denies access regardless of DAC permissions. Limitation: MAC policies are complex to write and maintain; a misconfigured policy can either block legitimate access (a denial of service) or fail to block an attack if the policy is too permissive. The policy itself is only as strong as the kernel's enforcement, which depends on the correctness of the LSM implementation.

(c) Sandboxing the web application (3 marks). Mechanisms: Two or more of:

Namespaces: run the application in its own mount, PID, network, and IPC namespaces, so it cannot see or signal other processes on the host. This contains the blast radius of an exploit.
seccomp: a filter that allows only the system calls the application actually needs (for example, read, write, openat, accept) and denies the rest. A compromised process cannot invoke execve, ptrace, or other dangerous calls.
Capability bounding: drop all capabilities except CAP_NET_BIND_SERVICE if the application binds to port 80 or 443. The application cannot use CAP_SYS_ADMIN, CAP_SYS_PTRACE, or any other privileged operation.
Read-only root file system: mount the container's file system read-only and provide a small writable tmpfs for temporary files. An attacker cannot persist a modified binary or a script on disk.

Threat mitigated: RCE (remote code execution) in the application is confined to the sandbox. The attacker cannot read the host's files, cannot signal other processes, cannot exfiltrate data through a system call the filter denies, and cannot persist across a restart. Limitation: A kernel vulnerability can allow a sandbox escape. Sandboxing is defence in depth, not a guarantee. If the web application needs a capability that is normally dangerous (for example, raw sockets), the sandbox must grant it, and the attacker may be able to exploit it.

(d) Auditing and detection (2 marks). Mechanism: auditd is enabled with rules that log writes to sensitive files (/etc/passwd, /etc/shadow), the execution of privileged binaries, the loading of kernel modules, and changes to the firewall. Logs are forwarded to a central log server (so that an attacker who compromises the host cannot erase them). An IDS/IPS (for example, Suricata or Zeek) monitors network traffic for known attack patterns. Threat mitigated: An attacker who compromises the host is detected by the anomalous audit events (for example, an unexpected write to /etc/passwd or a suspicious outbound connection), and the incident can be investigated using the centralised logs. Limitation: Auditing is reactive — it detects events after they occur. It also produces a large volume of data that requires tuning and analysis; an unattended audit log provides no protection. An attacker who is aware of the audit rules may try to disable them or to blend in with normal traffic.

Marking: (a) 2 marks — 1 for the mechanism, 1 for the threat and limitation combined. (b) 3 marks — 1 for DAC, 1 for MAC, 1 for the threat/limitation. (c) 3 marks — 1 for each of two mechanisms, 1 for the threat/limitation. (d) 2 marks — 1 for the mechanism, 1 for the threat/limitation.

Answer 35

Workload A — Legacy Windows application (3 marks). Recommendation: Virtual machine (with a conventional Type 1 hypervisor such as KVM, Hyper-V, or ESXi). Justification: The application requires a specific Windows kernel version and cannot be recompiled, so it needs a full Windows user-space and kernel. A container shares the host kernel; it cannot run a Windows kernel on a Linux host without a compatibility layer (WSL2, which is itself a VM), and it cannot run a Windows kernel on a Linux host at all without virtualisation. A microVM would technically work (a microVM can boot any kernel), but microVMs are optimised for small, fast-booting Linux guests and would not be a good fit for a full Windows installation; the boot time and memory footprint would be those of a conventional VM in any case. The VM provides the kernel-level compatibility the application requires. Trade-offs: Isolation is strong (its own kernel), which is a benefit for a proprietary application that may not be trusted. Density is moderate (a full Windows VM has a significant memory footprint). Startup time is slow (seconds to tens of seconds), but the workload is not expected to scale elastically — it is a legacy application that runs continuously. Performance is good for a VM (a few percent overhead for CPU; virtio or passthrough for I/O if needed). The VM is the correct choice.

Workload B — Stateless HTTP API (3 marks). Recommendation: Container (Linux namespaces, cgroups, seccomp), with a possible transition to a microVM if multi-tenancy becomes a requirement. Justification: The workload is a stateless Go service that must scale elastically with demand and have a cold-start time of less than 100 ms. Containers start in milliseconds, so the cold-start requirement is met with room to spare. Containers are dense (many replicas can run on one host), which is essential for elastic scaling at thousands of requests per second. Containers have near-native performance, so the API's throughput and latency are not degraded by the isolation layer. The application is trusted (written in-house), so the weaker isolation of a container relative to a VM is acceptable. If the platform later needs to run untrusted customer code in the same cluster, the API can be moved to a microVM (Kata Containers) with minimal change, because the container image is the same. Trade-offs: Isolation is weaker than a VM (shared kernel), which is acceptable for a trusted in-house service. Density is excellent. Startup time is excellent (milliseconds). Performance is near-native. The container is the correct choice.

Workload C — Multi-tenant SaaS platform (4 marks). Recommendation: MicroVM (Firecracker or Kata Containers), with a fallback to a conventional VM if the microVM's performance is insufficient for the workload. Justification: The workload runs untrusted customer code in the same cluster, and tenants are mutually distrusting. Strong isolation is the dominant requirement: a kernel vulnerability in one tenant's workload must not allow an escape to another tenant's workload or to the host. Containers share the host kernel, so a kernel vulnerability is an escape vector; a container-only design is therefore not acceptable for this workload. A conventional VM would provide the required isolation, but the density and startup time would be poor — a multi-tenant platform must launch many tenants' workloads quickly and pack them densely to be cost-effective. A microVM combines the strong isolation of a VM (its own kernel) with the density and startup time of a container (boot in tens of milliseconds, memory footprint of a few tens of MB per microVM). Firecracker and Kata Containers are the standard implementations. The microVM is the correct choice. Trade-offs: Isolation is strong (its own kernel, hypervisor-enforced). Density is good — significantly better than a conventional VM and closer to a container. Startup time is fast (tens of milliseconds), which is acceptable for the platform's scale-out requirements. Performance is close to native for CPU and memory; I/O is handled through virtio, so it is slightly slower than a container but much faster than a conventional VM. If the microVM's performance is insufficient for a specific workload, that workload can be deployed on a conventional VM while the rest of the platform uses microVMs.

Marking: (a) 3 marks — 1 for the recommendation, 2 for the justification with reference to the four dimensions. (b) 3 marks — same. (c) 4 marks — 1 for the recommendation, 3 for the justification, with emphasis on the multi-tenancy requirement and the microVM's combination of isolation, density, and speed. Award partial marks for correct recommendations with incomplete justifications, and for a defensible alternative (for example, a conventional VM for workload C) if the student argues the trade-off correctly.

Course	COMP 3150 / CMIS 3150 — Operating Systems
Weight	Comprehensive final; weight determined by the assessment plan variant (see note in § 01.1)
Coverage	All units (1–13), with emphasis on Modules 4–5 (Units 10–13)
Duration	3 hours (180 minutes)
Total marks	100 marks
Format	Closed book. One A4 formula sheet (handwritten or printed, both sides) is permitted. Non-programmable calculator permitted.
Sections	Part A — Multiple choice (20 marks) Part B — Short answer (24 marks) Part C — Problems (36 marks) Part D — Design and analysis (20 marks)
CLOs assessed	CLO1, CLO2, CLO3, CLO4, CLO5, CLO6, CLO7, CLO8

Part	Content	Questions	Marks each	Total	CLOs
A	Multiple choice (cumulative review and Units 10–13)	20	1	20	CLO1, CLO2, CLO3, CLO4, CLO5, CLO7
B	Short answer (Units 10–13)	8	3	24	CLO5, CLO6, CLO7
C	Problems (file systems, I/O, RAID, address translation, page replacement)	5	6–8	36	CLO3, CLO4, CLO5
D	Design and analysis (security architecture; isolation technology choice)	2	10	20	CLO5, CLO6, CLO7, CLO8
Total				100

Unit	Marks	Where assessed
Unit 1 — Introduction	1	A1
Unit 2 — Linux/UNIX	1	A1 (via the kernel/user mode distinction) — reviewed cumulatively
Unit 3 — Processes	1	A2
Unit 4 — Threads	1	A3
Unit 5 — CPU Scheduling	1	A4
Unit 6 — Synchronization	1	A5
Unit 7 — Deadlocks	1	A6
Unit 8 — Main Memory	1	A7
Unit 9 — Virtual Memory	1	A8
Unit 10 — File Systems	~24	A9–A12, B1, B2, C1
Unit 11 — I/O and Storage	~24	A13–A16, B3, B4, C2, C3
Unit 12 — Security	~6	A17, A18, B5, B6, D1
Unit 13 — Virtualization	~18	A19, A20, B7, B8, D2
Cross-unit (Units 4–5, 9)	—	C4, C5 (address translation and page replacement are also relevant to Units 8–9 but are assessed here for cumulative review)

Band	Marks	Descriptor
A	90–100	Comprehensive understanding of all topics; quantitative answers are correct and well-justified; design and analysis are insightful and reference the correct trade-offs.
B	80–89	Solid understanding; most answers correct; design and analysis are sound but not exhaustive.
C	70–79	Adequate understanding; some answers incomplete or with minor errors; design and analysis are present but shallow.
D	60–69	Limited understanding; several answers incorrect or missing; design and analysis are superficial.
F	<60	Does not demonstrate the required understanding; most answers incorrect or missing.

Final Examination

01 Examination details

1.1 Note on weight

02 Instructions to candidates

03 Formula sheet (permitted reference)

04 Examination paper

05 Part A — Multiple choice (20 marks)

06 Part B — Short answer (24 marks)

07 Part C — Problems (36 marks)

08 Part D — Design and analysis (20 marks)

End of examination paper

09 Instructor answer key

Part A — Multiple choice (20 marks, 1 mark each)

Part B — Short answer (24 marks, 3 marks each)

Part C — Problems (36 marks)

Part D — Design and analysis (20 marks)

10 Marking summary

11 Academic integrity

12 Preparation resources