Operation system –

Lecture 1:
BASICS OF OPERATING SYSTEM
 Operating System: A program that acts as a midway
between a user of a computer and the computer hardware;
Make the computer system convenient to use
 Kernel: The one program running at all times on the
computer
 bootstrap program: Initializes all aspects of system and
Loads operating system kernel and starts execution
 Caching – copying information into faster storage system;
main memory can be viewed as a cache for secondary
storage
 Device Driver for each device controller to manage I/O,
Provides uniform interface between controller and kernel
 System call – request to the OS to allow user to wait for
I/O completion
 Device-status table contains entry for each I/O device
indicating its type,

 Computer system can be divided into four components:

1. Hardware – provides basic computing resources
 CPU, memory, I/O devices
2. Operating system
 Controls and coordinates use of hardware among
various applications and users
3. Application programs – define the ways in which the
system resources are used to solve the computing problems of
the users
Word processors, compilers, web browsers
4. Users
 OS is a resource allocator
 Manages all resources
 Decides between conflicting requests for efficient and fair
resource use
  OS is a control program
 Controls execution of programs to prevent errors and improper
use of the computer

Main Memory:
 The only large storage media directly accessible by the CPU.
 Features RAM.
 Typically volatile (data is lost when power is off).
Secondary Storage:
 Extension of main memory with large
 nonvolatile storage capacity.
Hard Disks:
 Constructed with rigid metal or glass platters coated with magnetic
recording material.
 Disk surface is logically divided into tracks, further subdivided into
sectors.
 A disk controller manages logical interactions between the disk
and the computer.
Solid-State Disks (SSDs):
 Faster than hard disks.
 Nonvolatile.
Lecture 2-
 Clustered Systems: Multiple systems work together, often
using shared storage (SAN) for high availability.
 A Dual-Core Design: Multi-chip and multicore

 Multiprocessors advantages include:

 Increased throughput
 Economy of scale
 Increased reliability

 Two types:
 Asymmetric Multiprocessing – each processor is assigned
a specific task.
 Symmetric Multiprocessing – each processor performs all
tasks

 Clustered Systems: Multiple systems work together, often using

shared storage (SAN) for high availability.”
 Asymmetric Clustering: One machine is on standby.
 Symmetric Clustering: Nodes actively monitor and share
tasks.
* Some clusters are optimized for high-performance
computing (HPC).
* Some have distributed lock manager (DLM) to avoid
conflicting operations

 Multiprogramming: Organizes jobs to maximize CPU utilization.

 Timesharing (Multitasking): Extends multiprogramming, allowing
user interaction with processes.
 *Features like job scheduling, CPU scheduling, swapping, and virtual
memory manage processes effectively.

Interrupts: Triggered by hardware or software for error handling or

service requests.
Dual-mode operations: Dual-mode operation allows OS to protect itself
and other system components
 User mode and kernel mode
 Mode bit provided by hardware
 Mode bit distinguishes user and kernel code. Privileged
instructions run only in kernel mode. System calls switch
to kernel mode; returning resets to user mode.
Timers: Prevent resource hogging and infinite loops by generating
interrupts after a set time.
Multiprocessor environment must provide cache coherency in
hardware

Process Management

 A process(active entity) is a program(passive entity) in

execution, requiring CPU, memory, I/O, and files.
 Single-threaded – one execution path; Multi-threaded – multiple
paths.
 OS manages process creation, deletion, suspension,
synchronization, and communication.

The operating system manages processes by:

 Creating and removing user and system processes.

 Pausing and resuming processes.
 Ensuring processes work together properly.
 Allowing processes to communicate.
 Preventing or handling process deadlocks.

Memory Management

1. Determines what is in memory and when, to optimize CPU

utilization.
2. OS tracks memory usage, moves processes in and out, and
allocates/deallocates memory.
3. Virtual memory allows execution of processes that are not
completely in memory.

. Storage Management
  Provides a logical view of storage, abstracting physical differences.
 File-System Management: Creates/deletes files, manages access
control, and maps storage.
 Mass Storage Management:
o Disk Management – free-space, allocation, and disk
scheduling.
o Tertiary Storage – slower storage like optical disks,
managed differently.

