Soma-notes - Recent changes [en]

Operating Systems 2026F: Tutorial 4

Soma — Sun, 04 Oct 2026 19:47:06 GMT

Setup

← Older revision		Revision as of 19:47, 4 October 2026
(2 intermediate revisions by the same user not shown)
Line 10:		Line 10:

	The kernel, however, does not treat all processes the same. The kernel allows some processes to do more than others depending upon the user and group of the process. We can see what access a process has by looking at the permissions associated with files.		The kernel, however, does not treat all processes the same. The kernel allows some processes to do more than others depending upon the user and group of the process. We can see what access a process has by looking at the permissions associated with files.

			Most users have limited access. One user, <tt>root</tt> (with user ID of 0), has as much access as is possible from a process. The kernel will even allow the root process to modify how the kernel operates. Processes running as root are still just processes, though, and any access that the kernel gives to such processes is at the discretion of the kernel. (In fact, there are setups which limit the privileges of the root user.)

	===File Permissions===		===File Permissions===
Line 19:		Line 21:
	* group permissions		* group permissions
	* other permissions		* other permissions
	Each of these have read, write, and/or execute permissions along with some other special permissions we'~~ll discuss later~~.		Each of these have read, write, and/or execute permissions along with some other special permissions.

			One special permission is the ''setuid'' bit. When an executable has this bit set, the process will run as the user who owns that executable (rather than as the user associated with the process that did the execve). The setuid bit is particularly important when a file is owned by root, as it gives us a way for regular users to escape the bounds of normal permissions. We will see the setuid root bit in action in this tutorial.

	The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.		The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.
Line 79:		Line 83:
	tar xzf tut4.tar.gz		tar xzf tut4.tar.gz
	cd tut4		cd tut4
			sudo apt install make # make isn't installed on the class VMs oops
	make		make
	make setuid		make setuid

Operating Systems 2026F: Tutorial 4

Soma — Sun, 04 Oct 2026 19:01:09 GMT

Created page with "'''This tutorial is not yet finalized.''' In this tutorial you will learn about permissions, accounts, how logging in works, and ssh. ==Background== In UNIX and UNIX-like systems like Linux, kernel code runs in supervisor mode (ring 0 on x86-64) and user code runs in user mode (ring 3 on x86-64). When the CPU is in supervisor mode, all system resources can be accessed; when the CPU is in user mode, only a limited set of resources can be used, namely those that have be..."

New page

'''This tutorial is not yet finalized.'''

In this tutorial you will learn about permissions, accounts, how logging in works, and ssh.

==Background==

In UNIX and UNIX-like systems like Linux, kernel code runs in supervisor mode (ring 0 on x86-64) and user code runs in user mode (ring 3 on x86-64). When the CPU is in supervisor mode, all system resources can be accessed; when the CPU is in user mode, only a limited set of resources can be used, namely those that have been allocated to the current process.

A process is an abstraction over the limited access of the CPU's user mode. All processes run in user mode. While kernel code can be doing work on behalf of a specific process, properly speaking no kernel code is in a process. Instead, the kernel implements the process abstraction.

The kernel, however, does not treat all processes the same. The kernel allows some processes to do more than others depending upon the user and group of the process. We can see what access a process has by looking at the permissions associated with files.

===File Permissions===

A process' permission to access files in UNIX is determined by the user and group associated with that process. When a person logs in, their initial process is given the user and group associated with their account. All child processes of that initial login process inherit the same user and group.

A user can belong to multiple groups but a process only belongs to one group at a time. (There are ways to change the group associated with a process.) A file is always owned by someone and is always associated with a group. All files on the UNIX file system (including directories and other special files) have three different sets of permissions:
* owner permissions
* group permissions
* other permissions
Each of these have read, write, and/or execute permissions along with some other special permissions we'll discuss later.

The <tt>ls</tt> command with the <tt>-l</tt> option can be used to show both the permissions of a file as well as the owner and group associated with the file. Permissions are listed first, followed by the owner and the group.

===Logging in to a UNIX system===

In order to log in to a UNIX system (Linux or otherwise), the following steps must occur (potentially not in this order).

# The user must authenticate themselves, proving their identity and that they are allowed to access the system. By default this is done through a username and password.
# A new process, U, should be created for the authenticated user.
# The login program must establish communication with the user via some communications channel. Normally this channel will be a device. Standard in, out, and error for U should be connected to this device.
# U changes uid and gid to that of the new user.
# U sets up other aspects of the user's context (mainly setting key environment variables).
# U does an execve of the user's chosen shell.

