https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2026F_Lecture_11 2026-10-25T14:32:14Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2026F_Lecture_11&diff=25211&oldid=prev 2026-10-23T16:26:21Z

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

Soma