I/O Subsystem

 Hides hardware details from users.

 Handles buffering, caching, and spooling.
 Uses device drivers for hardware interaction.

Protection and Security

 Protection: Controls process and user access to system resources.

 Security: Prevents attacks (e.g., denial-of-service, viruses, identity
theft).
 Uses user IDs (UIDs) and group IDs (GIDs) for access control.
 Privilege escalation allows users to gain higher permissions when
needed.

Computing Environments

 Traditional: Standalone systems, but now mostly networked.

 Mobile: Smartphones, tablets with extra OS features (GPS,
gyroscope).
 Distributed: Multiple networked systems acting together (LAN,
WAN, etc.).
 Client-Server: Clients request services from central servers.
o Compute-server system provides an interface to client to
request services (i.e., database)
o File-server system provides interface for clients to store and
retrieve files

 Peer-to-Peer (P2P): No distinction between clients and servers; all

nodes are equal
 Network Operating System provides features between systems
across network
o Communication scheme allows systems to exchange
messages
o Illusion of a single system

Virtualization

 Running multiple OS instances on the same hardware.

  Used for testing, application development, and running
multiple environments.
 Types: Emulation (slow) vs. native virtualization (fast)

Cloud Computing

 Uses virtualization to provide computing, storage, and

applications as services.
 Types of Cloud:
o Public – accessible to anyone for a fee.
o Private – company-specific.
o Hybrid – combination of both.
 Service Models:
o SaaS – software as a service (e.g., Google Docs).
o PaaS – platform as a service (e.g., cloud-based databases).
o IaaS – infrastructure as a service (e.g., cloud storage).

11. Real-Time Embedded Systems

 Used in special-purpose applications (e.g., medical devices, car

systems).
 Real-time OS must meet strict time constraints.

12. Open-Source Operating Systems

 OS with publicly available source code (e.g., Linux, BSD UNIX).

 Promoted by Free Software Foundation (FSF) and uses the GNU
Public License (GPL).
 Virtualization tools like VMware and VirtualBox help run multiple OS
instances.
LECTURE 5

Slide 2: Resources

Summary:

 A resource is anything a process needs (e.g., printer, lock, database

table).
 Two types of resources:
o Preemptable: Can be taken without harm (e.g., memory).
o Non-preemptable: Cannot be taken without causing failure
(e.g., printer).
 Processes must request and release resources properly to avoid
issues.

Slide 3: System Model

Summary:

 System has resource types like CPU, memory, I/O devices.

 Each resource type has a limited number of instances.
 Resource usage steps:
o Request
o Use
o Release

Slide 4: Using Resources

Summary: If a request is denied:

¤Requesting process has options

Block and wait for resource
Continue (if possible) without it: may be able to use an alternate resource
Process fails with error code
Slide 5: When Do Deadlocks Happen?

Summary:

 Example: Process 1 holds A, wants B; Process 2 holds B, wants A —

both are stuck.
 Deadlock happens when each process is waiting for a resource held
by another.

Slide 6: What is a Deadlock?

Definition:

 Deadlock = Each process is waiting for something only another can

release.
 Result: None of the processes can run, release, or proceed.

Slide 7: Deadlock Characterization

Four necessary conditions:

1. Mutual exclusion – Only one process uses a resource.

2. Hold and wait – Process holds one resource while waiting for
others.
3. No preemption – Resources can’t be forcibly taken.
4. Circular wait – Circular chain of processes waiting on each other.

Slide 8: Dealing With Deadlocks

Summary:

 Options for the OS:

o Ignore the problem (hope it won’t happen).
o Detect and recover.
o Avoid it by careful resource allocation.
o Prevent it by breaking one of the four conditions.
Slide 9: Ostrich Algorithm

Summary:

 Just ignore deadlocks (like an ostrich).

 Used if:
o Deadlocks are rare.
o Prevention costs are high.
 Common in UNIX and Windows.
 Recovery usually = rebooting.

Slide 10: Preventing Deadlock

Summary:

 Break at least one of the four conditions to prevent deadlocks.

 Not always practical but possible in some cases.

Slide 11: Eliminating Mutual Exclusion

Summary:

 Some devices like printers can be spooled (handled by a daemon).

 Fewer processes get direct access.
 Avoid assigning resources unless necessary.