[[#Code|3000userlogin]] is a basic implementation of steps 4-6. (Steps 2 and 3 are accomplished by running 3000userlogin in a shell, as running an external command means the shell first creates a new process, as we have seen. We are skipping 1.)

===SSH===

Secure Shell, or ssh, is the standard method for accessing UNIX and UNIX-like systems remotely. It is a more secure replacement for older technologies such as [https://en.wikipedia.org/wiki/Berkeley_r-commands rsh] and [https://en.wikipedia.org/wiki/Telnet telnet].

The standard implementation of ssh is [http://www.openssh.org openssh], a version of ssh that was originally created for [https://www.openbsd.org/ OpenBSD] but has been ported to other systems. OpenBSD has a reputation for being the most secure UNIX-like system around. It tends to be a bit harder to configure, have less support for current hardware, and have lower overall performance than Linux-based systems; however, it can be very competitive for some workloads.

While ssh support password-based authentication, it is meant to be used with more secure forms of authentication. For example, ssh supports public key authentication, a type of authentication that makes use of [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography]. Instead of a shared key (such as a password) that is known to both parties, with public key cryptography, keys come in two parts: a public part and a private part. The public part should be widely distributed, while the private part needs to be carefully secured.

Public key cryptography can be used to send secret messages to anyone you can get the public key for. With digital signatures, public key cryptography can also be used to verify the authenticity and integrity of messages, so long as we know the public key of the originating party.

With public key authentication, we use a key pair to authenticate rather than sending a password.

A cool feature of public key authentication is it is possible to automatically log into a system once the appropriate private key is made available, thus giving us the convenience of passwordless logins with better security than passwords.

==Setup==

===3000userlogin===

When 3000userlogin is properly compiled and set up, you can run

./3000userlogin someuser

and you'll be logged in as "someuser", assuming someuser exists.

You can add a user with the adduser command. For example, to create the user "someuser":

sudo adduser someuser

Note you'll have to answer several questions.

If you just compile 3000userlogin normally, you won't be able to log in as anyone except the current user. To compile and set up 3000userlogin, do the following:

gcc -O -Wall 3000userlogin.c -o 3000userlogin
sudo chown root:root 3000userlogin
sudo chmod u+s 3000userlogin

The chown command makes the binary owned by root, and the chmod command makes it setuid. Thus, when the program is execve'd it will have an effective user ID of root (euid=0).

Alternately, you can download the code and use the associated makefile to build by doing the following:

wget https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/tut4.tar.gz
tar xzf tut4.tar.gz
cd tut4
make
make setuid

===SSH===

Install the openssh-server package (note on openstack it will already be installed, but on a default Ubuntu desktop install it won't be):

sudo apt-get install openssh-server

Create a second user in the virtual machine named "other" (or any other name you wish to use):

sudo adduser other

(Answer the subsequent prompts however you wish, just remember the password.)

At this point you should be able to log in to the "other" account using ssh:

ssh other@localhost

You'll have to enter your password.

If you don't get a password prompt, password authentication has probably been disabled. (Password authentication has been disabled on the openstack VMs.) To enable it, do the following

sudo nano /etc/ssh/sshd_config (or vi, or emacs)

In the editor change the line "PasswordAuthentication no" to "PasswordAuthentication yes". Then, to restart sshd:

sudo service sshd restart

Be sure to change it back after you've set up public key authentication!

===Public key authentication===

Create a public key file for your account (as user student, ubuntu, or your personal account):

ssh-keygen

(Accept the default filename and choose at least a simple passphrase.)

You just created a certificate! (A certificate is just a public key with metadata.)

Copy the key to the other account:

cat ~/.ssh/id_rsa.pub >> authorized_keys
scp authorized_keys other@localhost:.
rm authorized_keys
ssh other@localhost

(as user other)
mkdir ~/.ssh (if it doesn't exist already)
chmod 700 ~/.ssh (make it private)
mv ~/authorized_keys ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Now you can log in to user other by typing in the passphrase you used to lock the key you generated.

To avoid entering this passphrase every time, you can give it to the authentication agent (generally, ssh-agent) that was started when you logged in:

ssh-add

==Tasks==

# Compile and setup 3000userlogin as described above. Create a new user account. Verify that you can use 3000userlogin to login as the new user without typing the password of the new user.
# What is returned as the user's password by getpwnam()? Is this what you expected?
# Compare the uid, gid, euid, egid when running 3000userlogin as a regular user, running it setuid root, and running it as root (i.e., running it from a root shell without the setuid bit set). Also check to see what happens when you set the setgid bit (with different group IDs on the file).
# Why does 3000userlogin change its gid before changing its uid? What happens if you switch the order of these operations?
# Make 3000userlogin use the shell that is specified in the user's password entry. Check by making a new user and setting its shell to a new shell and then see if that new shell runs when you run 3000userlogin. You should change a user's shell with the chsh command, run as that user.
# Can you set 3000shell to be a user's default shell? What changes do you have to make for chsh to accept 3000shell? Does anything obvious break when running 3000shell this way, and how can you change 3000userlogin to fix it?
# Does a user's default shell have to be a regular shell? Could it instead be an arbitrary program? How do you know?
# How important is each of the environment variables that is set by 3000userlogin? Are these the only environment variables that are set after you successfully login?
# Note that 3000userlogin uses environ not envp (as an argument to main) to access environment variables. Why not use envp? (Try changing the code to use envp and see what happens.)
# Setup password-less login to your local system between the student and other account (or any two other accounts), following the above instructions. Note that the "local" account is the one you are running the ssh command on.
# Setup password-less login to access.scs.carleton.ca, following the instructions above.
# Secure shell can be used to directly run a command on another program rather than the default shell. For example, try "ssh student@localhost bc -l" and see that bc is run. When you do this, does ssh directly run the specified command or does it first run a shell and have the shell run the command? Use opensnoop.bt or execsnoop.bt to verify.
# What files in /etc does bash access when you login via 3000userlogin? How does this compare to what bash opens when you log in via ssh?
# '''(Optional):''' Prompt for the user's password before logging the user in. To do this, you'll need to get the right password hash and then figure out how to hash the entered password to check if it matches. See online guides about [https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils how passwords are stored on Linux] for help.

==Code==

[https://homeostasis.scs.carleton.ca/~soma/os-2021f/code/3000userlogin.tar.gz Download code for this tutorial (3000userlogin.c and Makefile)]

===3000userlogin.c===

[https://homeostasis.scs.carleton.ca/~soma/os-2020w/code/3000userlogin.c Download 3000userlogin.c]

<syntaxhighlight lang="c" line>
/* 3000userlogin.c */
/* version 0.1 */

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <pwd.h>

int main(int argc, char *argv[])
{
int result;
char *shell_argv[3];
char *username;
extern char **environ;
struct passwd *pw_entry;

if (argc < 2) {
fprintf(stderr, "Usage: %s <username>\n", argv[0]);
exit(-1);
}

printf("uid=%d, euid=%d, gid=%d, egid=%d\n",
getuid(), geteuid(), getgid(), getegid());

username = argv[1];

pw_entry = getpwnam(username);
if (pw_entry == NULL) {
fprintf(stderr, "Could not find user %s.\n", username);
exit(-2);
}

result = setgid(pw_entry->pw_gid);
if (result != 0) {
fprintf(stderr, "Failed to change to gid %d\n",
pw_entry->pw_gid);
exit(-3);
}

result = setuid(pw_entry->pw_uid);
if (result != 0) {
fprintf(stderr, "Failed to change to uid %d\n",
pw_entry->pw_uid);
exit(-4);
}

result = chdir(pw_entry->pw_dir);
if (result != 0) {
fprintf(stderr, "Failed to change to home dir %s\n",
pw_entry->pw_dir);
exit(-5);
}

shell_argv[0] = "bash";
shell_argv[1] = "--login";
shell_argv[2] = NULL;

clearenv();
setenv("USERNAME", pw_entry->pw_name, 1);
setenv("PATH", "/usr/bin:/bin", 1);
setenv("SHELL", "/bin/bash", 1);
setenv("HOME", pw_entry->pw_dir, 1);
setenv("COMP3000", "yes", 1);

execve("/bin/bash", shell_argv, environ);

fprintf(stderr, "Failed to exec bash\n");
return -6;
}
</syntaxhighlight>

===Makefile===

<syntaxhighlight lang="make" line>
.PHONY: setuid

3000userlogin: 3000userlogin.c
gcc -Wall -O 3000userlogin.c -o 3000userlogin

setuid: 3000userlogin
@echo "The following changes ownership to root, group to root, and sets the setuid bit on 3000userlogin:"
sudo chown root:root 3000userlogin && sudo chmod u+s 3000userlogin
@echo "3000userlogin is now setuid root!"
</syntaxhighlight>

Operating Systems 2026F Lecture 6

Soma — Fri, 02 Oct 2026 14:02:07 GMT

Created page with "==Video== Video from the lecture given on October 2, 2026 is now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec06-20261002.mp4 Lecture 6] ==Notes== ===Lecture 6=== <pre> Lecture 6 --------- Signals What is a signal? - message from the kernel to a process - can originate from the kernel or from another process Idea: interrupt the process to handle an event - so a simple form of event handling, or more exception handl..."

New page

==Video==

Video from the lecture given on October 2, 2026 is now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec06-20261002.mp4 Lecture 6]

==Notes==

===Lecture 6===

<pre>
Lecture 6
---------

Signals

What is a signal?
- message from the kernel to a process
- can originate from the kernel or from another process

Idea: interrupt the process to handle an event
- so a simple form of event handling, or more exception handling

When a process receives a signal
- it stops executing the current code (function)
- it instead starts running the appropriate signal handler
- when handling is complete, it then returns to where it was, continuing the function

This means signals can interrupt almost ANY part of your program
- need to be prepared!

What sort of signals are there?
- user defined (SIGUSR1, SIGUSR2)
- memory access errors (SIGSEGV, SIGBUS)
- some floating point errors

But mainly:
- when child processes terminate (SIGCHLD)
- when the user wants to terminate the process (SIGTERM)
or suspend (SIGSTOP)

And many other conditions

Signal handlers are defined by default by the C library

you can change signals with sigaction()
(don't use signal)

So what bad things can happen to your program because of a signal handler?
- could interrupt critical code
- can even happen while doing a system call
- handler could mess up state of your code

When a process receives a signal while in a system call, we have two choices:
- continue the system call after the signal is handled
- that doesn't work because of how the kernel operates
- but we can do the system call from the beginning (restart it)
- cancel the system call after the signal is handled

Standard I/O file descriptors
- when you type "ls", its output goes to the terminal
- but all ls was doing was writing to standard out
- how did standard out end up in the terminal?

C standard in = file descriptor 0 in Linux/UNIX
C standard out = file descriptor 1 in Linux/UNIX
C standard error = file descriptor 2 in Linux/UNIX

What is a file descriptor?
- small number
- refers to an open file

A file descriptor is what UNIX uses instead of the FILE struct for C.

But what is that small number, really?
- index into an array of open files the kernel maintains
for the currently running process

When a program starts, 0, 1, and 2 file descriptors are expected to be open and ready to go, with 0 ready for reads and 1 and 2 ready for writes.

Who gets these file descriptors set up? Whomever did the execve!
- they could inherit them from who execve'd them, but they are responsible

When you're using a shell, the shell is responsible for setting up the standard I/O file descriptors.

This is good, because it lets us do I/O redirection

So what does ">" do in most shells?
- redirects standard output to the given file

Remember that "files" in UNIX can be stored on disk, but they can be many other things as well
- tty's/pseudo tty's
- another process (IPC, inter-process communication)
</pre>

Operating Systems 2026F: Assignment 1

Soma — Wed, 30 Sep 2026 23:34:26 GMT

← Older revision		Revision as of 23:34, 30 September 2026
(One intermediate revision by the same user not shown)
Line 1:		Line 1:
	~~'''This assignment is not yet finalized.'''~~

	Please submit the answers to the following questions via Brightspace by October 5, 2026. There are 20 points in eight questions.		Please submit the answers to the following questions via Brightspace by October 5, 2026. There are 20 points in eight questions.

	Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-~~assign1~~-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.		Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-a1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

	Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.		Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.

Operating Systems 2026F: Tutorial 3

Soma — Sat, 26 Sep 2026 23:43:18 GMT

Created page with "In this tutorial you will be experimenting with and extending [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c] (listed below). '''Make sure you use the original code from 3000shell for each question.''' ==Getting Started== You should download [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c] on your openstack instance (or a Ubuntu Linux 21.04 system or similar). Compile it using the command gcc -O -g -..."

New page

In this tutorial you will be experimenting with and extending [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c] (listed below).

'''Make sure you use the original code from 3000shell for each question.'''

==Getting Started==

You should download [https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c] on your openstack instance (or a Ubuntu Linux 21.04 system or similar). Compile it using the command
gcc -O -g -Wall 3000shell.c -o 3000shell

==Standard I/O==

Recall that the shell is a command interpreter (program). In comparison, a terminal is a device used to enter data into and display data from a computer. It used to be physical - [https://en.wikipedia.org/wiki/Teleprinter teletypes, or "TTY"'s]. Today they are virtual - pseudoterminals, pseudo teletypes, or pts's. /dev/pts/1 is a pts for example. By themselves, a pts does nothing; however, they allow any program to appear as a virtual teletype to any other program. (To learn more, <tt>man ptmx</tt>. However, this goes into more detail than you need for this tutorial.)

When you ssh to a system interactively, the remote ssh process uses a pseudo tty to connect network I/O with the programs you run at the command line. In this context you can thus think of ssh (plus a pseudo tty) as an adaptor that converts network traffic into terminal-like I/O.

Standard input, (e.g., /dev/stdin), output (e.g., /dev/stdout) and error (/dev/stderr) are just
references to file descriptors 0, 1, and 2 for the current process. They can refer to basically any file. If a process is run in a terminal, stdin, stdout, and stderr are set to refer to the terminal's I/O channels via a tty or pts.

Shells provide easy interfaces for changing these file descriptors. For example:

ls > ls.log

Will redirect ls's standard output to the file ls.log. Similarly,

bc -l < math.txt

will take math input from /tmp/math.txt and output it to the current terminal. We can also use the pipe operator to direct the standard output of one program to the standard input of another:

ls -l | less

(This is really good if you have lots of files in a directory.)

Part of the magic of UNIX is that it allows problems to be solved by combining multiple programs together. For example, to get a list of unique words in a file, you can do something like the following:

tr ' \t' '\n' < file.txt | tr -d ',.!()?-' | sort | uniq | less

In summary, shells run in terminals, and the terminal interface is implemented by teletype-like devices, either a "tty" or "pts" device. Standard in, out, and error are abstractions for interactions with such terminals or, with I/O redirection, other arbitrary files.

==Tasks/Questions==

The purpose of the following questions and tasks is to help you understand how 3000shell works. At the end of this you should have an understanding of every function and every line of the code. If you understand 3000shell, then you understand the basics of all UNIX shells. Your understanding of the code will be tested later, so use this opportunity to dive deep into the code. These tasks and questions should help you build up a mental model of how 3000shell works.

# Compile and run 3000shell.c
# Try running programs in the background using & after commands entered in 3000shell. What happens to the input and output of the program? Try this for simple programs like ls and bc. Then, try it for more complex interactive programs such as nano and top.
# You may have trouble interacting with the shell after running programs in the background. How can you recover from such a situation?
# Run 3000shell under gdb and observe all the system calls it makes using <tt>catch syscall</tt> (after setting a breakpoint on main so you don't see the syscalls when it starts). Where does each system call happen? In what context (source and assembly)? Consider both parent and child processes (by setting follow-fork-mode to parent and child). Compare with the output of <tt>strace</tt> (e.g., run <tt>strace -fqo 3000shell.log ./3000shell</tt>). For info on gdb, see the [[GDB quick start]].
# 3000shell implements a simple form of output redirection. What syntax should you use to redirect standard output to a file?
# Why are lines 207-210 there (the check for pid == -1)?
# Make find_binary show every attempt to find a binary.
# Make the shell output "Ouch!" when you send it a SIGUSR1 signal.
# Delete line 324 (SA_RESTART). How does the behavior of 3000shell change?
# Replace the use of find_env() with getenv(). How do their interfaces differ?
# Make plist output the parent process id for each process, e.g. "5123 ls (5122)". Pay attention to the stat and status files in the per-process directories in /proc.
# Implement redirection of standard error
# Implement redirection of standard out for plist() (the same as if it was an external command).
# Implement a built-in 3000kill command that works like the standard kill command. (What system call/library call is used to send signals?)

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2019f/code/3000shell.c 3000shell.c]===

<syntaxhighlight lang="c" line>
/* 3000shell.c */
/* v2 Sept. 15, 2019 */
/* v1 Sept. 24, 2017 */
/* based off of csimpleshell.c, Enrico Franchi © 2005
https://web.archive.org/web/20170223203852/
http://rik0.altervista.org/snippets/csimpleshell.html */
/* Original under "BSD" license */
/* This version is under GPLv3, copyright 2017, 2019 Anil Somayaji */
/* You really shouldn't be incorporating parts of this in any other code,
it is meant for teaching, not production */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <dirent.h>
#include <ctype.h>
#include <fcntl.h>
#include <signal.h>

#define BUFFER_SIZE 1<<16
#define ARR_SIZE 1<<16
#define COMM_SIZE 32

const char *proc_prefix = "/proc";

void parse_args(char *buffer, char** args,
size_t args_size, size_t *nargs)
{
char *buf_args[args_size]; /* You need C99 */
char **cp, *wbuf;
size_t i, j;

wbuf=buffer;
buf_args[0]=buffer;
args[0] =buffer;

for(cp=buf_args; (*cp=strsep(&wbuf, " \n\t")) != NULL ;){
if ((*cp != NULL) && (++cp >= &buf_args[args_size]))
break;
}

for (j=i=0; buf_args[i]!=NULL; i++){
if (strlen(buf_args[i]) > 0)
args[j++]=buf_args[i];
}

*nargs=j;
args[j]=NULL;
}

/* this is kind of like getenv() */
char *find_env(char *envvar, char *notfound, char *envp[])
{
const int MAXPATTERN = 128;
int i, p;
char c;
char pattern[MAXPATTERN];
char *value = NULL;

p = 0;
while ((c = envvar[p])) {
pattern[p] = c;
p++;
if (p == (MAXPATTERN - 2)) {
break;
}
}
pattern[p] = '=';
p++;
pattern[p] = '\0';

i = 0;
while (envp[i] != NULL) {
if (strncmp(pattern, envp[i], p) == 0) {
value = envp[i] + p;
}
i++;
}

if (value == NULL) {
return notfound;
} else {
return value;
}
}

void find_binary(char *name, char *path, char *fn, int fn_size) {
char *n, *p;
int r, stat_return;

struct stat file_status;

if (name[0] == '.' || name[0] == '/') {
strncpy(fn, name, fn_size);
return;
}

p = path;
while (*p != '\0') {
r = 0;
while (*p != '\0' && *p != ':' && r < fn_size - 1) {
fn[r] = *p;
r++;
p++;
}

fn[r] = '/';
r++;

n = name;
while (*n != '\0' && r < fn_size) {
fn[r] = *n;
n++;
r++;
}
fn[r] = '\0';

stat_return = stat(fn, &file_status);

if (stat_return == 0) {
return;
}

if (*p != '\0') {
p++;
}
}
}

void setup_comm_fn(char *pidstr, char *comm_fn)
{
char *c;

strcpy(comm_fn, proc_prefix);
c = comm_fn + strlen(comm_fn);
*c = '/';
c++;
strcpy(c, pidstr);
c = c + strlen(pidstr);
strcpy(c, "/comm");
}

void plist()
{
DIR *proc;
struct dirent *e;
int result;
char comm[COMM_SIZE]; /* seems to just need 16 */
char comm_fn[512];
int fd, i, n;

proc = opendir(proc_prefix);

if (proc == NULL) {
fprintf(stderr, "ERROR: Couldn't open /proc.\n");
}

for (e = readdir(proc); e != NULL; e = readdir(proc)) {
if (isdigit(e->d_name[0])) {
setup_comm_fn(e->d_name, comm_fn);
fd = open(comm_fn, O_RDONLY);
if (fd > -1) {
n = read(fd, comm, COMM_SIZE);
close(fd);
for (i=0; i < n; i++) {
if (comm[i] == '\n') {
comm[i] = '\0';
break;
}
}
printf("%s: %s\n", e->d_name, comm);
} else {
printf("%s\n", e->d_name);
}
}
}

result = closedir(proc);
if (result) {
fprintf(stderr, "ERROR: Couldn't close /proc.\n");
}
}

void signal_handler(int the_signal)
{
int pid, status;

if (the_signal == SIGHUP) {
fprintf(stderr, "Received SIGHUP.\n");
return;
}

if (the_signal != SIGCHLD) {
fprintf(stderr, "Child handler called for signal %d?!\n",
the_signal);
return;
}

pid = wait(&status);

if (pid == -1) {
/* nothing to wait for */
return;
}

if (WIFEXITED(status)) {
fprintf(stderr, "\nProcess %d exited with status %d.\n",
pid, WEXITSTATUS(status));
} else {
fprintf(stderr, "\nProcess %d aborted.\n", pid);
}
}

void run_program(char *args[], int background, char *stdout_fn,
char *path, char *envp[])
{
pid_t pid;
int fd, *ret_status = NULL;
char bin_fn[BUFFER_SIZE];

pid = fork();
if (pid) {
if (background) {
fprintf(stderr,
"Process %d running in the background.\n",
pid);
} else {
pid = wait(ret_status);
}
} else {
find_binary(args[0], path, bin_fn, BUFFER_SIZE);

if (stdout_fn != NULL) {
fd = creat(stdout_fn, 0666);
dup2(fd, 1);
close(fd);
}

if (execve(bin_fn, args, envp)) {
puts(strerror(errno));
exit(127);
}
}
}

void prompt_loop(char *username, char *path, char *envp[])
{
char buffer[BUFFER_SIZE];
char *args[ARR_SIZE];

int background;
size_t nargs;
char *s;
int i, j;
char *stdout_fn;

while(1){
printf("%s $ ", username);
s = fgets(buffer, BUFFER_SIZE, stdin);

if (s == NULL) {
/* we reached EOF */
printf("\n");
exit(0);
}

parse_args(buffer, args, ARR_SIZE, &nargs);

if (nargs==0) continue;

if (!strcmp(args[0], "exit")) {
exit(0);
}

if (!strcmp(args[0], "plist")) {
plist();
continue;
}

background = 0;
if (strcmp(args[nargs-1], "&") == 0) {
background = 1;
nargs--;
args[nargs] = NULL;
}

stdout_fn = NULL;
for (i = 1; i < nargs; i++) {
if (args[i][0] == '>') {
stdout_fn = args[i];
stdout_fn++;
printf("Set stdout to %s\n", stdout_fn);
for (j = i; j < nargs - 1; j++) {
args[j] = args[j+1];
}
nargs--;
args[nargs] = NULL;
break;
}
}

run_program(args, background, stdout_fn, path, envp);
}
}

int main(int argc, char *argv[], char *envp[])
{
struct sigaction signal_handler_struct;

char *username;
char *default_username = "UNKNOWN";

char *path;
char *default_path = "/usr/bin:/bin";

memset (&signal_handler_struct, 0, sizeof(signal_handler_struct));
signal_handler_struct.sa_handler = signal_handler;
signal_handler_struct.sa_flags = SA_RESTART;

if (sigaction(SIGCHLD, &signal_handler_struct, NULL)) {
fprintf(stderr, "Couldn't register SIGCHLD handler.\n");
}

if (sigaction(SIGHUP, &signal_handler_struct, NULL)) {
fprintf(stderr, "Couldn't register SIGHUP handler.\n");
}

username = find_env("USER", default_username, envp);
path = find_env("PATH", default_path, envp);

prompt_loop(username, path, envp);

return 0;
}
</syntaxhighlight>

Operating Systems (Fall 2026)

Soma — Sat, 26 Sep 2026 16:50:26 GMT

Tutorials

← Older revision		Revision as of 16:50, 26 September 2026
(2 intermediate revisions by the same user not shown)
Line 130:		Line 130:
	</td>		</td>
	<td>		<td>
	<p>Midterm (in class)		<p>'''Midterm Exam (in class)'''
	</p>		</p>
	</td>		</td>
Line 322:		Line 322:
	<tr>		<tr>
	<td>		<td>
	<p>~~Oct~~. 19		<p>Nov. 2
	</p>		</p>
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F: Tutorial 5\|Tutorial 5]]		<p>[[Operating Systems 2026F: Tutorial 5\|Tutorial 5]]
	~~</p>~~
	~~</td>~~
	~~</tr>~~
	~~<tr>~~
	~~<td>~~
	~~<p>Nov. 2~~
	~~</p>~~
	~~</td>~~
	~~<td>~~
	~~<p>[[Operating Systems 2026F: Tutorial 6\|Tutorial 6]]~~
	</p>		</p>
	</td>		</td>
Line 346:		Line 336:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F: Tutorial 7\|Tutorial 7]]		<p>[[Operating Systems 2026F: Tutorial 6\|Tutorial 6]]
	</p>		</p>
	</td>		</td>
Line 357:		Line 347:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F: Tutorial 8\|Tutorial 8]]		<p>[[Operating Systems 2026F: Tutorial 7\|Tutorial 7]]
	</p>		</p>
	</td>		</td>
Line 367:		Line 357:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F: Tutorial 9\|Tutorial 9]]		<p>[[Operating Systems 2026F: Tutorial 8\|Tutorial 8]]
	</p>		</p>
	</td>		</td>
