Operating Systems 2026F Lecture 11
Video
Video from the lectures given on October 22nd and 23rd, 2026 are now available:
Notes
Lecture 11A
Lecture 11B
-----------
What makes smartphone secure?
Is it the app stores?
- automated and (for Apple) manual review?
- developer vetting?
NOPE
The automated part is just anti-malware scanning, plus some policy checks
- and that's standard on Windows and even macOS
- and anti-malware scanners are always reactive
If you're trying to categorize all manner of badness, you're always reactive
- infinite ways to be bad!
Rather than making a deny list, better security comes from an allow list
- world of known good is inherently more limited
Turns out Apple and Google (historically) haven't vetted developers
- bar to entry VERY low
- different from game stores!
So app store policies are not sufficient to make mobile OSs more secure than desktop OSs
But apps on mobile OSs are sandboxed!
Remember that sandboxing is an aspiration, not a technical mechanism
- want code to be isolated from rest of system so it can't do harm
Sandboxing is normally dynamic, i.e., code is checked at runtime
- versus static analysis before running code
Most used sandboxes are language or runtime-based sandboxes
- the program execution environment itself limits program activity
- JavaScript/WebAssembly, Java (JVM), Flash
When a language requires a runtime, it means that its code isn't compiled directly into machine code
- instead, it is run as source code or as byte code
- but isn't this slower? generally yes (but not always)
- with interpretation, yes
- with just-in-time compilation, mostly yes
When you have a runtime, that runtime can implement restrictions on code behavior
- it can provide the sandbox
But language-based runtimes aren't enough on mobile OSs
- we want to run native apps (i.e., ones in machine code)
So we have to use the operating system.
Good news, modern OSs already do a lot of the work
- already have limits on memory and CPU
- virtual memory
- scheduling
- but the system call interface is, by default, too permissive
iOS and Android take different approaches to OS-level sandboxing
- but today they are basically equivalent
Android builds on the standard UNIX security model
- assign users to apps
- groups for resources
- intent permissions for Android APIs (implemented through binder)
- mediated by systemserver
- plus SELinux (mandatory access control)
iOS started with app isolation through OS-level virtualization
- every app thinks it has a separate environment
- users, groups, process IDs, filesystem
- so any sharing between apps then has to be built as exceptions to the isolation
Rest of term:
- scheduling
- virtual memory
- filesystems
Why not cheat?
- AI's do it all the time!
What is cheating?
- achieving a goal (or attempting to achieve a goal)
- using means that are not permitted for some reason
- peer pressure
- "morals"
- "ethics"
- against the "rules"
cheating is inherent to current AI systems
- because AI is just search
- and modern AI systems search over concepts
So what is cheating in this context?
- looking for solutions in the "wrong" part of the search space
Why don't we like cheating in AI systems?
- mostly because it undermines learning
Lecture 11B
Lecture 11B
-----------
What makes smartphone secure?
Is it the app stores?
- automated and (for Apple) manual review?
- developer vetting?
NOPE
The automated part is just anti-malware scanning, plus some policy checks
- and that's standard on Windows and even macOS
- and anti-malware scanners are always reactive
If you're trying to categorize all manner of badness, you're always reactive
- infinite ways to be bad!
Rather than making a deny list, better security comes from an allow list
- world of known good is inherently more limited
Turns out Apple and Google (historically) haven't vetted developers
- bar to entry VERY low
- different from game stores!
So app store policies are not sufficient to make mobile OSs more secure than desktop OSs
But apps on mobile OSs are sandboxed!
Remember that sandboxing is an aspiration, not a technical mechanism
- want code to be isolated from rest of system so it can't do harm
Sandboxing is normally dynamic, i.e., code is checked at runtime
- versus static analysis before running code
Most used sandboxes are language or runtime-based sandboxes
- the program execution environment itself limits program activity
- JavaScript/WebAssembly, Java (JVM), Flash
When a language requires a runtime, it means that its code isn't compiled directly into machine code
- instead, it is run as source code or as byte code
- but isn't this slower? generally yes (but not always)
- with interpretation, yes
- with just-in-time compilation, mostly yes
When you have a runtime, that runtime can implement restrictions on code behavior
- it can provide the sandbox
But language-based runtimes aren't enough on mobile OSs
- we want to run native apps (i.e., ones in machine code)
So we have to use the operating system.
Good news, modern OSs already do a lot of the work
- already have limits on memory and CPU
- virtual memory
- scheduling
- but the system call interface is, by default, too permissive
iOS and Android take different approaches to OS-level sandboxing
- but today they are basically equivalent
Android builds on the standard UNIX security model
- assign users to apps
- groups for resources
- intent permissions for Android APIs (implemented through binder)
- mediated by systemserver
- plus SELinux (mandatory access control)
iOS started with app isolation through OS-level virtualization
- every app thinks it has a separate environment
- users, groups, process IDs, filesystem
- so any sharing between apps then has to be built as exceptions to the isolation
Rest of term:
- scheduling
- virtual memory
- filesystems
Why not cheat?
- AI's do it all the time!
What is cheating?
- achieving a goal (or attempting to achieve a goal)
- using means that are not permitted for some reason
- peer pressure
- "morals"
- "ethics"
- against the "rules"
cheating is inherent to current AI systems
- because AI is just search
- and modern AI systems search over concepts
So what is cheating in this context?
- looking for solutions in the "wrong" part of the search space
Why don't we like cheating in AI systems?
- mostly because it undermines learning