Operating Systems 2017F Lecture 16 - Revision history

Krithikasaravanan at 08:38, 24 November 2017

2017-11-24T08:38:56Z

← Older revision		Revision as of 08:38, 24 November 2017
Line 166:		Line 166:
	=== Additional Notes ===		=== Additional Notes ===

	What determines what files you can and cannot create? -> Ssh privileges <br>		What determines what files you can and cannot create?<br>
			* Ssh privileges <br>
			<br>
	* Anything that you can do as an ssh user you can do in the vm, just doing file operations<br>		* Anything that you can do as an ssh user you can do in the vm, just doing file operations<br>
	* Sshfs means when you do read and write system calls for programs in a directory it also does it on the remote machine<br>		* Sshfs means when you do read and write system calls for programs in a directory it also does it on the remote machine<br>

Krithikasaravanan at 08:37, 24 November 2017

2017-11-24T08:37:53Z

← Older revision		Revision as of 08:37, 24 November 2017
Line 163:		Line 163:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules		$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
	</source>		</source>

			=== Additional Notes ===

			What determines what files you can and cannot create? -> Ssh privileges <br>

			* Anything that you can do as an ssh user you can do in the vm, just doing file operations<br>
			* Sshfs means when you do read and write system calls for programs in a directory it also does it on the remote machine<br>
			* Ssh is a good tool to access remote files locally, we will use it to edit modules<br>
			<br>
			Ones/newgetpid program:<br>
			* We want to extend its functionality in a specific way<br>
			* We want to access info about the process that made the system call<br>
			* Let's get current processes id<br>
			** Normally we would use getpid<br>
			** But we can't make system calls in kernel space<br>
			** But we can call the function that the system call uses or just copy the functionality<br>
			* Code for this is in "kernel/sys.c"<br>
			<br>
			Syscall_define0:<br>
			* Macro that expands<br>
			* Defines system calls with "getpid" and takes no arguments<br>
			<br>
			* Can use the code inside the function but not the function itself in the kernel<br>
			* Getpid returns a pid_t<br>
			* Instead of get_ones returning all those ones we want it to return the pid<br>
			* Lets try to get it to output a basic string with the pid<br>
			<br>
			How does printk work?<br>
			* Printk sends its output to the kernel log<br>
			* We changed the name to "newgetpid"<br>
			* How do we convert int to string to print the pid?<br>
			** Make a buffer, let's call it "message"<br>
			<br>
			Why does the pid keep incrementing each time we call "cat /dev/newgetpid"?<br>
			* "Cat" spawns a process so every time we do a fork we get a new pid<br>
			<br>
			Why can we use snprintf but not printf?<br>
			* We include "linux/kernel.h" which defines snprintf but not printf<br>
			* Printf assumes we have a standard output to print to<br>
			* Snprintf only needs character arrays for it to work<br>
			<br>
			* Read functionality uses an API<br>
			* Adding new functionality like "write" is easy, just look at the standard API and original kernel source<br>
			* All device files have their own custom read and write functions<br>
			<br>
			Why do we use goto's?<br>
			* C has no exception handling functionality so we implement our own<br>
			* Jumps to error paths: failed_devreg, failed_classreg, failed_chrdevreg (very important in the kernel)<br>
			* Kernel needs to be able to handle it's own errors<br>
			* Needs to free up allocated resources, "undo" everything<br>
			<br>
			* "." is the current directory<br>
			* ".." is the parent directory<br>
			** Introduces another hardlink<br>
			<br>
			* In order to build kernel modules, you need to have the headers associated with the current kernel you're running
			* Modules are specified to a particular version of the kernel

Soma: /* Code */

2017-11-10T01:35:58Z

Code