Line 396:		Line 386:
	<tr>		<tr>
	<td>		<td>
	<p>Oct. 13, 14:30		<p>Oct. 15, 14:30
	</p>		</p>
	</td>		</td>

Operating Systems (Fall 2026) Course Outline

Soma — Sat, 26 Sep 2026 16:47:35 GMT

Grading

← Older revision		Revision as of 16:47, 26 September 2026
(One intermediate revision by the same user not shown)
Line 65:		Line 65:
	* 20% for tutorial participation.		* 20% for tutorial participation.
	* 20% for the assignments, if exam average is not too low (see below).		* 20% for the assignments, if exam average is not too low (see below).
	* 20% for the Midterm Exam, Oct. 15th & 16th during class.		* 20% for the Midterm Exam, <del>Oct. 15th & 16th</del> Oct. 20th & 21st during class.
	* 35% for the Final Exam (during the final exam period).		* 35% for the Final Exam (during the final exam period).

Operating Systems (Fall 2026)

Soma — Sat, 26 Sep 2026 16:34:18 GMT

Lectures & Exams

← Older revision		Revision as of 16:34, 26 September 2026
(One intermediate revision by the same user not shown)
Line 70:		Line 70:
	</td>		</td>
	<td>		<td>
	<p>[~~[Operating Systems 2026F Lecture 6\|Lecture 6]~~] ~~(NSPW~~)<br>(Last day to withdraw with fee adjustment: Sep. 30)		<p>'''No class ([https://www.nspw.org NSPW])'''<br>(Last day to withdraw with fee adjustment: Sep. 30)
	</p>		</p>
	</td>		</td>
