Design and Components of OS

CSS Optional — Paper-II, Section-A · P-II.III.I (cont.) · Previously missing from this vault — added because "Design and Components of OS" is named explicitly in the syllabus line for this topic. This page answers "what must an OS achieve, and what pieces does it break into" — the companion [OS Structures and Operations] page answers "how is it physically architected."

1. Design Goals

These two goal-sets are sometimes in tension (e.g. maximum safety/protection checks can cost raw speed) — OS design is a continual balancing act between them.

2. Mechanisms vs Policies (a classic separation-of-concerns principle)

• A mechanism is how something is done (e.g. the timer-interrupt hardware that CAN preempt a process).
• A policy is what/when decision is made using that mechanism (e.g. which scheduling algorithm decides WHEN to preempt and WHOM to run next).

Good OS design keeps mechanism and policy separate — the same underlying mechanism (a preemption timer) can then support many different policies (FCFS, RR, Priority, MLFQ) without redesigning the hardware/low-level support each time. This separation is why, e.g., Linux can offer several pluggable schedulers on the same kernel mechanisms.

3. Components of an Operating System

graph TD
    OS["Operating System"] --> PM["Process Management"]
    OS --> MM["Memory Management"]
    OS --> FM["File Management"]
    OS --> IO["I/O System Management"]
    OS --> SM["Secondary Storage Management"]
    OS --> NW["Networking"]
    OS --> PROT["Protection System"]
    OS --> CI["Command-Interpreter / UI"]

• Process Management: creating/scheduling/terminating processes and threads, synchronization, deadlock handling.
• Memory Management: allocating/deallocating main memory, tracking which parts are in use, deciding which processes/data move in and out of memory.
• File Management: creating/deleting files and directories, mapping files onto secondary storage, backup.
• I/O System Management: a buffer/caching system, a general device-driver interface, drivers for specific hardware devices.
• Secondary Storage Management: free-space management, storage allocation, disk scheduling.
• Networking: enabling communication and resource-sharing across machines (distributed-system support).
• Protection System: controlling which processes/users may access which resources (see Security below).
• Command-Interpreter System / User Interface: the shell or GUI through which a user's commands are read and acted upon.

Kernel responsibilities recap (frequently asked as a standalone short-note): the kernel is the privileged core implementing most of the above — process management/scheduling, memory management, file-system management, device management via drivers, IPC/synchronization primitives, system-call interface, and security/access-control enforcement.

4. Protection & Security as a Design Component

Protection controls access to resources within a trusted system (permissions, access rights); Security defends the system against external/internal threats (authentication, malware, attacks). Both are treated as core OS design components, not afterthoughts, because a fast-but-insecure OS fails its system goals above.

Design principles frequently tested (2024 MCQs):

• Least Privilege: give a subject (user/process) only the access rights it strictly needs for its task, nothing more — e.g. not granting an employee root access unless their job requires it.
• Complete Mediation: every single access to every resource must be checked for authorization, every time — e.g. a banking site forcing re-login after 30 minutes doesn't just check once and trust forever.
• Open Design: system security should not depend on the secrecy of its design/algorithm (only on the secrecy of keys/passwords).

Malware taxonomy (asked as both short-note and MCQs, 2024):

5. Access Matrix Model (the standard textbook protection model — a common short-note)

Protection can be formalized as a matrix with rows = domains (a user, process, or role) and columns = objects (files, devices, other processes); cell Access(i,j) lists the operations domain i may perform on object j (e.g. read, write, execute, own).

• Access Control List (ACL): store the matrix by column — each object keeps a list of (domain, rights) pairs. Efficient when checking "who can access this object" (NTFS's approach — see [File Systems]).
• Capability List: store the matrix by row — each domain keeps a list of (object, rights) it may access, like a ticket the holder presents. Efficient when checking "what can this domain do."

This ACL-vs-capability framing is exactly what distinguishes UNIX's simpler rwx model from NTFS's richer ACL model, and is worth citing explicitly if a question asks you to justify why one system chose one approach.

6. Additional Security Design Principles (extending the Least Privilege / Complete Mediation pair)

These five, plus Least Privilege, Complete Mediation, and Open Design (already covered above), form the classic Saltzer & Schroeder list of secure-design principles — naming several of them together (not just one) is what turns a 2-mark MCQ-level answer into a full short-note answer.

7. Authentication Basics (ties Protection to practical OS security)

• Something you know: passwords, PINs.
• Something you have: a smart card, a hardware token, an OTP device.
• Something you are: biometrics (fingerprint, retina).

Multi-factor authentication combines at least two of these categories — a direct application of the Separation of Privilege principle above.

---

🎯 CSS Exam Angle

Component-listing questions ("key roles and responsibilities of an OS," 2024) score best when each component gets one concrete sentence tying it to a resource it manages — a bare list of eight nouns earns fewer marks than four components each explained in a full sentence. For the mechanism/policy distinction, always give a paired concrete example (timer interrupt = mechanism; choice of scheduling algorithm = policy) rather than defining the terms abstractly.

📄 Past CSS Paper Questions on this Topic

⚠️ MCQ Traps

• A Trojan does NOT self-replicate — this is the single most-tested malware fact; candidates default-guess "worm" or "rootkit" here and are wrong.
• Mechanism vs Policy: a question describing "how" something is technically achieved is asking about mechanism; a question about "which choice/rule is applied" is asking about policy — don't answer with the wrong half.
• Least Privilege vs Complete Mediation are easy to swap: Least Privilege is about the scope of access granted; Complete Mediation is about checking every single access attempt, even repeated ones from an already-authenticated source.
• ACL vs Capability List: ACL is stored per-object ("who can access ME"); a capability list is stored per-domain ("what can I access") — a question asking which model NTFS uses expects "ACL," not "capability."

📜 Past-Paper Questions & MCQs (CSS 2016–2026)

2018 · Paper-I · Q2(c) · 3 marks

Q. What are the responsibilities of the operating system kernel?

Ans.

• Process management: create, schedule and terminate processes, and context switching.
• Memory management: allocate and free memory, paging and virtual memory.
• Device management: control hardware through drivers and handle interrupts.
• File-system management: files, directories and access.
• System calls and protection: provide the interface to applications, and enforce security and isolation (user mode versus kernel mode).
• Inter-process communication and synchronisation.

2020 · Paper-II · Q3(a) · 7 marks

Q. What is the kernel of an operating system? Explain the difference between a monolithic kernel and a microkernel.

Ans.

• The kernel is the core of the OS. It always stays in memory, runs in privileged mode and controls the hardware, processes, memory and I/O.