Slide 12: Attacking “Hold and Wait”

Summary:

 Require processes to request all resources at the start.

 Or release all before requesting new ones.
 Problems:
o May not know needs upfront.
o Wastes resources.
o Risk of losing resources before getting new ones.
Slide 13: Attacking “No Preemption”

Summary:

 Preemption is tricky.
 Taking a printer mid-job = chaos.
 Can work for resources like memory pages (can be restored).

Slide 14: Attacking “Circular Wait”

Summary:

 Assign a numeric order to resources.

 Always acquire resources in increasing order.
 Prevents circular dependencies and deadlocks.

Slide 15: Deadlock Prevention Summary

Summary:

Condition How to Prevent

Mutual
Spool resources
Exclusion
Hold & Wait Request everything at once
Take resources back (if
No Preemption
possible)
Circular Wait Order resources numerically

Slide 16: Resource Allocation Graph

Summary:

 Graph with:
o Processes (P) and Resources (R).
o Request edge: P → R
o Assignment edge: R → P
Slide 17: Resource Allocation Graph (Cont.)

Summary:

 Shows how processes request and hold resources.

 Visual way to track and detect deadlocks.

Slide 18: Resource Allocation Graph Examples

Summary:

 Example:
o C holds T, wants U.
o D holds U, wants T.
o → Deadlock
 Helps visualize issues.

Slide 19: Multiple Resources and Cycles

Summary:

 No cycle = no deadlock.
 Cycle:
o With one instance per resource = deadlock.
o With multiple instances = possible deadlock.

Slide 20: Detecting Deadlocks Using Graphs

Summary:

 Graph or table shows who holds or requests what.

 Cycle in graph = deadlock.
 Some processes may not be in deadlock even if others are.

Slide 21: Recovering from Deadlock: Options

Recovery Strategies:

1. Preemption: Take resources away.

2. Rollback: Use saved checkpoints to go back.
 3. Killing processes: End one to free resources.

Slide 22: Deadlock Recovery – Process Termination

Summary:

 Abort all deadlocked processes or one at a time.

 Choose based on:
o Process priority.
o Execution time.
o Resources used/needed.
o Process type (interactive or batch).

Slide 23: Deadlock Avoidance

Summary:

 Each process declares maximum resource needs.

 OS ensures allocation won’t lead to circular wait.
 Based on resource-allocation state (available, allocated, max).

Slide 24: Summary

Summary:

 Deadlock = process waits for a resource held by another.

 Four required conditions: Mutual Exclusion, Hold & Wait, No
Preemption, Circular Wait.
 Ways to deal with deadlock:
o Ignore it.
o Prevent it.
o Detect and recover.
o Avoid it with smart allocation.
LECTURE 6

Here is a clear and focused summary of the text-only slides from Chapter 6:
Memory Management of your Operating Systems Security course. I've skipped
image-only slides and retained definitions in simple terms for easier studying.

Introduction

 A computer must load programs and data into memory to run them.
 Keeping multiple processes in memory improves CPU use and system
response time.
 Memory management methods depend heavily on hardware support.

Memory Basics

 Memory = a big array of bytes, each with a unique address.

 CPU uses the program counter to fetch and execute instructions.
 Instructions may also load data from or write results to memory.

Background

 Programs must be loaded from disk into memory to run.

 Only registers and main memory are directly accessible to the CPU.
 Cache memory helps bridge the speed gap between the CPU and main
memory.
 Memory access protection is essential for system stability.

Base and Limit Registers

 These registers define the valid memory address range for a program.
 The CPU checks every user-mode memory access to stay within this range.

Binding of Instructions and Data

 Compile-time binding: Hardcoded memory addresses; must recompile if

changed.
 Load-time binding: Uses relocatable code.
 Execution-time binding: Final addresses assigned during execution
(most flexible, needs hardware support).
Logical vs. Physical Addresses

 Logical (virtual) address: generated by CPU.

 Physical address: actual location in memory hardware.
 They can differ depending on when binding happens.

Swapping

 Swapping = moving a process in/out of memory to/from disk.

 Used when memory is full; allows running more programs than fit in RAM.
 Backing store: A large, fast disk that holds swapped-out programs.
 Roll out, roll in: Swap low-priority processes out to run high-priority
