In this course, the students will obtain a thorough understanding of the challenges and issues related to the design and implementation of modern multi-core operating systems. The students will apply and extend their knowledge in systems, software engineering, project management, and team work. During the course, the students will work together in small groups to build a fairly complete operating system.

The course covers the design and implementation of various operating systems concepts such as, but not limited to:

1. memory management,
2. scheduling,
3. inter-process communication,
4. inter-core synchronization,
5. protection,
6. device drivers,
7. file systems, and
8. networking.

Moreover, the course pays particular attention to the design of system software architectures that differ from the traditional monolithic arrangements of Unix/Linux and Windows.

Credit: This course is based on 263-​3800-00L @ ETH Zurich taught by Prof. Timothy Roscoe. Reto Achermann has brought this course to UBC.

Goals

• Teach general operating systems principles, using a real research operating system to illustrate them and by reading the research papers which propose some of the ideas that the particular OS builds on.
• Give a broader perspective on operating systems which do not look like Linux, Unix, or Windows.
• Provide exposure to the practical experience of working on OS code on real “metal”, including debugging, hardware access, etc. This kind of experience is hard to gain merely from reading books or papers.
• Introduce a sense of the complexity of a real OS, rather than simplified teaching OSes often used in more basic courses.

Prerequisites

This course is about the design and implementation of operating systems, and thus requires strong background in computer systems, software engineering, and programming.

Courses Students should have taken an undergraduate systems and software engineering course course. Ideally, this means the following:

• CPSC 313 (or equivalent) with 85% or above.
• CPSC 310 (or equivalent) with 85% or above.
• CPSC 317 (or equivalent) with 85% or above.

(See the course catalogue for hard requirements)

Additional Requirements The following skills and knowledge are recommended for successfully completing the course.

• Proficiency in C programming is assumed
• Knowledge of computer architecture: caches, MMU, interrupts, devices
• Not afraid to read assembly code
• Navigate technical documentation and manuals
• Familiarity with OS concepts: concurrency, asynchrony, process management, memory management, virtual memory, networking, filesystem
• Linux development tools: shell, editors, make, gcc, gdb, …
• General interest in system software and low-level hacking

Class / Tutorial / Lab Hours

• Monday, 1pm–4pm, ICICS 005
• Tuesday, 9am–11am, MCLD-3014
• Thursday, 9am–11am, MCLD-3014

Office Hours (Optional)

• Wednesday, 2pm–3pm, ICICS 304)
• Friday, 1pm–2pm ICICS 306)

Term Schedule

Fill the group registration form before September 15th.

Schedule Notes

The lectures and labs are designed around the class project. They are designed to help the students to succeed in completing each milestone and progress through the construction of their operating system.

This may seem like a lot of hours, but unlike a lot of courses, this course focus on hand-on experience. You will spend a significant amount of those hours working as a team or discussing with the instruction team. The activities during the term are divided between the following categories:

Lecture (Presence is strongly encouraged)

During a lecture slot, we will cover the necessary background information, present an overview of the up-coming milestone, and provide hints and tips for the next project milestone. The students are expected to have at least looked at the next milestone. The students are encouraged to ask questions regarding the project during lectures.

Lab (Presence is encouraged)

This is a office-hours like lab session. Course staff will be present to answer project related questions. During this slot, the students are expected to meet with their team and work on the project.

Tutorial (Presence is encouraged):

This is similar to the Lab sessions; but we’ll have a short tutorial with some additional information that may be useful for the project. The remainder of the session will be available to work on the project and ask questions.

Milestones demonstrations (presence mandatory)

During this slot the students will present and explain their milestone solutions to the course staff.

Failure to show up without giving notice will result in a zero in the associated assignment.

Office Hours (presence optional)

During this slot you can ask questions about the course and/or your project.

Quizzes (presence mandatory)

Short knowledge test organized in the CBTF rooms.

Failure to show up without giving notice will result in a zero in the associated assignment.

Source code and other materials (the course book, manuals, specifications, etc. ) will be distributed through a git repository. The students will use the provided git repository to submit their code and reports. No other means of submission will be accepted. The use of other repositories on GitHub or other platforms is not allowed.

• Course Materials
• Code Handout
• Student Repositories

Your final grade will be a weighted average of the individual and group assessments.

Individual Grades (35%)

• 20% Quizzes. The grade for the quizzes during the term.

• 5% Milestone 0 Demonstration. These are the points awarded during the individual milestone presentation. The students are expected to demonstrate the required milestone functionality, and explain their design and implementation.

