Operating Systems 2015F Lecture 22 - Revision history

Soma: /* Notes */

2015-11-27T20:42:08Z

Notes

← Older revision		Revision as of 20:42, 27 November 2015
Line 1:		Line 1:
			==Video==

			The video for the lecture given on November 27, 2015 [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec22-27Nov2015.mp4 is now available].

	==Notes==		==Notes==

	* ~~Explain generating~~, ~~format~~ of ~~patches~~ for ~~reports~~		<pre>
			Lecture 22
			----------

			Project
			- you need to pass the oral to get credit for it
			- Due December 4th by midnight, late penalty is 20%/day

			Patching

			Malware detection & operating systems

			* Most Linux systems don't run "antivirus"
			* Most Macs don't run antivirus
			* iOS devices don't
			* some Android devices do

			What does this tell us about those operating systems?
			- not that much
			- it is more about what exists today rather than what could exist

			Ideally your OS should only allow you to run "good" code.
			Antivirus is what you get when you are likely to run "bad" code.

			How do operating systems keep out bad code?
			* user authentication (accounts and passwords)
			* otherwise, mostly isolation
			* user permissions (not all users can access all
			resources)
			("users" are now often applications)
			* firewalls (isolate network connections to apps)
			* supervisor versus user mode on the CPU
			(kernel vs userspace)
			* memory protection (virtual memory)
			* CPU & I/O scheduling to prevent programs from
			monopolizing resources

			* Desktop OSs assume installed applications can be trusted
			- they are allowed to do arbitrary damage

			* Mobile OSs do not trust most applications, or greatly limit trust

			Android
			- applications can be trusted in different ways
			- user can decide what apps are trustworthy for different
			things
			- users will look at an app's permissions and decide
			whether it is worthy of the trust level requested
			- regular users are not sufficiently knowledgeable to make such trust decision

			- every app runs as a different user. Each app can only access its own files
			- but, then we have processes that accept requests from apps to access just about anything else


			* iOS sandboxing
			- OS-level virtualization: every app gets its own userspace
			- then iOS puts things in that "sandbox" that it deems
			safe to access

			On Android, you've always been able to install keyboards
			On iOS, only recently have keyboards been added
			- and they can't be used for passwords

			on iOS, Apple-supplied apps have always had more access

			What is antivirus?
			- downloader's remorse
			- or, I really shouldn't have installed that

			How does antivirus work?
			- tech equivalent to criminal profiling
			- their history
			- their behavior
			- their friends
			- profiling is fundamentally hard and limited
			- profiling is especially hard because of lies

			How do you catch the lies of programs?
			- surveillance

			all antivirus need kernel-level help to work
			why can't malware have kernel-level help?
			- that's a kernel-level rootkit

			Nexus (border control) for operating systems is...
			- code signing

			Code signing in any sort of "open context" is suspect

			App store signing is not bad

			Traditional OSs are for running "trusted" code

			We have the technology for running untrusted code.
			It is called a web browser.
			</pre>

Soma: Replaced content with "==Notes== * Explain generating, format of patches for reports"

2015-11-25T21:31:35Z

Replaced content with "==Notes== * Explain generating, format of patches for reports"