ones.

Context Switching with Swapping

 Swapping adds delay to context switching (can take several seconds).

 Reduce delay by:
o Swapping only the needed memory.
o Using system calls like request_memory().

Swapping Constraints

 If a process is doing I/O, it can't be swapped out without complications.

 Double buffering: Temporarily holds data in kernel before device
transfer.
 Modern OSs rarely use full swapping; they use it only when memory is
critically low.

Contiguous Allocation

 Memory split into two parts: one for the OS and one for user processes.
 Each process gets one continuous memory block.

Memory Protection

 Relocation register: Holds the starting address of the process.

  Limit register: Ensures memory access stays within range.
 Allows dynamic resizing and moving of memory segments.

Dynamic Storage Allocation

 How to choose memory blocks for new processes:

o First-fit: First available hole.
o Best-fit: Smallest available hole.
o Worst-fit: Largest hole.
 First-fit and best-fit usually perform better.

Fragmentation

 External: Enough free memory overall, but not in one block.

 Internal: Allocated memory slightly more than needed, leaving unused
space.
 50% rule: For every 2 blocks used, 1 block gets lost to fragmentation.

Compaction

 Rearranges memory to combine free space into one block.

 Requires dynamic relocation (i.e., changing memory addresses during
execution).

Paging

 Allows non-contiguous memory allocation.

 Physical memory split into frames, logical memory into pages.
 Page size is power of 2 (e.g., 512 bytes to 16MB).
 A page table maps logical pages to physical frames.
 Reduces external fragmentation, but may still have internal fragmentation.

Paging Mechanics

 CPU uses page number and offset from logical address to find the physical
address.
 Logical address: High bits = page number; low bits = offset within page.
Segmentation

 Divides program logically into segments like functions, variables, arrays,

etc.
 Each segment has a separate address space.
 Helps reflect the programmer's view of memory.

Final Summary

 Main memory = fast internal memory (RAM).

 Processes need to be in memory to run; if not enough space, OS uses
disk (swapping).
 Contiguous allocation gives each process a single block.
 Paging solves external fragmentation by allowing non-contiguous
allocation.
 Memory protection ensures a process only accesses its own memory.
 Fragmentation is wasted space in memory. Paging eliminates external
fragmentation, but not internal
Lecture 8 :

📘 Chapter 8: File System

1. File Concept

 A file holds data or program code.

 Data types: text, binary, program files.

2. File Attributes

 Name, identifier, type, location, size, protection, timestamps.

 Stored in a special structure called a directory.

3. File Operations

 You can create, read, write, seek, delete, open, and close files.

4. File Concepts: Storage Methods

 Contiguous: Stored in one block.

 Linked list: Each piece points to the next.
 Indexed: Use an index block to keep track of file parts.

5. Open Files

 OS keeps an open-file table to manage files in use.

 Tracks file pointer, access rights, and how many users have opened the
file.

6. File Locking

 Prevents conflicts when multiple processes access a file:

o Shared lock: Multiple can read.
o Exclusive lock: Only one can write.
 Mandatory vs Advisory locking.

7. File Structure

 Can be:
o No structure (just bytes)
o Record-based (lines, fixed/variable)
o Complex formats like executables

8. Access Methods

 Sequential: Read/write in order.

  Direct: Jump to specific block using block numbers.

9. Directory Structure

 Stores info about files.

 Located on disk with the files themselves.

10. Disk Structure

 Disk may be split into partitions/volumes.

 RAID can protect data across disks.

11. Directory Operations

 Common actions: Search, create, delete, list, rename, and traverse.

12. Directory Organization

 Must support fast search, multiple names, and grouping.

13. Single-Level Directory

 All files in one big list – easy, but confusing if many users.

14. Two-Level Directory

 Each user has their own directory.

 Still limited grouping options.

15. Tree-Structured Directories

 Like a file system tree – supports subdirectories and better grouping.

16. File-System Mounting

 Before using a new file system, it must be "mounted" at a mount point.

17. File Sharing

 Multi-user systems allow file sharing using permissions.

 NFS (Network File System) used for remote sharing.

18. File Consistency Semantics

 Unix: Changes visible immediately.

 Session: Changes appear after closing the file.
 Immutable: Shared but unchangeable files.
