jesperrosenkilde:reducingsyscalloverhead

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
jesperrosenkilde:reducingsyscalloverhead [2022/10/06 00:58] – Move to personal namespace KubilayKocakjesperrosenkilde:reducingsyscalloverhead [2022/10/06 01:00] (current) – Add Category: GsoC, move footnote to intro KubilayKocak
Line 1: Line 1:
 ===== Avoiding syscall Overhead ===== ===== Avoiding syscall Overhead =====
 +
 +This project is for the 2007 Google Summer of Code. [[/JesperRosenkilde|JesperRosenkilde]] will be working on it with [[/JeffRoberson|JeffRoberson]] as mentor.
  
 ==== Synopsis ==== ==== Synopsis ====
 +
 At the moment the setproctitle call is implemented with a sysctl, this has the unfortunate side effect that this simple call locks the Giant-lock. As this call is a simple matter of setting a value, it could be better implemented with shared memory between the kernel and  user-space. At the moment the setproctitle call is implemented with a sysctl, this has the unfortunate side effect that this simple call locks the Giant-lock. As this call is a simple matter of setting a value, it could be better implemented with shared memory between the kernel and  user-space.
  
 ==== Project ==== ==== Project ====
 +
 This project purposes a scheme to securely share process specific data, between the kernel and a user-space process. This is done by having each process allocate a special memory page, on which the kernel and user-space process can share data. This will give the security needed, as the VM-system will make sure that no outside processes can fiddle with a process' data. As everything is going on it user-space, there is no concern about a rogue process could write inside the kernel memory. There is still a locking concern, which will be addressed either by locking the entire page, or micro-locking each data field on the page. To test the scheme, I will implement the setproctitle call with share memory as oppose to the current syscall version. This project purposes a scheme to securely share process specific data, between the kernel and a user-space process. This is done by having each process allocate a special memory page, on which the kernel and user-space process can share data. This will give the security needed, as the VM-system will make sure that no outside processes can fiddle with a process' data. As everything is going on it user-space, there is no concern about a rogue process could write inside the kernel memory. There is still a locking concern, which will be addressed either by locking the entire page, or micro-locking each data field on the page. To test the scheme, I will implement the setproctitle call with share memory as oppose to the current syscall version.
  
-//Update: Howard Su has sugested a a multi page scheme, where a read/write page is used for things like get/setproctitle and a read-only page for things like getpid. And maybe a system wide read-only page for things like getdomain, gethostname etc. More on this to follow.//+//Update: Howard Su has suggested a a multi page scheme, where a read/write page is used for things like get/setproctitle and a read-only page for things like getpid. And maybe a system wide read-only page for things like getdomain, gethostname etc. More on this to follow.//
  
 ==== Milestone ==== ==== Milestone ====
 +
 This is a list of milestone, and the order in which I will take them. This is a list of milestone, and the order in which I will take them.
  
Line 31: Line 36:
 All weeks included. All weeks included.
  
-%%-%%-- 
 ==== Patch/Source ==== ==== Patch/Source ====
-This should add a working getpid() through the page-scheme. A page is allocated on fork() and exec() and its address is accesible through the kern.usrsysshm sysctl. There is a struct on the page which is hold the pid, the pid is set from the kernel, and is accessible directly from the user process' vmspace.+ 
 +This should add a working getpid() through the page-scheme. A page is allocated on fork() and exec() and its address is accessible through the kern.usrsysshm sysctl. There is a struct on the page which is hold the pid, the pid is set from the kernel, and is accessible directly from the user process' vmspace.
  
 http://www.cs.aau.dk/~jbr/patch.diff http://www.cs.aau.dk/~jbr/patch.diff
Line 40: Line 45:
 ---- ----
  
-//This project is for the 2007 Google Summer of Code. [[/JesperRosenkilde|Jesper B. Rosenkilde]] will be working on it with Jeff Roberson as mentor//+{{tag>Gsoc}}
  
  • jesperrosenkilde/reducingsyscalloverhead.1665017939.txt.gz
  • Last modified: 2022/10/06 00:58
  • by KubilayKocak