Line 76:		Line 76:
	<tr>		<tr>
	<td>		<td>
	<p>Oct. 1, 2		<p>Oct. 2
	</p>		</p>
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 7\|Lecture 7]] (NSPW)		<p>[[Operating Systems 2026F Lecture 6\|Lecture 6]]<br>'''No class on Oct 1 ([https://www.nspw.org NSPW])'''</br>
	</p>		</p>
	</td>		</td>
Line 90:		Line 90:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 8\|Lecture 8]]		<p>[[Operating Systems 2026F Lecture 7\|Lecture 7]]
	</p>		</p>
	</td>		</td>
Line 100:		Line 100:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 9\|Lecture 9]]		<p>[[Operating Systems 2026F Lecture 8\|Lecture 8]]
	</p>		</p>
	</td>		</td>
Line 110:		Line 110:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 10\|Lecture 10]]~~: Midterm Review~~		<p>[[Operating Systems 2026F Lecture 9\|Lecture 9]]
	</p>		</p>
	</td>		</td>
Line 120:		Line 120:
	</td>		</td>
	<td>		<td>
	<p>Midterm ~~(in class)~~		<p>[[Operating Systems 2026F Lecture 10\|Midterm Review]]
	</p>		</p>
	</td>		</td>
Line 130:		Line 130:
	</td>		</td>
	<td>		<td>
	<p>~~[[Operating Systems 2026F Lecture 11\|Lecture 11]]~~		<p>Midterm (in class)
	</p>		</p>
	</td>		</td>
Line 140:		Line 140:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 12\|Lecture 12]]		<p>[[Operating Systems 2026F Lecture 11\|Lecture 11]]
	</p>		</p>
	</td>		</td>
Line 150:		Line 150:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 13\|Lecture 13]]		<p>[[Operating Systems 2026F Lecture 12\|Lecture 12]]
	</p>		</p>
	</td>		</td>
Line 160:		Line 160:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 14\|Lecture 14]]		<p>[[Operating Systems 2026F Lecture 13\|Lecture 13]]
	</p>		</p>
	</td>		</td>
Line 170:		Line 170:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 15\|Lecture 15]]		<p>[[Operating Systems 2026F Lecture 14\|Lecture 14]]
	</p>		</p>
	</td>		</td>
Line 180:		Line 180:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 16\|Lecture 16]]<br>		<p>[[Operating Systems 2026F Lecture 15\|Lecture 15]]<br>
	(Last day to withdraw Nov. 13)		(Last day to withdraw Nov. 13)
	</p>		</p>
Line 191:		Line 191:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 17\|Lecture 17]]		<p>[[Operating Systems 2026F Lecture 16\|Lecture 16]]
	</p>		</p>
	</td>		</td>
Line 201:		Line 201:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 18\|Lecture 18]]		<p>[[Operating Systems 2026F Lecture 17\|Lecture 17]]
	</p>		</p>
	</td>		</td>
Line 211:		Line 211:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 19\|Lecture 19]]		<p>[[Operating Systems 2026F Lecture 18\|Lecture 18]]
	</p>		</p>
	</td>		</td>