19. Protection

 Users can set who can read/write/execute files.

20. Access Lists and Groups

 Unix/Linux has owner, group, others permissions.

 Example:
o 7 = RWX
o 6 = RW
o 1=X

21. Windows 7 ACLs

 Use Access Control Lists for file permissions.

22. Summary

 A file system organizes and tracks files.

 Different access and protection methods are used to ensure security.
Lecture 9:

📘 Chapter 9: Protection and Security

1. Goals of Protection

 System contains objects (files, memory, etc.)

 Protection ensures only authorized access to these objects.

2. Principles of Protection

 Least privilege: Only give minimal rights needed.

 Need to know: Users only access what they need.

3. Domain Structure

 Domain = what a process can access.

 Access right = what operations can be done on an object.

4. Access Matrix

 A table:
o Rows = domains (users/processes)
o Columns = objects (files, devices)
o Cells = what access (read, write, etc.)

5. Use of Access Matrix

 Shows what actions are allowed.

 Can include special rights like owner, control, or copy.

6. Use of Matrix (Cont.)

 Policy: What should be allowed

 Mechanism: How the OS enforces that policy

7. Security Problem

 Threat = possible attack

 Attack = attempt to breach security
 Secure system = works only as intended (but perfect security is
impossible)

8. Violation Categories

 Confidentiality: Read without permission

 Integrity: Change data without permission
  Availability: Destroy or deny access to data
 Service theft: Use without paying
 DOS: Prevent others from using the system

9. Violation Methods

 Masquerading: Pretending to be someone else

 Replay attack: Reuse data
 Man-in-the-middle: Intercept communication
 Session hijacking: Take over a session

10. Security Levels

 Protection must occur at:

o Physical
o Human
o OS
o Network
 One weak link can break the chain.

11–13. Program Threats

 Trojan horse: Program that misbehaves

 Spyware: Secretly collects data
 Trapdoor: Secret way to bypass security
 Buffer overflow: Overwrites memory to execute attack
 Virus: Self-replicating code

14. Virus Example

 Code snippet shows how a virus can format a hard drive.

15. Threat Evolution

 Attacks now used for crime (not just hacking).

 Botnets: Networks of infected machines
 Keystroke loggers: Capture passwords

16. System/Network Threats

 Worms: Spread across network on their own

 Port scanning: Find vulnerabilities
 Tools like nmap, nessus used by attackers

17. Denial of Service

 Overload system so it can’t respond.

 DDOS: Many computers attack together.
18. Cryptography

 Used to secure communication.

 Encryption: Hide data so only those with the key can read it.

19. Passwords

 Stored in encrypted form

 Add a salt to prevent duplicate encryption
 One-time passwords and biometrics add more security

20. Security Defenses

 Defense in depth: Many layers

 Vulnerability assessment: Check for weaknesses
 Intrusion detection: Find attacks
o Signature-based
o Anomaly-based

21. Firewalls

 Block untrusted network access

 Personal firewall: On one computer
 Application firewall: Understands app-level traffic
 System-call firewall: Controls OS functions
Lecture 10:

📘 Chapter 10: Threat Modeling

Operating System Security

🔹 Slide 1: Threat Modeling - What Is It?

 Threat modeling = A process to identify, prioritize, and address

threats in a system.
 Focus: What could go wrong? Who could attack? What’s most valuable to
attackers?
 Helps answer:
o “Where am I most vulnerable?”
o “What are the biggest threats?”
o “How do I protect my system?”

🔹 Slide 2: What Does It Contain?

A typical threat model includes:

 System description or diagram (what you’re analyzing)

 Assumptions (about how the system behaves or what attackers can do)
 List of threats
 Actions or mitigations for each threat
 Validation steps (to check if mitigations are working)

🔹 Slide 3: Why Threat Model?

 Helps build secure systems

 Allows smart use of resources (time, money, effort)
 Connects developers and security teams with shared goals
 Finds and documents:
o Threats
o Compliance requirements
o Security controls
 Ensures business needs are protected from attacks or accidents
 Creates test cases for security
🔹 Slide 4: STRIDE – Threat Categories