← Older revision		Revision as of 21:31, 25 November 2015
Line 1:		Line 1:
	~~==Video==~~

	~~The video for the lecture given on November 25, 2015 [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec21-25Nov2015.mp4 is now available].~~

	==Notes==		==Notes==

	~~<pre>~~		* Explain generating, format of patches for reports
	~~Lecture 21~~
	~~----------~~

	~~no last assignment~~

	~~What is research?~~
	* ~~Asking questions and figuring out the answers~~
	* Questions are much more important than answers
	* Questions are much harder than answers

	~~What question you ask determines what answer you'll get~~

	~~The research literature~~
	~~- many many publications~~
	~~- hard to tell what is any good~~

	~~Reseachers know who to trust in their area~~, ~~and, how in general to determine trust~~
	~~- do spot checks~~ for ~~obvious errors, based on what you do know~~
	~~- do they give full details about what they did? could you reproduce it?~~
	~~- surprising results require extraordinary evidence~~


	~~If you're outside the field, look at~~
	~~- publication reputation~~
	~~- citation counts and quality~~

	~~to learn more about operating systems research...~~
	~~what are the well-respected venues?~~

	~~Conferences, not journals~~

	~~USENIX OSDI~~
	~~ACM SOSP~~

	~~When should you really look at the research literature?~~

	~~You're trying to solve a hard problem and aren't sure what approach to take.~~
	* look to see what other people have done in response to similar problems!

	~~What about computer security?~~
	* even more publications

	~~But there's a truth to research...~~
	~~- most of it isn't any good~~

	~~Why?~~
	~~- a lot of research doesn't work in practice~~
	~~- a lot of conclusions are premature~~

	~~Computer security research is mostly bad~~

	~~Cryptography is mostly bad. And dangerous.~~
	* easy to implement
	* hard to implement well

	~~If you make a mistake, your crypto is worse than useless~~
	* security cannot be specified or completely defined
	* attacks exploit details that you didn't think about

	~~Timing attacks~~

	~~Game in encryption: encrypt and decrypt without disclosing the plaintext or the key~~

	~~For many encryption algorithms, execution time is a function of the plaintext and/or key~~

	~~Watch how long a computer takes to encrypt something, and you can figure out the key~~

	~~1970's, Data Encryption Standard (DES)~~
	~~- first developed by IBM~~
	~~- "fixed" by the NSA~~
	~~- halved the key (much easier to break)~~
	~~- fiddled with the constants in the algorithm~~

	~~Any security technology may improve and reduce your security at the same time~~

	~~security is confidentiality, availability, and integrity~~
	~~Example: encrypting a hard disk~~

	~~Why not use biometrics~~
	~~- fingerprints~~
	~~- facial recognition~~

	~~It is all about your threat model~~
	~~- any technology helps with certain risks and harms versus others~~
	~~- what do you care about?~~

	~~Tradeoffs are inherent to technology~~
	~~</pre>~~

Soma: Created page with "==Video== The video for the lecture given on November 25, 2015 [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec21-25Nov2015.mp4 is now available..."

2015-11-25T21:27:46Z

Created page with "==Video== The video for the lecture given on November 25, 2015 [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec21-25Nov2015.mp4 is now available..."

New page

==Video==

The video for the lecture given on November 25, 2015 [http://homeostasis.scs.carleton.ca/~soma/os-2015f/lectures/comp3000-2015f-lec21-25Nov2015.mp4 is now available].

==Notes==

<pre>
Lecture 21
----------

no last assignment

What is research?
* Asking questions and figuring out the answers
* Questions are much more important than answers
* Questions are much *harder* than answers

What question you ask determines what answer you'll get

The research literature
- many many publications
- hard to tell what is any good

Reseachers know who to trust in their area, and, how in general to determine trust
- do spot checks for obvious errors, based on what you do know
- do they give full details about what they did? could you reproduce it?
- surprising results require extraordinary evidence

If you're outside the field, look at
- publication reputation
- citation counts and quality

to learn more about operating systems research...
what are the well-respected venues?

Conferences, not journals

USENIX OSDI
ACM SOSP

When should you *really* look at the research literature?

You're trying to solve a hard problem and aren't sure what approach to take.
* look to see what other people have done in response to similar problems!

What about computer security?
* even more publications

But there's a truth to research...
- most of it isn't any good

Why?
- a lot of research doesn't work in practice
- a lot of conclusions are premature

Computer security research is mostly bad

Cryptography is mostly bad. And dangerous.
* easy to implement
* hard to implement well

If you make a mistake, your crypto is worse than useless
* security cannot be specified or completely defined
* attacks exploit details that you didn't think about

Timing attacks

Game in encryption: encrypt and decrypt without disclosing the plaintext or the key

For many encryption algorithms, execution time is a function of the plaintext and/or key

Watch how long a computer takes to encrypt something, and you can figure out the key

1970's, Data Encryption Standard (DES)
- first developed by IBM
- "fixed" by the NSA
- halved the key (much easier to break)
- fiddled with the constants in the algorithm

Any security technology may improve and reduce your security at the same time

security is confidentiality, availability, and integrity
Example: encrypting a hard disk

Why not use biometrics
- fingerprints
- facial recognition

It is all about your threat model
- any technology helps with certain risks and harms versus others
- what do you care about?

Tradeoffs are inherent to technology
</pre>