Lecture Capture

IN2011 n Audio and Data Projector content is

Networks and Operating Systems being captured for this session (I hope!)
l Note: no video is being recorded
n Recordings will be made available in the
Session 2 Echo360 block for this module in
Moodle within a few days of the lecture
System Calls, Services and
System Boot

IN2011 Nets & Ops Session 2 2

Overview Protection

n Protection n An OS provides various forms of

n Dual-mode: user-mode vs kernel-mode protection, including:
l prevent one process from accessing a resource
n System Calls (eg memory) allocated to another
n OS Services (brief overview) l prevent some processes from denying CPU-time
to others
n OS and Kernel structure l prevent file permission controls from being
subverted (eg by direct access to disk controller)
n System Boot
l ...others?

IN2011 Nets & Ops Session 2 3 IN2011 Nets & Ops Session 2 4

Thought Experiment Dual Mode Operation

n Suppose we have a line-printer device n Dual-mode CPU operation allows OS

l To print a line of text we place it in memory and to implement protection mechanisms
write its address into a specified register with hardware support
n What can happen if arbitrary programs n user mode and kernel mode
are allowed to access the device l mode bit provided by hardware
directly? l allows CPU to distinguish when system is running
user code or kernel code
n Can we devise a scheme to manage the l some CPU instructions/registers/memory locations
are privileged: the CPU will only execute/access
printer properly? them when in kernel mode

IN2011 Nets & Ops Session 2 5 IN2011 Nets & Ops Session 1 6

1
 CPU modes in practice Meltdown

n The details of how mode-based protection n Meltdown is fundamentally a failure of the

works in a real architecture can be quite
complicated
n Example: how things work for Intel x86
http://duartes.org/gustavo/blog/post/cpu-rings-
privilege-and-protection
(not examinable)
kernel-mode check on Intel chips
n During speculative instruction execution, the
check can happen concurrently with an illegal
memory fetch, allowing the fetch to proceed
l The permission violation is detected, and the memory fetch
result is erased, but…
l … by then it has affected the cache, allowing information to
be leaked via covert timing channels

IN2011 Nets & Ops Session 1 7 IN2011 Nets & Ops Session 2 8

How the OS uses dual-modes System Calls

n The system-call/interrupts framework n System calls allow user processes to

ensures that: request the kernel to carry out privileged
operations on their behalf
l kernel code (in particular, interrupt handlers)
runs in kernel mode
l everything else runs in user mode
n System calls and Interrupts cause switch
to kernel mode, return from call switches Software interrupt
back to user mode

IN2011 Nets & Ops Session 2 9 IN2011 Nets & Ops Session 1 10

Key Types of System Calls System calls: example sequence

n Process control n Demo: cat contents of a file to screen

n File manipulation l trace with strace
l http://www.kernel.org/doc/man-
n Device manipulation pages/online/pages/man2/syscalls.2.html
n Information maintenance
n Communications
n Protection

IN2011 Nets & Ops Session 2 11 IN2011 Nets & Ops Session 2 12

2
 System Call APIs System Call Implementation

n System calls are usually accessed via a n A small integer number is associated
high-level Application Program Interface with each system call
(API) rather than directly l System-call interface maintains a table of
l Common APIs: Win32 API for Windows; POSIX privileged (ie kernel) code locations, indexed
API for POSIX-based systems (including virtually according to these numbers
all versions of UNIX, Linux, and Mac OS X); Java n The system call interface invokes the
API for the Java virtual machine (JVM)
intended system call code in the OS
n Why use APIs rather than direct system kernel and returns the status of the
calls? system call and any return values

IN2011 Nets & Ops Session 2 13 IN2011 Nets & Ops Session 2 14

System Call Parameter Passing Parameter Passing via Table

n Three general methods used to pass

parameters to the OS
l Simplest: pass the parameters in registers
4 In some cases, may be more parameters than registers
l Parameters stored in a block, or table, in memory,
and address of block passed as a parameter in a
register
l Parameters pushed onto the stack by the program
and popped off the stack by the operating system

IN2011 Nets & Ops Session 2 15 IN2011 Nets & Ops Session 2 16

API Example OS Services

n The ReadFile() function in the Win32 API
n User interface
l Varies between Command-Line (CLI), GUI, Batch
n Program execution
l load a program into memory and run it; end
execution

n A description of the parameters: n I/O operations

l HANDLE file—the file to be read
l LPVOID buffer—a buffer where the data will be read into and written from n File-system:
l DWORD bytesToRead—the number of bytes to be read into the buffer
l LPDWORD bytesRead—the number of bytes read during the last read l read, write, create, delete, search, list file info,
l LPOVERLAPPED ovl—indicates if overlapped (asynchronous) I/O is being permission management
used

IN2011 Nets & Ops Session 2 17 IN2011 Nets & Ops Session 2 18

3
 A Layered View