Line 221:		Line 221:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 20\|Lecture 20]]		<p>[[Operating Systems 2026F Lecture 19\|Lecture 19]]
	</p>		</p>
	</td>		</td>
Line 231:		Line 231:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 21\|Lecture 21]]		<p>[[Operating Systems 2026F Lecture 20\|Lecture 20]]
	</p>		</p>
	</td>		</td>
Line 241:		Line 241:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 22\|Lecture 22]]		<p>[[Operating Systems 2026F Lecture 21\|Lecture 21]]
	</p>		</p>
	</td>		</td>
Line 251:		Line 251:
	</td>		</td>
	<td>		<td>
	<p>[[Operating Systems 2026F Lecture 23\|Lecture 23]]		<p>[[Operating Systems 2026F Lecture 22\|Lecture 22]]
	</p>		</p>
	</td>		</td>

Operating Systems 2026F: Assignment 1

Soma — Sat, 26 Sep 2026 16:15:12 GMT

← Older revision		Revision as of 16:15, 26 September 2026
Line 1:		Line 1:
	'''This assignment is not yet finalized.'''		'''This assignment is not yet finalized.'''

	Please submit the answers to the following questions via Brightspace by ~~???~~, 2026. There are 20 points in ?? questions.		Please submit the answers to the following questions via Brightspace by October 5, 2026. There are 20 points in eight questions.

	Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.		Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

Operating Systems (Fall 2026)

Soma — Sat, 26 Sep 2026 16:14:41 GMT

Assignments

← Older revision		Revision as of 16:14, 26 September 2026
Line 386:		Line 386:
	<tr>		<tr>
	<td>		<td>
	<p>~~Sep~~. 30		<p>Oct. 5
	</p>		</p>
	</td>		</td>

Operating Systems 2026F: Assignment 1

Soma — Sat, 26 Sep 2026 16:12:02 GMT

← Older revision		Revision as of 16:12, 26 September 2026
(One intermediate revision by the same user not shown)
Line 1:		Line 1:
			'''This assignment is not yet finalized.'''

	Please submit the answers to the following questions via Brightspace by ???, 2026. There are 20 points in ?? questions.		Please submit the answers to the following questions via Brightspace by ???, 2026. There are 20 points in ?? questions.

Line 37:		Line 39:
	<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>		<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>
	<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.		<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.

	~~<li>[5] Replace line 29 in 3000menu.s (the assembly code version) with the following two lines:<br>~~
	~~<tt>    mov $57,%eax</tt><br>~~
	~~<tt>    syscall</tt><br>~~
	~~Create a new binary by compiling the modified assembly language code, calling it 3000menu-q9. It should run the same as before.~~
	~~<ol style="list-style-type:lower-alpha">~~
	~~<li>[1] Is 3000menu-q9 statically or dynamically linked?</li>~~
	~~</ol>~~
	~~</li>~~
	</ol>		</ol>

Operating Systems 2026F: Assignment 1

Soma — Sat, 26 Sep 2026 16:11:09 GMT

Created page with "Please submit the answers to the following questions via Brightspace by ???, 2026. There are 20 points in ?? questions. Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be prope..."

New page

Please submit the answers to the following questions via Brightspace by ???, 2026. There are 20 points in ?? questions.