← Older revision		Revision as of 01:35, 10 November 2017
Line 4:		Line 4:

	==Code==		==Code==

			[http://homeostasis.scs.carleton.ca/~soma/os-2017f/code/lec16/newgetpid.zip Code for download]

	==newgetpid.c==		==newgetpid.c==

Soma: /* newgetpid.c */

2017-11-10T01:34:48Z

newgetpid.c

← Older revision		Revision as of 01:34, 10 November 2017
Line 7:		Line 7:
	==newgetpid.c==		==newgetpid.c==

	<source lang="C" ~~lines~~>		<source lang="C" line>
	/* Code derived from:		/* Code derived from:
	https://appusajeev.wordpress.com/2011/06/18/writing-a-linux-character-device-driver/		https://appusajeev.wordpress.com/2011/06/18/writing-a-linux-character-device-driver/

Soma: /* Makefile */

2017-11-10T01:34:33Z

Makefile

← Older revision		Revision as of 01:34, 10 November 2017
Line 154:		Line 154:
	==Makefile==		==Makefile==

	<source lang=make ~~lines~~>		<source lang=make line>
	obj-m := newgetpid.o		obj-m := newgetpid.o
	KDIR := /lib/modules/$(shell uname -r)/build		KDIR := /lib/modules/$(shell uname -r)/build

Soma: /* Code */

2017-11-10T01:34:17Z

Code

Show changes

Soma at 01:14, 10 November 2017

2017-11-10T01:14:49Z

← Older revision	Revision as of 01:14, 10 November 2017
Line 1:	Line 1:
		==Video==

		The video from the lecture given on Nov. 7, 2017 [http://homeostasis.scs.carleton.ca/~soma/os-2017f/lectures/comp3000-2017f-lec16-09Nov2017.mp4 is now available].

		==Code==

Soma: Blanked the page

2017-11-10T00:28:13Z

Blanked the page

Show changes

Krithikasaravanan at 19:40, 7 November 2017

2017-11-07T19:40:20Z

← Older revision		Revision as of 19:40, 7 November 2017
Line 103:		Line 103:
	o Override that? Still your permission is denied, you can only read since we didn’t write a function in the struct to write.		o Override that? Still your permission is denied, you can only read since we didn’t write a function in the struct to write.

	Additional notes:		'''Additional notes:'''
	--> Warning: it's possible to destroy your entire system with 1 command. Solution: have good backups		--> Warning: it's possible to destroy your entire system with 1 command. Solution: have good backups
	--> Core kernel functionality is implemented via modules		--> Core kernel functionality is implemented via modules

Krithikasaravanan at 19:39, 7 November 2017

2017-11-07T19:39:58Z

← Older revision		Revision as of 19:39, 7 November 2017
Line 102:		Line 102:
	 What happens if you start running to the file ? permission are read only, not writing		 What happens if you start running to the file ? permission are read only, not writing
	o Override that? Still your permission is denied, you can only read since we didn’t write a function in the struct to write.		o Override that? Still your permission is denied, you can only read since we didn’t write a function in the struct to write.

			Additional notes:
			--> Warning: it's possible to destroy your entire system with 1 command. Solution: have good backups
			--> Core kernel functionality is implemented via modules
			--> use ls mod to see modules that are loaded
			--> In practice, you load modules all at once

			'''Why do we need to load code into the kernel anyways?'''
			--> more secure, ability to restrict access

			--> examples of microkernel: minix (predecessor to Linux), QNX, GNU hurd
			--> once you install a module, it's unrestrained

			'''What is a monolithic kernel?'''
			--> a type of OS architecture where the entire OS is working in kernel space
			--> can dynamically load/unload modules at runtime

			'''make localmodconfig:'''
			--> takes output of ls mod and configures your kernel

			'''ones.c program:'''

			'''/dev/ones:'''
			--> permissions are read only

			'''file_operations ones_fops():'''
			--> define what happens when you open a file, read from it, release tells you what happens when you're done with it (not the same thing as close)

			'''ones_read():'''
			--> len = number of bytes to read
			--> offset tells you where you are in the file
			--> put_user(): takes care of whatever needs to be done to write into that process properly

			'''ones_release:'''

			'''Why are we using printk instead of printf?'''
			--> printf is not yet defined (ie. C library is not available in the kernel)
			--> kernel doesn't depend on any libraries, all code belongs to the kernel itself
			--> printk is the kernel's own implementation of printf (outputs to the kernel log --> /var/log/kern.log)

			vfs = virtual filesystem layer

			'''How do we limit access to user space processes?'''
			--> Do a permission check

			--> kernels need to be updated regularly to correct bugs that make the kernel vulnerable to programs trying to gain access to important user space processes
			--> unlikely() = tells you that this branch is not likely to be taken, optimize the current path

			'''vfs_read:'''

			'''file->f_op->read:'''
			--> this is how our read function will be called