Operating Systems 2018F: Assignment 3 - Revision history

Soma: /* Solutions */

2018-11-13T02:43:29Z

Solutions

← Older revision		Revision as of 02:43, 13 November 2018
Line 37:		Line 37:
	#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.		#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.
	# It wouldn't change the behavior of /dev/newgetpid; however, it would change the names of the directories created in /sys/class/ and /sys/devices/virtual/. (Note: you could find these files by running 'find /sys -name "carleton"'		# It wouldn't change the behavior of /dev/newgetpid; however, it would change the names of the directories created in /sys/class/ and /sys/devices/virtual/. (Note: you could find these files by running 'find /sys -name "carleton"'
	# put_user() is used in /dev/ones to write to userspace, specifically to write to the buffer supplied to ones_write.		# put_user() is used in /dev/ones to write to userspace, specifically to write to the buffer supplied to ones_write. Also, copy_from_user() and copy_to_user() are used for /dev/remember to read data from userspace (in remember_write) and write data to userspace (in remember_read), respectively.
	Also, copy_from_user() and copy_to_user() are used for /dev/remember to read data from userspace (in remember_write) and write data to userspace (in remember_read), respectively.		# See how /dev/remember responds to write requests. The key changes that have to be made is adding a .write to the file_operations struct, creating the appropriate write function, and changing the permissions of the device file to allow for writing (in the _devnode function).
	#		# If you destroy all the superblocks in a filesystem (including the backup ones), you normally would not be able to recover the filesystem as the superblock is needed in order to determine the filesystems block size, the location of inodes, and other aspects of the filesystem layout. Having said that, in principle you could recover the filesystem by re-creating its superblock, but this could be very difficult depending on how dynamic the layout of the filesystem is.
	#		# lost+found is used by fsck to store inodes that have been found to be allocated but which have no corresponding directory entries. This situation can happen if the filesystem is corrupted, say by erasing the blocks of a directory.
	#		# This question is important because it helps you determine whether an attacker is attempting to intercept the connection (i.e., is performing an intruder-in-the-middle attack). To prevent such an attack, you should have gotten the server's host key fingerprint previously so you can compare it to the one presented on first connection. (After the first connection, .ssh/known_hosts will have the remote server's host key. If the server ever presents a different key ssh will warn of a potential intruder in the middle attack.)
	#		# The files in scs-files won't have a uid=1000; instead, it will have whatever uid you have on access.scs.carleton.ca. If the files are marked as readable by the owner, you will be able to access them because the ssh process spawned on access.scs.carleton.ca (to send data to the local sshfs process) will be running as "you", and so it will have access to all of "your" files.
	#		# To create foo with a logical size of 20 GiB but taking up no space on disk, run "truncate -s 20G foo". (You don't want to use dd as then you'd have a file that actually takes up 20GiB.)


	#		#

Soma: /* Solutions */

2018-11-13T02:31:50Z

Solutions

← Older revision		Revision as of 02:31, 13 November 2018
Line 37:		Line 37:
	#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.		#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.
	# It wouldn't change the behavior of /dev/newgetpid; however, it would change the names of the directories created in /sys/class/ and /sys/devices/virtual/. (Note: you could find these files by running 'find /sys -name "carleton"'		# It wouldn't change the behavior of /dev/newgetpid; however, it would change the names of the directories created in /sys/class/ and /sys/devices/virtual/. (Note: you could find these files by running 'find /sys -name "carleton"'
			# put_user() is used in /dev/ones to write to userspace, specifically to write to the buffer supplied to ones_write.
			Also, copy_from_user() and copy_to_user() are used for /dev/remember to read data from userspace (in remember_write) and write data to userspace (in remember_read), respectively.
	#		#
	#
	#		#
	#		#

Soma: /* Solutions */

2018-11-13T02:21:08Z

Solutions