Submit your answers as a plain text file following [https://homeostasis.scs.carleton.ca/~soma/os-2026f/templates/comp3000-a1-template.txt this template]. Name your answer file "comp3000-assign1-<username>.txt" (where username is your MyCarletonOne username). Please make sure to use your correct student ID number otherwise your grades may not be properly recorded.

Your answers will be parsed by a script in order to help with grading so please preserve the format of the template. No other formats will be accepted.

Note that the file should be a UNIX text file, not a Windows text file (so LF line endings). See the [https://en.wikipedia.org/wiki/Text_file Wikipedia page on text files] to learn more. Most modern text editors can convert between different types of text files. Alternately, install the program <tt>dos2unix</tt> on the VM to convert.

You may use [https://homeostasis.scs.carleton.ca/~soma/os-2026f/validators/a1-validator.html this validator page] to make sure your answer file is properly named and formatted.

Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.

==Introduction==

In this assignment you will be looking at [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c] and its corresponding assembly language version, [https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]. You can download the C source, generate the assembly language code, and compile it with the following commands:

wget https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c
gcc -O -S 3000menu.c
gcc -O 3000menu.c -o 3000menu

Note that you can also just compile the assembly code directly:

gcc -O 3000menu.s -o 3000menu

If <tt>ltrace</tt> doesn't work for you, add the "-z lazy" option when you compile. (This option is not needed on Ubuntu 26.04.)

==Questions==
Please answer the following questions. When a question asks about how do you know, you need to give empirical evidence. References to documentation are not sufficient as documentation can be incorrect.

<ol>
<li>[2] How do you define a custom command for 3000menu without changing its code? What parts 3000menu implement custom command support?</li>
<li>[2] Can menu commands include command line options? Why, or why not?
<li>[2] What compiler directive (an instruction starting with a period) is present at the start of every function? What is at the end of the function? Ignore directives that include the name of the function.</li>
<li>[2] Which line(s) in 3000menu.s implement the if/else statements in <tt>run_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] What line(s) in 3000menu.s implement the call to <tt>getline()</tt> in <tt>choose_program()</tt>? How do you know those are the correct lines?</li>
<li>[2] <tt>printf</tt> calls get translated into two different calls in assembly. What are those two calls? And why is each used (rather than the other)?</li>
<li>[2] Does the code in 3000menu.s make any system calls directly? How do you know? Explain briefly.</li>
<li>[6] How could you modify 3000menu.c so that <tt>run_program()</tt> no longer used <tt>system()</tt> and instead used <tt>fork</tt>, <tt>execve</tt>, and any code from the first two tutorials except for <tt>execvp()</tt>? You may not use any other external code. Your modified version should have equivalent functionality to the original.

<li>[5] Replace line 29 in 3000menu.s (the assembly code version) with the following two lines: 
<tt>    mov $57,%eax</tt> 
<tt>    syscall</tt> 
Create a new binary by compiling the modified assembly language code, calling it 3000menu-q9. It should run the same as before.
<ol style="list-style-type:lower-alpha">
<li>[1] Is 3000menu-q9 statically or dynamically linked?</li>
</ol>
</li>
</ol>

==Code==

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.c 3000menu.c]===

<syntaxhighlight lang="c" line>
/* 3000menu.c */
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <stdlib.h>

char *menu[] = {
"/usr/bin/ls",
"/usr/bin/ps",
"/usr/bin/nano",
"/usr/bin/top",
"CUSTOM",
"QUIT",
NULL
};

int quit = 5;
const int CUSTOM = 4;

void run_program(int choice)
{
int result;

printf("Running %s\n", menu[choice]);

result = system(menu[choice]);

if (result != 0) {
printf("Command failed.\n");
} else {
printf("Command succeeded.\n");
}

return;
}

int choose_program(void)
{
int i = 0;
int choice;
char *input = NULL;
size_t result, n = 0;

printf("\nChoose a program to run:\n\n");

while (i <= quit) {
printf("%d. %s\n", i + 1, menu[i]);
i++;
}

printf("\nYour choice? ");

result = getline(&input, &n, stdin);
choice = atoi(input);
free(input);

if ((result > 0) && (choice > 0) && (choice <= i)) {
return choice - 1;
} else {
return -1;
}
}

int main()
{
int program;
char *c;

c = getenv("MENUCMD");

if (c) {
menu[CUSTOM] = c;
} else {
menu[CUSTOM] = menu[quit];
quit = CUSTOM;
}

while (1) {
program = choose_program();

if (program == quit) {
return 0;
}

if (program != -1) {
run_program(program);
}
}
}
</syntaxhighlight>

===[https://homeostasis.scs.carleton.ca/~soma/os-2026f/code/3000menu.s 3000menu.s]===

<syntaxhighlight lang="asm" line>
.file "3000menu.c"
.text
.section .rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Running %s\n"
.LC1:
.string "Command failed."
.LC2:
.string "Command succeeded."
.text
.globl run_program
.type run_program, @function
run_program:
.LFB51:
.cfi_startproc
endbr64
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
pushq %rbx
.cfi_def_cfa_offset 24
.cfi_offset 3, -24
subq $8, %rsp
.cfi_def_cfa_offset 32
leaq menu(%rip), %rbp
movslq %edi, %rbx
movq 0(%rbp,%rbx,8), %rdx
leaq .LC0(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
movq 0(%rbp,%rbx,8), %rdi
call system@PLT
testl %eax, %eax
je .L2
leaq .LC1(%rip), %rdi
call puts@PLT
.L1:
addq $8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 24
popq %rbx
.cfi_def_cfa_offset 16
popq %rbp
.cfi_def_cfa_offset 8
ret
.L2:
.cfi_restore_state
leaq .LC2(%rip), %rdi
call puts@PLT
jmp .L1
.cfi_endproc
.LFE51:
.size run_program, .-run_program
.section .rodata.str1.1
.LC3:
.string "\nChoose a program to run:\n"
.LC4:
.string "%d. %s\n"
.LC5:
.string "\nYour choice? "
.text
.globl choose_program
.type choose_program, @function
choose_program:
.LFB52:
.cfi_startproc
endbr64
pushq %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
pushq %rbp
.cfi_def_cfa_offset 24
.cfi_offset 6, -24
pushq %rbx
.cfi_def_cfa_offset 32
.cfi_offset 3, -32
subq $32, %rsp
.cfi_def_cfa_offset 64
movq %fs:40, %rax
movq %rax, 24(%rsp)
xorl %eax, %eax
movq $0, 8(%rsp)
movq $0, 16(%rsp)
leaq .LC3(%rip), %rdi
call puts@PLT
cmpl $0, quit(%rip)
js .L9
leaq menu(%rip), %rbp
movl $0, %ebx
leaq .LC4(%rip), %r12
.L7:
addl $1, %ebx
movq 0(%rbp), %rcx
movl %ebx, %edx
movq %r12, %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
addq $8, %rbp
cmpl quit(%rip), %ebx
jle .L7
.L6:
leaq .LC5(%rip), %rsi
movl $2, %edi
movl $0, %eax
call __printf_chk@PLT
leaq 16(%rsp), %rsi
leaq 8(%rsp), %rdi
movq stdin(%rip), %rdx
call getline@PLT
movq %rax, %r12
movl $10, %edx
movl $0, %esi
movq 8(%rsp), %rdi
call __isoc23_strtol@PLT
movq %rax, %rbp
movq 8(%rsp), %rdi
call free@PLT
testl %ebp, %ebp
setg %dl
cmpl %ebx, %ebp
setle %al
andl %eax, %edx
testq %r12, %r12
setne %al
movzbl %al, %eax
andl %edx, %eax
negl %eax
andl %ebp, %eax
subl $1, %eax
movq 24(%rsp), %rdx
subq %fs:40, %rdx
jne .L12
addq $32, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 32
popq %rbx
.cfi_def_cfa_offset 24
popq %rbp
.cfi_def_cfa_offset 16
popq %r12
.cfi_def_cfa_offset 8
ret
.L9:
.cfi_restore_state
movl $0, %ebx
jmp .L6
.L12:
call __stack_chk_fail@PLT
.cfi_endproc
.LFE52:
.size choose_program, .-choose_program
.section .rodata.str1.1
.LC6:
.string "MENUCMD"
.text
.globl main
.type main, @function
main:
.LFB53:
.cfi_startproc
endbr64
subq $8, %rsp
.cfi_def_cfa_offset 16
leaq .LC6(%rip), %rdi
call getenv@PLT
testq %rax, %rax
je .L14
movq %rax, 32+menu(%rip)
.L18:
call choose_program
cmpl %eax, quit(%rip)
je .L20
cmpl $-1, %eax
je .L18
movl %eax, %edi
call run_program
jmp .L18
.L14:
movslq quit(%rip), %rdx
leaq menu(%rip), %rax
movq (%rax,%rdx,8), %rax
movq %rax, 32+menu(%rip)
movl $4, quit(%rip)
jmp .L18
.L20:
movl $0, %eax
addq $8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE53:
.size main, .-main
.globl CUSTOM
.section .rodata
.align 4
.type CUSTOM, @object
.size CUSTOM, 4
CUSTOM:
.long 4
.globl quit
.data
.align 4
.type quit, @object
.size quit, 4
quit:
.long 5
.globl menu
.section .rodata.str1.1
.LC7:
.string "/usr/bin/ls"
.LC8:
.string "/usr/bin/ps"
.LC9:
.string "/usr/bin/nano"
.LC10:
.string "/usr/bin/top"
.LC11:
.string "CUSTOM"
.LC12:
.string "QUIT"
.section .data.rel.local,"aw"
.align 32
.type menu, @object
.size menu, 56
menu:
.quad .LC7
.quad .LC8
.quad .LC9
.quad .LC10
.quad .LC11
.quad .LC12
.quad 0
.ident "GCC: (Ubuntu 15.2.0-16ubuntu1) 15.2.0"
.section .note.GNU-stack,"",@progbits
.section .note.gnu.property,"a"
.align 8
.long 1f - 0f
.long 4f - 1f
.long 5
0:
.string "GNU"
1:
.align 8
.long 0xc0000002
.long 3f - 2f
2:
.long 0x3
3:
.align 8
4:
</syntaxhighlight>

COMP5808 COMP4900 2026F: Openstack Instructions

Lianyingzhao — Sat, 26 Sep 2026 02:28:03 GMT

← Older revision		Revision as of 02:28, 26 September 2026
Line 11:		Line 11:
	#;[[File:boot-source.jpg\|300px]] [[File:select-image-f26.jpg\|580px]]		#;[[File:boot-source.jpg\|300px]] [[File:select-image-f26.jpg\|580px]]
	#; Flavor		#; Flavor
	#;[[File:select-flavor-~~f24~~.jpg\|580px]]		#;[[File:select-flavor-f26.jpg\|580px]]
	# You must add "ping-ssh-egress" to the security groups, or you'll not be able to ping/ssh to your instance.		# You must add "ping-ssh-egress" to the security groups, or you'll not be able to ping/ssh to your instance.
	#; Security groups:		#; Security groups:

File:Select-flavor-f26.jpg

Lianyingzhao — Sat, 26 Sep 2026 02:27:53 GMT

Lianyingzhao uploaded File:Select-flavor-f26.jpg

New page

COMP5808 COMP4900 2026F: Openstack Instructions

Lianyingzhao — Sat, 26 Sep 2026 02:25:07 GMT

← Older revision		Revision as of 02:25, 26 September 2026
Line 9:		Line 9:
	#;[[File:select-project-f26.jpg\|310px]]		#;[[File:select-project-f26.jpg\|310px]]
	# Make a choice for necessary items according to the screenshots attached.		# Make a choice for necessary items according to the screenshots attached.
	#;[[File:boot-source.jpg\|300px]] [[File:select-image-~~f24~~.jpg\|580px]]		#;[[File:boot-source.jpg\|300px]] [[File:select-image-f26.jpg\|580px]]
	#; Flavor		#; Flavor
	#;[[File:select-flavor-f24.jpg\|580px]]		#;[[File:select-flavor-f24.jpg\|580px]]

File:Select-image-f26.jpg

Lianyingzhao — Sat, 26 Sep 2026 02:24:52 GMT

Lianyingzhao uploaded File:Select-image-f26.jpg

New page

COMP5808 COMP4900 2026F: Openstack Instructions

Lianyingzhao — Sat, 26 Sep 2026 02:18:05 GMT

← Older revision		Revision as of 02:18, 26 September 2026
(2 intermediate revisions by the same user not shown)
Line 5:		Line 5:
	# [https://carleton.ca/its/help-centre/student-requiring-vpn-access/ Connect to Carleton's VPN] (if not on campus).		# [https://carleton.ca/its/help-centre/student-requiring-vpn-access/ Connect to Carleton's VPN] (if not on campus).
	# Log in to [https://openstack-stein.scs.carleton.ca/ https://openstack-stein.scs.carleton.ca/]		# Log in to [https://openstack-stein.scs.carleton.ca/ https://openstack-stein.scs.carleton.ca/]
	# Most of you would need to refresh your SCS account to have the right entitlements for our course (or you may not be able to log in or not listed in the COMP4900K-~~F24~~ project): https://newacct.scs.carleton.ca/scs_authentication/newacct-policy-form.php		# Most of you would need to refresh your SCS account to have the right entitlements for our course (or you may not be able to log in or not listed in the COMP4900K-F26 project): https://newacct.scs.carleton.ca/scs_authentication/newacct-policy-form.php
	# Switch to the COMP4900K-~~F24~~ project (top-left corner), and launch an instance (button on the right).		# Switch to the COMP4900K-F26 project (top-left corner), and launch an instance (button on the right).
	#;[[File:select-project-~~f24~~.jpg\|~~300px~~]]		#;[[File:select-project-f26.jpg\|310px]]
	# Make a choice for necessary items according to the screenshots attached.		# Make a choice for necessary items according to the screenshots attached.
	#;[[File:boot-source.jpg\|300px]] [[File:select-image-f24.jpg\|580px]]		#;[[File:boot-source.jpg\|300px]] [[File:select-image-f24.jpg\|580px]]

File:Select-project-f26.jpg

Lianyingzhao — Sat, 26 Sep 2026 02:16:03 GMT

Lianyingzhao uploaded File:Select-project-f26.jpg

New page

COMP5808 COMP4900 2026F: Openstack Instructions

Lianyingzhao — Sat, 26 Sep 2026 00:18:48 GMT

Created page with "You can create a VM instance on the [https://carleton.ca/scs/tech-support/scs-open-stack/ SCS openstack] cluster for the assignments, by doing the following: Obvious steps are skipped. You can always reach out to the TA or the instructor for any technical questions. # [https://carleton.ca/its/help-centre/student-requiring-vpn-access/ Connect to Carleton's VPN] (if not on campus). # Log in to [https://openstack-stein.scs.carleton.ca/ https://openstack-stein.scs.carleton..."

New page

You can create a VM instance on the [https://carleton.ca/scs/tech-support/scs-open-stack/ SCS openstack] cluster for the assignments, by doing the following:

Obvious steps are skipped. You can always reach out to the TA or the instructor for any technical questions.

# [https://carleton.ca/its/help-centre/student-requiring-vpn-access/ Connect to Carleton's VPN] (if not on campus).
# Log in to [https://openstack-stein.scs.carleton.ca/ https://openstack-stein.scs.carleton.ca/]
# Most of you would need to refresh your SCS account to have the right entitlements for our course (or you may not be able to log in or not listed in the COMP4900K-F24 project): https://newacct.scs.carleton.ca/scs_authentication/newacct-policy-form.php
# Switch to the COMP4900K-F24 project (top-left corner), and launch an instance (button on the right).
#;[[File:select-project-f24.jpg|300px]]
# Make a choice for necessary items according to the screenshots attached.
#;[[File:boot-source.jpg|300px]] [[File:select-image-f24.jpg|580px]]
#; Flavor
#;[[File:select-flavor-f24.jpg|580px]]
# You must add "ping-ssh-egress" to the security groups, or you'll not be able to ping/ssh to your instance.
#; Security groups:
#;[[File:security-group.jpg|580px]]
# Assign a floating IP.
#;[[File:floating-ip.jpg|170px]]
#; NEVER attempt to create a snapshot
# Then the new IP address (134.117.XXX.XXX) to the right of 192.168.XXX.XXX will be the one (floating IP) you will use to connect to your instance.
# Note down your floating IP and your instance name for subsequent uses for the rest of the term.
# Log in to your instance with username "student" and password "student" (you will be prompted to change your password right away).

Operating Systems 2026F Lecture 5

Soma — Fri, 25 Sep 2026 21:10:27 GMT

Created page with "==Video== Video from the lectures given on September 24th and 25th, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05a-20260924.mp4 Lecture 5A] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05b-20260925.mp4 Lecture 5B] ==Notes== ===Lecture 5A=== <pre> Lecture 5a ---------- The memory map of a process - every process has its own view of memory, cannot see the memory of other..."

New page

==Video==

Video from the lectures given on September 24th and 25th, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05a-20260924.mp4 Lecture 5A]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05b-20260925.mp4 Lecture 5B]

==Notes==

===Lecture 5A===

<pre>
Lecture 5a
----------

The memory map of a process
- every process has its own view of memory, cannot see the memory of other processes
- what goes in that address space?

Note that, almost always, the entire address space is NOT VALID MEMORY
- if you access most of it, you'll get an error (segmentation error generally)

So what is a segment?

Well first, consider the address
- 64 bit pointer, so 2^64 possible addresses

We can't have this much RAM, so most of these addresses are invalid.
- but which ones are valid?
- and on what basis?

First, we should talk about the stack and the heap

The heap is just memory that is allocated in chunks, with each chunk pointed to
by a pointer
- when you call malloc, you're getting memory from the heap
- when you create a new object in most languages other than C, you're really
getting memory from the heap (mostly)

How to manage the heap is a complex problem, solved by memory allocators, garbage collection, etc (beyond the scope of this class)

The stack is memory that is managed in a very simple way: as a stack
- LIFO (last in, first out), e.g., a stack of plates

A stack is great because...
- no memory leaks!
- allocation and de-allocation is trivial

But the discipline of a stack only makes sense in certain contexts

Fortunately, we've built our programming languages around those contexts:
FUNCTIONS

When a program enters a function, it allocates memory for the function
When the function exits, that function's storage needs to be de-allocated

So we need somewhere to put the stack and somewhere to put the heap
- could separate, but normally are allocated together

Stack grows from himem (of data segment) down
heap grows up from the bottom of the data segment

if you put some invalid memory in the middle, you can know when they would potentially overlap (because access to it will generate an error)

a segmentation violation is just an access to memory that hasn't been allocated

So what's in memory?

<top>
command line args, environment vars

Data
------ "break"
Code

<bottom>

So the command line arguments and environment variables passed to a program
are at the top of the process's address space. The kernel put them there when
the program was launched.

fork duplicates the current process
execve replaces the current program with a new one
- neither act like normal "functions", because they are system calls

Windows has

Remember in C we make system calls by calling functions
- the functions that make system calls are using compiler-specific ways
of making the special CPU instructions for system calls

fork <- to make a process
execve <- to load a program into a process
exit <- to terminate a process
wait <- wait for a child to finish

If the parent doesn't wait for its child, and the child terminates,
the child sticks around in a zombie state
- it is already dead but still around, cannot be further killed

zombies stick around as long as their parent exists
zombies are "reaped" once the parent dies
- init or similar will call wait

How do we run programs?

Run fork
- duplicates current process, creating a child process

in the parent
- wait for the child to finish, or
- go do other work and call wait will notified
of child termination

in the child
- set up things for new program
- standard in, out, error, other open files
- close any files that SHOULD NOT be accessible
- command line arguments
- environment variables
- execve new program

In practice, you won't actually see the fork system call nowadays,
at least on Linux systems. Instead, you'll see clone

Containers - have you heard of them?

So containers are all about managing software and dependencies
- very poor security isolation properties

Turns out when you create a new process, you can change its view of the world
- e.g., give it a different view of the filesystem

namespaces is how you map the following for a process and its children

/newsystem/bin => /bin
uid 1000 => uid 0
</pre>

===Lecture 5B===

<pre>
Lecture 5b
----------

Planning to move midterm to Oct 20, 21
- so review will be Oct 15, 16
- assignment 2 will be due on the 15th 2:30 PM
- a1 will be put off a bit will finalize when posted (you'll have at least a week)
- A1 will be based on T1 and T2

For today, we're talking memory

With modern OSs, each running process gets its own address space
- so 64 bits in size
- most of that address space is not allocated, so cannot
be used or will generate an error
- typically the error is a "segmentation violation"
- so what is a segment?

A segment is a unit of memory that has a specific "purpose"
- contiguous addresses

What segments are there? You'll at least have
- code (text), read only
- data, read write
- global variables
- dynamically-allocated storage

The data segment has to store two logically distinct types of dynamically allocated memory: the stack and the heap

The heap is used to store dynamically allocated objects/data structures that have indeterminate lifetimes
- could be around for a few milliseconds
- could exist for most of the run of the program (but aren't known at compile time)
- malloc (C), new (C++), most everything in JavaScript & Python

Now this might sound complicated because IT IS
- entire area of memory management techniques
- automatic memory management is called "garbage collection"
- not only but most general approach

The heap is complex, hard to do right, so traditionally UNIX programs have avoided using the heap as much as possible and instead used the stack

So what's the stack?
- data structure that respects LIFO discipline (last in, first out)

A process normally has one stack that is used for functions
- local variables
- arguments
- return values

heap grows up from bottom of data segment
stack grows down from the top of the data segment

normally some invalid memory in the middle so you know when the two run into each other

Where do the environment variables and command line variables come from?

Those are both arguments of the execve system call

Key system calls for running a program in a new process are:
- fork
- execve
- wait

fork: duplicates the current process
- new process is called the child, old the parent
- except for the PID/PPID and the return value of fork(),
code, data, and other state are IDENTICAL

child calls execve
- sets up argv, env, open files (standard in/out/error +),
signal handlers (will discuss later)
- then loads new program binary with execve call, which REPLACES
the code in the process
- if execve returns, it failed

parent calls wait
- either literally waiting for child process to terminate, or
- in response to a signal that the child has terminated

Why does the parent care about the child process terminating?
- because it has a return status

processes terminate with the exit system call, and exit takes an integer argument that is past via wait to the parent

Modern Linux systems tend not to use the fork system call
- fork() actually calls clone

If you don't use setarch -R to run 3000memview, addresses will be randomized. This is ASLR in action: address space layout randomization
</pre>

Operating Systems 2026F: Tutorial 2

Soma — Thu, 24 Sep 2026 21:14:40 GMT

Setting up and connecting a VM

← Older revision		Revision as of 21:14, 24 September 2026
Line 25:		Line 25:
	===Setting up and connecting a VM===		===Setting up and connecting a VM===

	Create a VM on the SCS openstack cluster as shown in ~~lecture~~. Make sure do the following:		Create a VM on the SCS openstack cluster as shown in the SCS documentation. Make sure do the following:
	* Choose the COMP3000-F26.2026-* instance snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.		* Choose the COMP3000-F26.2026-* instance snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
	* Add the ping-ssh-egress security group, and		* Add the ping-ssh-egress security group, and

Operating Systems 2026F Lecture 4

Soma — Thu, 24 Sep 2026 21:12:19 GMT

Video

@@ Line 2: / Line 2: @@
 Video from the lectures given on September 22nd and 23rd, 2026 are now available:
-* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04a-20260922.mp4 September 15th video]
+* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04a-20260922.mp4 Lecture 4A]
-* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04b-20260923.mp4 September 16th video]
+* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04b-20260923.mp4 Lecture 4B]