• 10% Self Reflections

  • 5% Early self-reflection. You will reflect on what you expect from the course, what you want to learn and how you want to grow.
  • 5% Final self-reflection. You will look back at what happened during the class, how things diverged from your expectations and more importantly why.

Group Grades (65%)

• 20% Milestone Demonstration. These are the points awarded during the group milestone presentations. The students are expected to demonstrate the required milestone functionality, and explain their design and implementation.

• 25% Integration Test. These are the results of the integration tests run on the final submission.

• 15% Reports

  • 5% Intermediate Group Report. This includes the quality and completeness of the intermediate group report.
  • 10% Final Group Report. This includes the quality and completeness of the final group report.

• 5% Class Presentation. How well the group did during their presentation(s).

Further Information

Milestone Completion

Extra Challenges

Milestones come with extra challenges that award the student extra points and additionally provides the basis for a good reference letter. The completion of the extra challenges is not required for obtaining a maximum grade. To receive the extra points, the extra challenge must be presented before the normal deadline. No points will be awarded for completed extra challenges on late submissions, or if the base or target tasks have not been met.

Late Submissions

Generally, submissions must be completed by the stated deadline. Late submissions will be graded at 75% (one week delay) and 50% (two weeks delay) of the base points respectively. To help the students prioritize the tasks, the course materials indicate the base functionality for each milestone. Due to the schedule and to ensure enough time for grading, there is no late hand-in for milestone M0 and the final submission.

Joker Cards

Life happens, and sometimes it’s good to get a little extra time.

• Each group will receive two joker cards that extend the deadline of group milestones – no question asked. The instructor will set the date for the postponed demonstration.
• There are no jokercards for the individual milestone at the beginning of the course.
• The final hand-in are a hard deadline and cannot be extended

Joker cards must be redeemed the day before the deadline as posted on the schedule.

This is not an algorithms course, or a coding interview. There won’t be any points awarded for correctly implementing a self-balancing tree, or a solution based on dynamic programming. The students are allowed to make reasonable use of third-party libraries. There are, however, a few rules and guidelines that need to be followed.

The use of Third-Party Code and Libraries

You may use third-party code in the project, or discuss with other students in the class. However, you must attribute and cite any third-party code that you use in your project. Moreover, you must implement a non-trivial fraction of the code on your own (or as a team). In any case, all members of the groups must be able to explain the design and implementation.

Generative AI

The course aims to keep up with a changing landscape andm generative AI (e.g., ChatGPT or copilot) is likely to become one of the many tools available to developers. As such the use of such tools is not prohibited.

Use these tools at your own risk. They are not a substitute for understanding the material, nor a guaranteed that you will obtain a good grade, especially when attempting to complete the milestones in the last minute. You might find yourself in spending a significant amount of time settings things up, and who knows, maybe you would have been faster actually coding it yourself.

Sharing or Publishing of Code

This is something you will actually sign when you register your group! The students agree not to publish or distribute their code in any form, including but not limited to public or private GitHub repositories, sending code to other students via e-mail, file transfers, or by any other means.

Here we summarize some advice that may be useful to successfully complete the project. Of course, not every student is the same, and you may find your own way to do well in this course.

Lectures

To get most out of the lectures, it is highly recommended reading the next chapter in the book before the class. This enables an engaged discussion during class and to help you ask relevant questions.

The lectures are also your chance to ask questions about the next milestone early on in the week. So it’s good to think about the upcoming tasks before the lecture.

Project

Think before you code. Think about the functionality that need to be implemented. Write down your architecture and keep design notes (this is helpful for your presentations and reports). This is especially important, especially when you work as a team.

Read ahead. Each milestone builds upon the functionality of the previous one. It is a good idea to read a bit ahead to get an overview of the entire project.

Read the milestone descriptions carefully. You are significantly more likely to succeed if you read the instructions, follow the suggested task order, and identify the hints you are given.

• Are there any hints and explanations? (your answer should be: yes, there is)
• What is the interface to be implemented?
• What are the required functionalities?

Write tests. This is one way to make sure your code works as intended. This is especially important, as later milestones build upon earlier ones. Also, those tests are a fantastic way to demonstrate your milestones. You might even decide to divide the work: some team members write the code, others design and write tests.

Git. Try to use version control wisely. Use meaningful and descriptive commit messages, and clean patches to help your teammates understand what you have done. Be strategic in how you use branches, we have seen students constructing diverging branches that soon became impossible to merge. A significant portion of the difficulty inherent to this course is about working effectively with others. There is a (git-)conflict management component in this course.

Milestone Presentations