← Older revision		Revision as of 02:21, 13 November 2018
Line 36:		Line 36:
	#* You could prevent those module(s) from loading by making their files inaccessible (say, by deleting them). You can find the files in /lib/modules/<kernel-version> (in some subdirectory).		#* You could prevent those module(s) from loading by making their files inaccessible (say, by deleting them). You can find the files in /lib/modules/<kernel-version> (in some subdirectory).
	#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.		#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.
	# It wouldn't change the behavior of /dev/newgetpid; however, it would change the names of the directories created in /sys/class/ and /sys/devices/virtual/.		# It wouldn't change the behavior of /dev/newgetpid; however, it would change the names of the directories created in /sys/class/ and /sys/devices/virtual/. (Note: you could find these files by running 'find /sys -name "carleton"'
	#		#
	#		#
	#		#

Soma: /* Solutions */

2018-11-13T02:19:47Z

Solutions

← Older revision		Revision as of 02:19, 13 November 2018
Line 36:		Line 36:
	#* You could prevent those module(s) from loading by making their files inaccessible (say, by deleting them). You can find the files in /lib/modules/<kernel-version> (in some subdirectory).		#* You could prevent those module(s) from loading by making their files inaccessible (say, by deleting them). You can find the files in /lib/modules/<kernel-version> (in some subdirectory).
	#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.		#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.
	#		# It wouldn't change the behavior of /dev/newgetpid; however, it would change the names of the directories created in /sys/class/ and /sys/devices/virtual/.
	#		#
	#		#

Soma: /* Solutions */

2018-11-13T02:16:07Z

Solutions

← Older revision		Revision as of 02:16, 13 November 2018
Line 32:		Line 32:
	# Man pages are not a good source of documentation on kernel APIs because most kernel APIs are, in effect, private - the Linux kernel doesn't maintain a stable internal interface. Any man pages that would be created would need to be continuously updated in order to stay up to date. To figure out how to call kernel routines, you ultimately have to consult the code of the kernel itself.		# Man pages are not a good source of documentation on kernel APIs because most kernel APIs are, in effect, private - the Linux kernel doesn't maintain a stable internal interface. Any man pages that would be created would need to be continuously updated in order to stay up to date. To figure out how to call kernel routines, you ultimately have to consult the code of the kernel itself.
	# The functions designated by module_init() and module_exit() are guaranteed to be called, with the module_init()-designated function being called when the module is loaded and module_exit()-designated function called when the module is unloaded. These functions run with the same privileges as all kernel code, allowing them to modify anything on the system.		# The functions designated by module_init() and module_exit() are guaranteed to be called, with the module_init()-designated function being called when the module is loaded and module_exit()-designated function called when the module is unloaded. These functions run with the same privileges as all kernel code, allowing them to modify anything on the system.
			# USB webcam answers:
	#* To find out what modules were loaded, you could run lsmod before and after the webcam was attached and compare the results.		#* To find out what modules were loaded, you could run lsmod before and after the webcam was attached and compare the results.
	#* You could prevent those module(s) from loading by making their files inaccessible (say, by deleting them). You can find the files in /lib/modules/<kernel-version> (in some subdirectory).		#* You could prevent those module(s) from loading by making their files inaccessible (say, by deleting them). You can find the files in /lib/modules/<kernel-version> (in some subdirectory).

Soma: /* Solutions */

2018-11-13T02:15:36Z

Solutions

← Older revision		Revision as of 02:15, 13 November 2018
Line 32:		Line 32:
	# Man pages are not a good source of documentation on kernel APIs because most kernel APIs are, in effect, private - the Linux kernel doesn't maintain a stable internal interface. Any man pages that would be created would need to be continuously updated in order to stay up to date. To figure out how to call kernel routines, you ultimately have to consult the code of the kernel itself.		# Man pages are not a good source of documentation on kernel APIs because most kernel APIs are, in effect, private - the Linux kernel doesn't maintain a stable internal interface. Any man pages that would be created would need to be continuously updated in order to stay up to date. To figure out how to call kernel routines, you ultimately have to consult the code of the kernel itself.
	# The functions designated by module_init() and module_exit() are guaranteed to be called, with the module_init()-designated function being called when the module is loaded and module_exit()-designated function called when the module is unloaded. These functions run with the same privileges as all kernel code, allowing them to modify anything on the system.		# The functions designated by module_init() and module_exit() are guaranteed to be called, with the module_init()-designated function being called when the module is loaded and module_exit()-designated function called when the module is unloaded. These functions run with the same privileges as all kernel code, allowing them to modify anything on the system.
	#		#* To find out what modules were loaded, you could run lsmod before and after the webcam was attached and compare the results.
			#* You could prevent those module(s) from loading by making their files inaccessible (say, by deleting them). You can find the files in /lib/modules/<kernel-version> (in some subdirectory).
			#* If the webcam modules didn't use dynamically allocated memory properly, they could corrupt the kernel and cause the system to crash or otherwise malfunction.
	#		#
	#		#