Operating Systems 2026F Lecture 4

Soma — Thu, 24 Sep 2026 17:45:18 GMT

Created page with "==Video== Video from the lectures given on September 22nd and 23rd, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04a-20260922.mp4 September 15th video] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04b-20260923.mp4 September 16th video]"

New page

==Video==

Video from the lectures given on September 22nd and 23rd, 2026 are now available:
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04a-20260922.mp4 September 15th video]
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec04b-20260923.mp4 September 16th video]

COMP5808 COMP4900 2026F: Reading list

Lianyingzhao — Tue, 22 Sep 2026 05:39:04 GMT

← Older revision		Revision as of 05:39, 22 September 2026
(One intermediate revision by the same user not shown)
Line 29:		Line 29:
	** [https://www.usenix.org/system/files/conference/atc17/atc17-lind.pdf Glamdring: Automatic Application Partitioning for Intel SGX] (*)		** [https://www.usenix.org/system/files/conference/atc17/atc17-lind.pdf Glamdring: Automatic Application Partitioning for Intel SGX] (*)
	** [https://www.usenix.org/conference/atc17/technical-sessions/presentation/tsai Graphene-SGX: A Practical Library OS for Unmodified Applications on SGX] (*) <span style="color:#0000ff;font-weight:bold"> Recommended </span>		** [https://www.usenix.org/conference/atc17/technical-sessions/presentation/tsai Graphene-SGX: A Practical Library OS for Unmodified Applications on SGX] (*) <span style="color:#0000ff;font-weight:bold"> Recommended </span>
			** [https://www.ndss-symposium.org/wp-content/uploads/2025-385-paper.pdf The Road to Trust: Building Enclaves within Confidential VMs] (*) <span style="color:#0000ff;font-weight:bold"> Recommended </span>
	** [https://dl.acm.org/doi/pdf/10.1145/3373376.3378469 Occlum: Secure and Efficient Multitasking Inside a Single Enclave of Intel SGX] (*)		** [https://dl.acm.org/doi/pdf/10.1145/3373376.3378469 Occlum: Secure and Efficient Multitasking Inside a Single Enclave of Intel SGX] (*)
	** [https://www.usenix.org/system/files/sec20spring_tsai_prepub.pdf Civet: An Efficient Java Partitioning Framework for Hardware Enclaves] (*)		** [https://www.usenix.org/system/files/sec20spring_tsai_prepub.pdf Civet: An Efficient Java Partitioning Framework for Hardware Enclaves] (*)
Line 42:		Line 43:
	** [https://www.usenix.org/conference/usenixsecurity18/presentation/lipp Meltdown: Reading Kernel Memory from User Space] (*)		** [https://www.usenix.org/conference/usenixsecurity18/presentation/lipp Meltdown: Reading Kernel Memory from User Space] (*)
	** [https://ieeexplore.ieee.org/abstract/document/8835233 Spectre Attacks: Exploiting Speculative Execution] (*)		** [https://ieeexplore.ieee.org/abstract/document/8835233 Spectre Attacks: Exploiting Speculative Execution] (*)
	** ~~Latest:~~ [https://www.usenix.org/system/files/usenixsecurity23-moghimi.pdf Downfall: Exploiting Speculative Data Gathering] (*)		** [https://www.usenix.org/system/files/usenixsecurity23-moghimi.pdf Downfall: Exploiting Speculative Data Gathering] (*)
	* Internal misbehavior: memory attacks		* Internal misbehavior: memory attacks
	** [https://ieeexplore.ieee.org/document/6547101 SoK: Eternal War in Memory] (*)		** [https://ieeexplore.ieee.org/document/6547101 SoK: Eternal War in Memory] (*)

COMP5900 COMP4900 2024F: Reading list

Lianyingzhao — Tue, 22 Sep 2026 05:37:38 GMT

← Older revision	Revision as of 05:37, 22 September 2026
(One intermediate revision by the same user not shown)
(No difference)

Operating Systems (Fall 2026)

Soma — Mon, 21 Sep 2026 19:16:04 GMT

Tutorials

← Older revision		Revision as of 19:16, 21 September 2026
Line 268:		Line 268:

	==Tutorials==		==Tutorials==

			Tutorials must be marked within 8 days of the tutorial being made available. (For example, T1 must be marked by the end of Sept. 22nd.)

	<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">		<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">

Operating Systems 2026F: Tutorial 2

Soma — Mon, 21 Sep 2026 16:18:34 GMT

← Older revision		Revision as of 16:18, 21 September 2026
(One intermediate revision by the same user not shown)
Line 1:		Line 1:
	~~'''This tutorial is not yet finalized.'''~~

	In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.		In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.

Line 28:		Line 26:

	Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:		Create a VM on the SCS openstack cluster as shown in lecture. Make sure do the following:
	* Choose the ~~comp3000~~-~~2026f~~-* snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.		* Choose the COMP3000-F26.2026-* instance snapshot image ONLY (others won't have the right software for later tutorials), use the latest one.
	* Add the ping-ssh-egress security group, and		* Add the ping-ssh-egress security group, and
	* Associating a floating IP address.		* Associating a floating IP address.

Operating Systems (Fall 2026)

Soma — Mon, 21 Sep 2026 13:33:27 GMT

Assignments

← Older revision		Revision as of 13:33, 21 September 2026
Line 384:		Line 384:
	<tr>		<tr>
	<td>		<td>
	<p>Sep. 28		<p>Sep. 30
	</p>		</p>
	</td>		</td>

Operating Systems 2026F: Tutorial 2

Soma — Sun, 20 Sep 2026 15:02:38 GMT

← Older revision		Revision as of 15:02, 20 September 2026
(5 intermediate revisions by the same user not shown)
Line 1:		Line 1:
	'''This tutorial is ~~still in development~~.'''		'''This tutorial is not yet finalized.'''

	In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.		In this tutorial we're going to look at how processes work at a low level: how they make system calls & library calls, how C and assembly compare, and and how memory is laid out.
Line 130:		Line 130:

	<ol>		<ol>
			<li>Join the class Team if you haven't already. Link is in brightspace.</li>
	<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>		<li>How does the environment of the Openstack VM compare to the LinuxOnTab one from Tutorial 1? Specifically, how do the following compare?</li>
	<ol style="list-style-type:lower-alpha">		<ol style="list-style-type:lower-alpha">
Line 142:		Line 143:
	<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>		<li>Compile and run [http://people.scs.carleton.ca/~soma/os-2019w/code/csimpleshell.c <tt>csimpleshell.c</tt>]. How does its functionality compare to that of bash? List at least 3 differences.</li>
	</ol>		</ol>


	===B: Function calls, library calls, and system calls===		===B: Function calls, library calls, and system calls===
Line 169:		Line 169:
	* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.		* If a register is in parentheses, then it is being used as a "pointer" (it contains an address, so the CPU goes to that address and interacts with the memory there). If there is a number before the parentheses, it is an offset to the register's value.

	Resources on x86-64 assembly language:		Resources on x86-64 assembly language (only needed if you want to learn more):
	* [https://~~cs61~~.~~seas~~.~~harvard~~.edu/~~site~~/~~2018~~/~~Asm1~~/ ~~Eddie Kohler's assembly language basics (2018)~~] ~~(also see other notes from this class)~~		* [https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf CMU introduction to x86-64]
	* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]		* [https://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax AT&T/GNU Assembler syntax]
	* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]		* [https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI the Wikipedia article on calling conventions]


	# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?		# Using the <tt>nm</tt> command, see what symbols are defined in prog-static and prog-dyn. Which defines more symbols?
Line 197:		Line 196:
	# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)		# Change each malloc call to allocate more than 128K. What happens to the values of sbrk? Why? (Hint: use strace)
	# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?		# Add more code and data to the program, and add more printf's to see where things are. Are things where you expect them to be?


	==Code==		==Code==