|
|
| Line 96: |
Line 96: |
| - e.g., when was it last accessed | | - e.g., when was it last accessed |
| </pre> | | </pre> |
|
| |
| Announcements
| |
| You may want to use Openstack after midterm
| |
| Semaphore tutorial is like kernel code
| |
| Tutorial similar to assignment!
| |
|
| |
| Additional Notes
| |
| Segmentation
| |
| Inode fields
| |
| Page table entries
| |
| Scheduling
| |
|
| |
| Paging - fixed sized memory allocations of usually 4k or 8k blocks (cab have some larger ones)
| |
|
| |
| Paging only works well if you have hardware to help you - specifically Memory Management Unit
| |
| Need page tables, TLB (Translation Lookaside Buffer: memory cache that speeds up access time to a user memory lcoation)
| |
| Do "table lookup" on every memory access
| |
|
| |
| If you do not have full paging support how would you manage memory?
| |
| Basic approach: put everything at a fixed place in memory
| |
| - Useful if you have limited RAM
| |
|
| |
| Classic Way: Put code, data into "segments" instead of pages
| |
| - Semantic units of memory (stack, heap, "text")
| |
| - Execve loads segments into memory
| |
| - Still use this terminology when referring to parts of a binary program
| |
|
| |
| Segments:
| |
| Variable sized block of memory
| |
| Base: starting address
| |
| Bound: how long is it
| |
| Key idea is segments can be placed in different parts of the address space:
| |
| - to move, you just change the base
| |
| - Code inside a segment refers to rest of segment via offsets
| |
| - On each memory access, CPU adds segment register to offset to get physical address
| |
| - Having a base address with offsets is still used in userspace
| |
|
| |
| 16-bit x86 (8086) is a segmented architecture
| |
| - Memory access is msotly relative toa segment base address
| |
| Standard modes for 32-bit x86 (80386+) and 64-bit x86 (amd64) is "flat" things can be wherever
| |
| - Segmented memory can be a pain because it can "wrap around" - going past the last address can put you in the first, or it just gives error
| |
|
| |
| Inode fields:
| |
| Stat, lstat gives you details on an inode
| |
| Inodes allows access to contents of files and have metadata such as indoe number, user id, stuff about time
| |
| - Size
| |
| - "Mode" - rwx (he shoes us how to change read write permissions the normal way and also using chmod number to set individual bits and also through GUI), others
| |
| - Owner, group
| |
|
| |
| Xdg-open foo.js same as double clicking knows what preferred program to open a file
| |
|
| |
| Users, groups
| |
| Users and group are used to restrict access
| |
| - each file has a user and group associated with it, permissions
| |
| - Each process has a user and group
| |
| What if file ownership/permissions are "wrong"
| |
| - Use "whoami" command to find user class
| |
| In UNIX root user has all power
| |
| - Can bypass all permission checks (Equivalent to Administrator on Windows)
| |
| - Dangerous because you can become another user and do anything
| |
| - You can view permission model in System Monitor and see processes owned by root, anilclass, etc. Regular users users cannot usually send kill commands to other processes. If you are the root no one else can send you a signal but you can have access to everything so very dangerous if attacker takes over root
| |
| - Id command calls getuid
| |
| - Kernel does not know where username is stored
| |
| - Hash function returns fixed size input over variable input and are used to securely store passwords. Even the hashes are stored in shadow files because you can password breach by guessing the password and hashing it and comparing it to the hashed password values. Lot of work but can be successful if you have a weak common password. There are rainbow tables that store some of the hashed passwords. Hashed password stored in etc\shadow
| |
|
| |
| Page tavle entries
| |
| Page tables are like tables (actually more like very wide trees) used to map virtual adrdress to phsyical address
| |
| Contain top bits of physical address along with metadata
| |
| - Readable?, writable? - executable (contains binary code)?
| |
| Most pages are either r+x(code) or r+w(data)
| |
Video
Video from the lecture given on October 17, 2017 is now available.
Notes
In-Class
Lecture 12
----------
* segmentation
* inode fields
* page table entries
* scheduling
paging, blocks - fixed-sized memory allocations
- typically 4K or 8K (can have some huge ones)
paging only works well if you have MMU
- need page tables, TLB
- do "table lookup" on every memory access
How do you manage memory without paging?
* put everything at a fixed place in memory
- useful if you have very little RAM
* put code, data into "segments"
- semantic units of memory (stack, heap, "text")
- still use this terminology when referring to parts of a binary program
Segments:
* a variable-sized block of memory
* base: starting address
* bound: how long is it
Key idea is segments can be placed in different parts of the address space
- to move, you just change the base
- code inside a segment refers to rest of segment via offsets
- on each memory access, CPU adds segment register to offset to get
physical address
- having a base address with offsets is still used in userspace
16-bit x86 (8086) is a segmented architecture
- memory accesses are mostly relative to a segment base address
standard modes for 32-bit x86 (80386+) and 64-bit x86 (amd64) is "flat"
- segmented memory can be a pain because it can "wrap around" - going past
the last address can put you in the first, or it just gives you an error
inode fields
------------
- stat, lstat gives you details on an inode
- inodes allow access to contents of files and have the key metadata
- size
- "mode" - rwx, others
- owner, group
Users, groups
-------------
users and groups are used to restrict access
- each file has a user and group associated with it, permissions
- each process has a user and group
What if file ownership/permissions are "wrong"?
In UNIX, the "root" user has all power
- can bypass all permission checks
- (unless you are on a mandatory access control system such as seLinux)
- VERY DANGEROUS
(Equivalent to an administrator account on Windows)
Page table entries
------------------
page tables are "tables" (really very wide trees) of page table entries
page table entries contain the top bits of the physical address along with
metadata:
- readable?
- writable?
- executable?
most pages are either r+x (code) or r+w (data)
- valid?
- dirty?
- is data in page different from data on disk?
other bits to help with deciding what pages to keep in RAM or not
- e.g., when was it last accessed