STRIDE is a model used to categorize different types of threats:

 Spoofing – Pretending to be someone else (fake identity)

 Tampering – Changing data or code
 Repudiation – Denying actions (e.g., user says "I didn’t do that")
 Information disclosure – Leaking data
 Denial of service – Blocking access to services
 Elevation of privilege – Gaining higher access than allowed

🔹 Slide 5: How to Start: Diagram First

Start with a whiteboard sketch:

 Draw external interactors (actors) – users or systems

 Add processes – like servers, apps
 Add data stores – databases or logs
 Connect everything using data flows
 Make sure the story makes sense and reflects the real system

🔹 Slide 6: Diagramming Details

Use DFDs (Data Flow Diagrams) that show:

 Processes
 Data stores
 Data flows
 Trust boundaries – lines showing where trust changes (e.g., between
internet and server)

Tips:

 Keep diagrams updated

 Label and number everything
 Note all assumptions and dependencies

🔹 Slide 7: Diagram Elements

These are basic components of a DFD:

 External entity – Something outside your system

 Process – Task or program
 Data Flow – Movement of information
  Data Store – Where data is saved
 Trust Boundary – Divide between trusted and untrusted zones

🔹 Slide 8: Identifying Threats per Element

Use STRIDE with each diagram element:

 External Entity: Spoofing, Repudiation

 Process: All six STRIDE threats apply
 Data Flow: Tampering, Information Disclosure, Denial of Service
 Data Store: TID (same as above), plus Repudiation if logs are involved

🔹 Slide 9: Apply STRIDE to All Diagram Elements

 For each item, match relevant STRIDE threats

 Focus especially on elements crossing trust boundaries
 Number and document everything so nothing is missed

🔹 Slide 10: Mitigation – The Point of Threat Modeling

Threat modeling is useless without mitigation!

 Purpose is to protect users by:

o Designing secure software
o Finding and fixing problems
o Tracking threats and resolutions using bug reports

🔹 Slide 11: Mitigate – How to Fix Threats

You can address threats in 4 ways:

1. Redesign the system to avoid the threat

2. Apply known solutions (standard mitigations)
3. Invent new solutions (if none exist)
4. Accept the risk (if it’s very low or unavoidable)

🔹 Slide 12: Standard vs Invented Mitigations

 Standard mitigations are safer and recommended

  Inventing your own is risky:
o Might look like it works, but could be flawed
o Needs expert review
 If you must invent one, get help from security experts

🔹 Slide 13: Validating Threat Models

Validation = Check if your model and fixes are good Ask:

 Does the diagram match the actual system?

 Have all threats been listed?
 Did testers review it and make test plans?
 Are all threats mitigated correctly?

🔹 Slide 14: Validate Quality of Threats & Fixes

Good threats must:

 Describe the attack

 Show the context and impact

Good mitigations must:

 Be linked to a threat
 Be clearly explained
 Be tested

Reminder: Fuzzing (random testing) is a test method, not a mitigation!

🔹 Slide 15: Validate What Info You Captured

Check:

 Dependencies: What third-party code or libraries are you using?

 Are those dependencies secure?
 Did you verify their security functions?

🔹 Slide 16–17: Patch Management

 Keep all systems up to date with patches!

 Challenges:
o Know what’s installed, where, by whom
 o Track new vulnerabilities and patches

Tips:

 Classify assets (e.g., critical vs optional)

 Mirror test environment before applying patches
 Have a back-out plan in case things go wrong
 Automate tracking and installation
 Keep clear documentation

🔹 Slide 18–20: Hardening the Operating System

Hardening = Making OS more secure

Key actions:

 Create security policies and training

 Plan for security from start to end of system life
 Use firewalls and DMZs to isolate networks
 Ensure redundancy for critical components
 Systems should fail securely, not crash dangerously

🔹 Slide 21–22: Hardening – More Techniques

 Disable unused ports/services

 Restrict physical access
 Use role-based access control (give users only what they need)
 Use strong passwords
 Apply encryption
 Audit logs to track critical system events
 Test patches before installing them

🔹 Slide 23: Hardening – Final Steps

 Apply patches automatically when possible

 Limit file sharing and unnecessary features
 Configure permissions tightly
 Remove unused software or services
 Log all activity and errors
 Enforce group policies
 Set and maintain secure system configurations