Soma at 22:10, 30 October 2019

2019-10-30T22:10:38Z

← Older revision		Revision as of 22:10, 30 October 2019
Line 1:		Line 1:
	==Video==		==Video==

	Video from the lecture given on October 30, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec14-20191030.m4v is now available]. ~~(will be uploaded shortly)~~		Video from the lecture given on October 30, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec14-20191030.m4v is now available].

	==Notes==		==Notes==

Soma: Created page with "==Video== Video from the lecture given on October 30, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec14-20191030.m4v is now available]. (..."

2019-10-30T21:42:25Z

Created page with "==Video== Video from the lecture given on October 30, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec14-20191030.m4v is now available]. (..."

New page

==Video==

Video from the lecture given on October 30, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec14-20191030.m4v is now available]. (will be uploaded shortly)

==Notes==
<pre>
Lecture 14
----------

* midterm discussion on Friday
* tutorial grading
* next week

* CPU modes
* OS kernel & userspace
* VFS & filesystems
* SSH

Tutorial grading
* 3 points for work
* 1 point for talking with TA

What do we mean by an operating system kernel?

CPUs run in different modes
- there are multiple modes, but for this class we'll focus on two
- user mode and supervisor mode
- processes run in user mode
- the OS kernel runs in supervisor mode
- in user mode, the CPU has limited access to resources
- only memory for the current process
- no direct hardware access
- in supervisor mode, CPU has access to everything
- all memory
- all hardware
- job of the kernel is to share and abstract resources for processes
(code running in user mode on the CPU)

We'll be studying the Linux kernel
- Windows, MacOS X all have functionally equivalent kernels

We already have a way to interact with the kernel directly
- /proc and /sys
- every system call

system calls are unlike function calls because...

function calls
- put arguments in registers, stack
- call function (saves IP to stack)
- function puts return value in register or stack
- function calls ret, restores old IP

system call
- put argument in registers (maybe stack), including syscall number
- issue syscall instruction
- CPU switches to supervisor mode
- CPU invokes system call dispatcher
-- like a signal handler, but an "interrupt" handler
- system call dispatcher calls system call handler
- system call handler does work, returns
- scheduler chooses process to run
- CPU switches to user mode, starts executing selected process

CPUs have multiple "interrupts"
- potential events
- have handlers for each event
- events can be created by hardware or by special instructions (eg syscall)
- e.g., hard drives, keyboards, *timers*
- kernel installs handlers on system startup

Operating system code can be in a few places
- the kernel <--- our focus
- system processes
- libraries in regular processes (applications can mess with this)

On every UNIX system, process 1 is special
- it is "init", the process that starts all other processes
- on modern Linux, "init" is systemd (and systemd has a lot more to it)
- special because
- it reaps orphan processes (with systemd, there are in effect inits for each user that handle this)
- if it dies, the system shuts down

On older systems, kill -9 1 was a fast way to shutdown/reboot a system (as root!)
- not sure what it does today?

To the kernel, a file is just a thing that goes with certain system calls
- open, read, write, lseek, mmap, close
- for example, for open
- takes filename, figures out which filesystem this corresponds to
- finds "open" routine for that filesystem, calls it with rest of args

So, a filesystem is an implementation of the main filesystem routines
- for files, directories, and filesystem management

A filesystem is an interface that can have many implementations
- the "virtual file system" (VFS) interface in that interface!
- structs of function pointers (because it is all C)

Secure shell (SSH)
------------------
* main functionality: give secure remote access to a shell
- redirect standard in, out, error from remote process to local terminal or files

* there were older ways to do this (telnet, rsh), but they go in the clear over the network, and so are very very insecure

* SSH employs a mix of public key cryptography and symmetric key cryptography to secure connection

* Similar to TLS/SSL, but different

Public key cryptography
-----------------------
- traditional codes & cyphers have symmetric keys
- same key or code book used for encryption and decryption

- main limitation of symmetric key crypto: how do you share keys with strangers?

- public key crypto solves this by splitting keys into public and private keys

In order to set up SSH public key authentication
- generate a key pair, public and private
- put public key in .ssh/authorized_keys on remote system

Then to use, make sure your ssh client has access to the private key you generated

Remember when you use SSH, both the remote system and you have public/private key pairs for identification!

Disks to UNIX are block devices
- arrays of fixed-sized storage, e.g. 4096 bytes at a time
- filesystems have to store files in this array somehow

Formatting a filesystem
- puts an empty filesystem data structure on storage (disk)
- that data structure has to be robust
- because it has to last for years potentially
- should recover from simple corruption
</pre>

Operating Systems 2019F Lecture 14 - Revision history

Soma at 22:10, 30 October 2019

Soma: Created page with "==Video== Video from the lecture given on October 30, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec14-20191030.m4v is now available]. (..."