Each milestone will be demonstrated to one of the course staff. This will take about 15-ish minutes. The students will need to show that they have implemented all required functionality, and be prepared to answer question about their implementation. Any member of a group should be able to explain what is going on.

Reports

Write the report as you go, or at least keep notes. You will need to submit 1-2 pages of notes on their design decisions, implementation details, performance evaluation, etc. with every group milestones.

Presentation

Make it entertaining and interesting, do a demo. Do a reflection: What has worked well, what have you learned. What turned out to be a bad decision? The class should be a supportive environment. You are going through the same (difficult?!) experience and it is a good opportunity to share! This class is not a zero-sum game, grades are unscaled, if everyone learns and finishes the class with an A+, it will be a resounding success.

Yanze Li

Title: eBPF, the eBPF “verifier”, and verifying the “verifier”

Abstract: eBPF is an emerging technique in the Linux kernel that allows you to safely extend your kernels with additional functionalities (e.g., processing network packets, profiling, tracing, etc.).

To ensure such safe extensions, the Linux kernel ships a verifier that checks the safety of eBPF programs before they are loaded into the kernel (and rejects them if the check fails). In reality, however, searching “BPF” on www.cve.org shows >300 CVEs and over 50 of them were found in 2025.

In this short talk, I will briefly introduce you to eBPF, and my current project on hardening the formal guarantees for eBPF and its verifier.

Philip Schowitz

Title: Response-time analysis of NVIDIA Holoscan

Abstract: Safety-critical applications, such as medical imaging workflows, should be verified to be as predictable as possible prior to deployment. Missed deadlines could lead to degraded image quality or delayed clinical decisions during an operation. One clear way to quantify safety is via a hard response-time bound (e.g., a video frame will take no longer than 50 ms to be processed by the app). In particular, our work concerns applications built using a specific framework, NVIDIA Holoscan. Response-time analysis of Holoscan apps is difficult due to the large number of variables affecting the runtime of any application: Holoscan’s internal task scheduling, GPU kernel scheduling, and the underlying OS thread scheduler. Our work addresses the challenge of distinguishing between the effects of these distinct scheduling layers and quantifying how the system’s design shapes its timing properties.

Ilias Karimalis

Title: TBD

Abstract: TBD

Changyuan Lin

Title: Demystifying Serverless Costs on Public Platforms: Bridging Billing, Architecture, and OS Scheduling

Abstract: Public cloud serverless platforms have attracted a large user base due to their high scalability, plug-and-play deployment model, and pay-per-use billing. However, compared to virtual machines and container hosting services, modern serverless offerings typically impose higher per-unit time and resource charges. Additionally, billing practices such as wall-clock time allocation-based billing, invocation fees, and usage rounding up can further increase costs. We holistically demystifies these costs by conducting an in-depth, top-down characterization and analysis from user-facing billing models, through request serving architectures, and down to operating system scheduling on major public serverless platforms. We quantify, for the first time, how current billing practices inflate billable resources up to 4.35x beyond actual consumption. Also, our analysis reveals previously unreported cost drivers, such as operational patterns of serving architectures that create overheads, details of resource allocation during keep-alive periods, and OS scheduling granularity effects that directly impact both performance and billing. By tracing the sources of costs from billing models down to OS scheduling, we uncover the rationale behind today’s expensive serverless billing model and practices and provide insights for designing performant and cost-effective serverless systems.

Kjell Dankert

Title: On the Scope and Gaps of Cache Side-Channel Research

Abstract: Cache side channel attacks have proven to be a significant threat to cryptographic libraries, prompting research that spans the development of new attacks and leakage mechanisms, the development of analysis tools, and the design of mitigation strategies across the hardware–software stack. Yet we still lack a clear understanding of the scope of vulnerable applications beyond cryptographic implementations, and how well analyses translate into practical attacks or effectively guide mitigations.

In this presentation, I briefly outline the main research directions and highlight the gaps that, in my view, deserve more attention. Additionally, I will present how our recent work on cache side channels in language runtimes broadens the perspective on which applications and execution environments may be susceptible to cache side-channel attacks.

Feedback from 2024 UBC students

I feel like I learned the most from this course. I am much more confident with the concepts from the prerequisite courses now. I am a better programmer than I was before taking this course. It is very rewarding to be able to work on an OS design with other students.

This course covers a large range of operating system functionality, and how we can implement it. It also explores alternative approaches to OS design which I found refreshing. This course definitely reinforced my understanding of lower–level functionalities in operating systems, and has improved my C coding and debugging skills.