Soma: /* Solutions */

2018-11-13T02:12:12Z

Solutions

← Older revision		Revision as of 02:12, 13 November 2018
Line 30:		Line 30:
	==Solutions==		==Solutions==

	#		# Man pages are not a good source of documentation on kernel APIs because most kernel APIs are, in effect, private - the Linux kernel doesn't maintain a stable internal interface. Any man pages that would be created would need to be continuously updated in order to stay up to date. To figure out how to call kernel routines, you ultimately have to consult the code of the kernel itself.
	#		# The functions designated by module_init() and module_exit() are guaranteed to be called, with the module_init()-designated function being called when the module is loaded and module_exit()-designated function called when the module is unloaded. These functions run with the same privileges as all kernel code, allowing them to modify anything on the system.
	#		#
	#		#
	#		#

Soma at 02:02, 13 November 2018

2018-11-13T02:02:19Z

← Older revision		Revision as of 02:02, 13 November 2018
Line 27:		Line 27:
	#* Assume a file in scs-files is marked as being readable only by the owner. Will you be able to read the contents of this file? Why or why not?		#* Assume a file in scs-files is marked as being readable only by the owner. Will you be able to read the contents of this file? Why or why not?
	# [1] How can you make a file that is 20 GB in size (you can read 20 GB of information from it) but takes up essentially no space on disk?		# [1] How can you make a file that is 20 GB in size (you can read 20 GB of information from it) but takes up essentially no space on disk?

			==Solutions==

			#
			#
			#
			#
			#
			#
			#
			#
			#
			#
			#

Soma at 20:50, 7 November 2018

2018-11-07T20:50:54Z

← Older revision		Revision as of 20:50, 7 November 2018
Line 10:		Line 10:

	# [2] Are man pages a good documentation source when developing kernel modules? Why or why not?		# [2] Are man pages a good documentation source when developing kernel modules? Why or why not?
	# [2] When you load a kernel module, what code is guaranteed to run? With what privileges will this code run?		# [2] When you load a kernel module, what code is guaranteed to run? (Which functions will definitely be called?) With what privileges will this code run?
	# [3] You attach a new USB webcam to your computer that is running Linux. The webcam is recognized and works properly.		# [3] You attach a new USB webcam to your computer that is running Linux. The webcam is recognized and works properly.
	#* How could you find out what kernel module(s) were loaded, if any, when you attached the webcam?		#* How could you find out what kernel module(s) were loaded, if any, when you attached the webcam?

Soma at 18:14, 1 November 2018

2018-11-01T18:14:41Z

← Older revision		Revision as of 18:14, 1 November 2018
Line 1:		Line 1:
	Please submit the answers to the following questions via CULearn by 2:30 PM on ~~Wednesday~~, November 7, 2018. There are 20 points in 11 questions.		Please submit the answers to the following questions via CULearn by 2:30 PM on Friday, November 9, 2018. There are 20 points in 11 questions.

	Submit your answers as a single text file named "<username>-comp3000-assign3.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 3", your name, student number, and the date of submission. You may wish to format your answers in Markdown to improve their appearance.		Submit your answers as a single text file named "<username>-comp3000-assign3.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 3", your name, student number, and the date of submission. You may wish to format your answers in Markdown to improve their appearance.