IN2011 Nets & Ops Session 2
OS Services (Cont)
n Another set of OS functions exists for
ensuring the efficient operation of the
system itself via resource sharing
l Resource allocation - When multiple
users or multiple jobs running concurrently,
resources must be allocated to each of
them
l Accounting - To keep track of which users
use how much and what kinds of computer
resources
IN2011 Nets & Ops Session 2
Operating System Design
n Internal structure of different Operating
Systems can vary widely
n Start by defining goals
l User goals – operating system should be
convenient to use, easy to learn, reliable, safe,
and fast
l System goals – operating system should be easy
to design, implement, and maintain, as well as
flexible, reliable, error-free, and efficient
IN2011 Nets & Ops Session 2
OS Services (Cont)
n Communications (inter-process)
l via shared memory or through message passing
n Error detection
l Errors may occur in the CPU and memory
hardware, in I/O devices, in user programs
l For each type of error, OS should take appropriate
action to ensure system integrity and to limit
consequences
19 IN2011 Nets & Ops Session 2 20
OS Services (cont)
n Protection and security
l Protection involves ensuring that all access to
system resources is controlled and preventing
concurrent processes from interefering with each
other
l Security of the system from outsiders requires
user authentication, extends to defending external
I/O devices from invalid access attempts
n If a system is to be protected and
secure, precautions must be instituted
throughout it. A chain is only as strong
as its weakest link.
21 IN2011 Nets & Ops Session 2 22
OS Design (Cont)
n Important principle to separate
Policy: What will be done?
Mechanism: How to do it?
n Mechanisms determine how to do
something, policies decide what must
be done
l The separation of policy from mechanism is a very
important principle, it allows maximum flexibility if
policy decisions are to be changed later
23 IN2011 Nets & Ops Session 2 24
4
 Layered Structure MS-DOS Layer Structure (Bad!)

Violation of
layering!
Protection
not enforced

IN2011 Nets & Ops Session 2 25 IN2011 Nets & Ops Session 2 26

Traditional UNIX System Structure UNIX

n Limited by hardware functionality, the

original UNIX operating system had
limited structuring:
l Systems programs
l The kernel
4 Everything below the system-call interface and above the
physical hardware
4 Provides the file system, CPU scheduling, memory
management, and other operating-system functions; a
large number of functions for one level

IN2011 Nets & Ops Session 2 27 IN2011 Nets & Ops Session 2 28

Microkernel System Structure Modules

n Moves as much as possible from the n Most modern operating systems

kernel into “user” space implement kernel modules
l Communication takes place between user l Uses object-oriented approach
modules using message passing l Each core component is separate
n Benefits: l Each talks to the others over known interfaces
l Easier to extend; Easier to port; More reliable; l Each is loadable as needed within the kernel
More secure
n Overall, similar to layers but with more
n Detriments: flexibility
l Performance overhead of user space to kernel
space communication
IN2011 Nets & Ops Session 2 29 IN2011 Nets & Ops Session 2 30

5
 System Boot Linux Boot on x86

n Operating system must be made

available to the hardware (CPU,
memory), so that it can be executed
l Small piece of code – bootstrap loader, locates
the kernel, loads it into memory, and starts it
l Sometimes two-step process where boot block at
fixed location loads bootstrap loader
l When power initialized on system, execution starts
at a fixed memory location http://duartes.org/gustavo/blog/post/how-computers-boot-up
4 Firmware is used to hold initial boot code

IN2011 Nets & Ops Session 2 31 IN2011 Nets & Ops Session 2 32

Hardware Initialisation on x86 MBR on x86

n Power on n Master Boot Record (MBR)

l hardware initialisation (OS not yet involved) l BIOS looks on boot device (eg first 512 bytes of disk
l one CPU chosen to run BIOS sector) for MBR containing a tiny chunk of code
4 CPU in “real mode” (unprotected) at this point l The MBR itself is generic but it is used to load an
l BIOS loaded from firmware and executed OS-specific boot-loader
4 Linux: use Grub to create and install a new MBR
n BIOS (Basic Input/Output System)
n BIOS loads MBR code into memory and
l Power-On-Self-Test (POST): hardware tests
jumps into it
l If POST ok, BIOS looks for a “boot device”
l MBR code finds the “boot-loader” on disk (Grub, in
4 configurable: CD drive, USB, hard disk, network interface
our case) and jumps into that

IN2011 Nets & Ops Session 2 33 IN2011 Nets & Ops Session 2 34

Grub Bootstrapping the Linux Kernel

n Grub (if so configured) presents user
n CPU is still in "real mode" (unprotected)
with a menu offering a choice of OS
l not necessarily Linux! n After early stages of bootstrap, the code
instructs CPU to switch to protected
n Grub reads kernel image from file
(dual-mode) operation
l /boot/vmlinuz-3.16.0-4-586 in our case
l the “z” indicates a compressed image n Bootstrap code then decompresses the
kernel-image
n The contents of this file are copied into
l and jumps in to it!
memory
l now the kernel is up and running
l Grub jumps in to “bootstrap” code which is now in
memory
IN2011 Nets & Ops Session 2 35 IN2011 Nets & Ops Session 2 36

6
 Linux Kernel Initialisation Kernel Parameters

n Kernel has a lot of work to do before it is n The behaviour of the kernel at start up is
ready for normal business configurable by setting various kernel
l in particular, initialising the file system (using initrd)
parameters
l we will gloss over the details n Examples in the GRUB menu entries:
n At the very end of initialisation, the kernel l ro mount root file system read-only (init
may remount it read-write later)
runs /sbin/init (but see next slide)
l quiet suppress lots of boot-time messages
l init consults /etc/inittab to determine which
user-mode processes (services) it should start l init=file run file instead of /sbin/init
l networking, mail system, X-windows, etc

IN2011 Nets & Ops Session 2 37 IN2011 Nets & Ops Session 2 38

What you should do now…

n Labs
n Preparation for Session 3
l see Moodle

IN2011 Nets & Ops Session 1 39