Very practical course in many ways. I think it would help any student feel more prepared for the workplace where likely they have to work within a team and with a pre–existing large code base that may not be well–documented. Also very interesting material because we cover topics that are currently being researched in operating systems. Most other courses only cover how Linux works and give the impression that a lot of these OS design challenges are solved.

The smaller class size and it seemed like the TA’s and the instructor knew a lot and were passionate about the material being taught.

This is the best class I’ve ever taken. Like the beautiful lovechild of 310 and 313.

The project is brutal, hardcore, and anybody who passes will feel invincible when it comes to writing in C.

This course is beautiful and should not be dropped for any reason!

Feedback from 2023 UBC students

This course is extremely interesting, and allows us to actually apply concepts we’ve learned to something practical, which I believe will stick with me for much longer than the standard lecture/exam format of other courses. I also enjoy that we get exposed to leading edge research in systems, rather than learning about ancient systems that will have to be phased out in the future.

Practical application of previous courses. Learn how to approach design problems and evaluate the advantages and disadvantages of designs.

By far the most I’ve learned in any one class at UBC. Pushed me to my limits and made me learn a lot about myself.

Out of all my courses at UBC I think this is the one I learned the most in! The focus on design really made me think carefully about the consequences of operating system decisions in a much more effective way than a lecture–focused class would have. I also liked that this course includes grading not just for how well the code works, but also for having an insightful analysis in the report/presentation. While other courses have gone almost entirely to autograded code assessments where code quality is not a priority, this course emphasized the importance of readable and maintainable code as my group had to often look back at the previous milestone work that we did. I think that this course reflects much more of a difficult real–world experience where many things are unclear and certain decisions may not necessarily be the best for future milestones.

Very practical course which is different to almost all other cpsc courses. gives a different perspective to what is taught in 313/213

The content is amazing – no other course at UBC like this. Its a struggle, but satisfying when you manage to figure things out. The difficulty is a good thing, this class should not be made easier at all.

Amazingly practical and useful content. Lots of office hours and tutorials to ask questions. Approachable prof and teaching assistants.

It has been a great pleasure taking this course with the professor. The content was amazing and the hands–on components of this class has been a great help at learning how operating systems work in modern contexts. The professor is very approachable and has open to questions during office hours. I would definitely take this course again.

Feedback from 2022 UBC students

It’s a self learning style course. You learn a ton by jumping into the deep end. The beginning of the course is extremely painful but gets better as time goes on.

This is one of the most interesting courses that I have taken. It has a very unique approach that allows you to think through new solutions. I am very happy that this course was added and it’s a lot better than the old OS Course.

The project, its complexities, and challenges were a highlight. While many students struggled, and many of us complained, I think we’ve grown so much as engineers and computer scientists.

I really liked the approach of this course since it is very different from what we have experienced in other classes at UBC, it teaches us what it takes to do real design and implementation of a fairly large system without just being told what to do at every stage. As a 4th year course, it also required us to use our knowledge from other courses which I found to be a great strength, especially when many other CS courses seem very disjoint.

I did have completed 310 and 313 but I still feel that I am not well–prepared for this course. To be honest, the workload for this course is much larger than other courses I have taken.

Best CS course I’ve taken! With the vast majority of my courses, I come out feeling unsatisfied, like the assignments are trivial toy problems, that I didn’t accomplish or learn much, or that I could’ve read a textbook and picked it up on my own in a few weeks. But with 436A I feel like I learned a ridiculous amount in just a couple of months and it made me feel like doing a degree in CS was worth it, and that this was an experience I wouldn’t have gotten by messing around with computers in my free time. Overall, I was really happy with the class :)

It’s too much work, it’s about 3 course load worth of work. I spend at most 4 hours finishing assignments from CPSC 314 and CPSC 322 every other week. For this course, I’m spending 30+ hours per week (all tracked via wakatime extension).

This is definitely the most difficult course I’ve taken, the project is very time consuming and the concepts are difficult. The course is centered around a project which forces you to experiment and focus on design rather than just following a recipe. As a result, you are rewarded with a much deeper understanding of OS concepts that were introduced in CPSC 313.

The course was paced quite aggressively. For most milestones I found that it took me about half the allotted time for the content to simply sink in and to figure out what exactly I was supposed to do. By that point, there was very little time left so my code was often messier than I would have liked.

Weekly feedback and answered questions well without giving away answers so that we could work through the problems ourselves. Probed us with questions to guide us in the right direction. Also provided good lectures.

At Monad I got to learn and work with Rust. I built their RPC server, which CPSC 436A was really handy for ;-)

Past Grade Distribution