This is an undergraduate operating systems class that requires x86 assembly language and C language basics such as data structures, stacks, queues, and pointers. I will attach pdf of the lab with...

This is an undergraduate operating systems class that requires x86 assembly language and C language basics such as data structures, stacks, queues, and pointers. I will attach pdf of the lab with instructions and the .c files which code must be written in. There is two parts Part A and Part B. Part is due on the 21/10/2022 and part B is due on 23/10/2022. All Exercises 1-10 must be done. Challenge is not required. Changes must be done to



Docs » Lab Assignments » Lab 3: User Environments Lab 3: User Environments Handed out: 09/23/2022 (Fri) Due: 10/30/2022 (Sun) 11:59pm Introduction In this lab you will implement the basic kernel facilities required to get a protected user-mode environment (i.e., "process") running. You will enhance the JOS kernel to set up the data structures to keep track of user environments, create a single user environment, load a program image into it, and start running it. You will also make the JOS kernel capable of handling any system calls the user environment makes and handling any other exceptions it causes.  Note In this lab, the terms environment and process are interchangeable -- both refer to an abstraction that allows you to run a program. We introduce the term "environment" instead of the traditional term "process" in order to stress the point that JOS environments and UNIX processes provide different interfaces, and do not provide the same semantics. Getting started Use Git to commit your changes after your Lab 2 submission (if any), fetch the latest version of the course repository, and then create a local branch called lab3 based on our lab3 branch origin/lab3 in the lab repository: https://crs.s3lab.io/cs4348/2022/fall/index.html https://crs.s3lab.io/cs4348/2022/fall/lab.html http://s3lab.utdallas.edu/cs4348/jos/-/tree/lab3 Chandrahas Nanduri $ cd ~/jos $ git add -A $ git commit -am 'changes to lab2 after handin' Created commit 734fab7: changes to lab2 after handin 4 files changed, 42 insertions(+), 9 deletions(-) $ git pull Already up-to-date. $ git remote add cs4348 ssh://[email protected]:2224/cs4348/jos.git $ git fetch cs4348 remote: Enumerating objects: 66, done. remote: Counting objects: 100% (66/66), done. remote: Compressing objects: 100% (50/50), done. remote: Total 51 (delta 12), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (51/51), 24.22 KiB | 143.00 KiB/s, done. From ssh://s3lab.utdallas.edu:2224/cs4348/jos * [new branch] lab1 -> cs4348/lab1 * [new branch] lab2 -> cs4348/lab2 * [new branch] lab3 -> cs4348/lab3 $ git checkout -b lab3 cs4348/lab3 Branch 'lab3' set up to track remote branch 'lab3' from 'cs4348'. Switched to a new branch 'lab3' $ git push -u origin lab3:lab3 Enumerating objects: 66, done. Counting objects: 100% (66/66), done. Delta compression using up to 4 threads Compressing objects: 100% (50/50), done. Writing objects: 100% (51/51), 24.24 KiB | 2.42 MiB/s, done. Total 51 (delta 12), reused 0 (delta 0), pack-reused 0 remote: remote: To create a merge request for lab3, visit: remote: http://s3lab.utdallas.edu/cxk200010/jos/-/merge_requests/new? merge_request%5Bsource_branch%5D=lab3 remote: To ssh://s3lab.utdallas.edu:2224/cxk200010/jos.git * [new branch] lab3 -> lab3 Branch 'lab3' set up to track remote branch 'lab3' from 'origin'. $ git remote rm cs4348 $ You will now need to merge the changes you made in your lab2 branch into the lab3 branch, as follows: $ git merge lab2 Auto-merging kern/pmap.c Auto-merging kern/monitor.c Auto-merging kern/kdebug.c Merge made by the 'recursive' strategy. .lab1-extra | 1 + answers-lab2.txt | 7 ++++ kern/kdebug.c | 12 ++++++- kern/monitor.c | 53 ++++++++++++++++++++++++++++ kern/monitor.h | 1 + kern/pmap.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++--- lib/printfmt.c | 10 ++++-- 7 files changed, 182 insertions(+), 8 deletions(-) create mode 100644 .lab1-extra create mode 100644 answers-lab2.txt $ Lab 3 contains a number of new source �les, which you should browse: inc/ env.h Public de�nitions for user-mode environments trap.h Public de�nitions for trap handling syscall.h Public de�nitions for system calls from user environments to the k lib.h Public de�nitions for the user-mode support library kern/ env.h Kernel-private de�nitions for user-mode environments env.c Kernel code implementing user-mode environments trap.h Kernel-private trap handling de�nitions trap.c Trap handling code trapentry.S Assembly-language trap handler entry-points syscall.h Kernel-private de�nitions for system call handling syscall.c System call implementation code lib/ Makefrag Make�le fragment to build user-mode library, obj/lib/libuser.a entry.S Assembly-language entry-point for user environments libmain.c User-mode library setup code called from entry.S syscall.c User-mode system call stub functions console.c User-mode implementations of putchar and getchar , providing exit.c User-mode implementation of exit exit.c User mode implementation of exit panic.c User-mode implementation of panic user/ * Various test programs to check Lab 3 code In addition, a number of the source �les we handed out for Lab 2 are modi�ed in Lab 3. To see the differences, you can type: $ git diff lab2 You may also want to take another look at the tools page, as it includes information on debugging user code that becomes relevant in this lab. Lab requirements This lab is divided into two parts, A and B. Part A is due at the end of the second week from the time this lab was assigned; you should commit your changes and push your lab before the Part A deadline (10/23/2022 11:59pm), even though your code may not yet pass all of the grade script tests. (If it does, great!) You only need to have all the grade script tests passing by the Part B deadline at the end of the third week (10/30/2022 11:59pm). As in Lab 2, you will need to do all of the regular exercises described in the lab and provide a write- up that brie�y answers to the questions posed in the lab in a �le called answers-lab3.txt in the top level of your lab directory. Do not forget to include the answer �le in your submission with git add answers-lab3.txt . Inline assembly In this lab you may �nd GCC's inline assembly language feature useful, although it is also possible to complete the lab without using it. At the very least, you will need to be able to understand the fragments of inline assembly language (" asm " statements) that already exist in the source code we gave you. You can �nd several sources of information on GCC inline assembly language on the reference page. Part A: User Environments and Exception Handling Due: 10/23/2022 (Sun) 11:59pm https://crs.s3lab.io/cs4348/2022/fall/lab/tools.html https://crs.s3lab.io/cs4348/2022/fall/ref.html Chandrahas Nanduri Chandrahas Nanduri Chandrahas Nanduri Chandrahas Nanduri The new header �le inc/env.h contains basic de�nitions for user environments in JOS. Read it now. The kernel uses the Env data structure to keep track of each user environment. In this lab you will initially create just one environment, but you will need to design the JOS kernel to support multiple environments; Lab 4 will take advantage of this feature by allowing a user environment to fork other environments. As you can see in kern/env.c , the kernel maintains three main global variables pertaining to environments: struct Env *envs = NULL; // All environments struct Env *curenv = NULL; // The current env static struct Env *env_free_list; // Free environment list Once JOS gets up and running, the envs pointer points to an array of Env structures representing all the environments in the system. In our design, the JOS kernel will support a maximum of NENV simultaneously active environments, although there will typically be far fewer running environments at any given time. ( NENV is a constant #define 'd in inc/env.h .) Once it is allocated, the envs array will contain a single instance of the Env data structure for each of the NENV possible environments. The JOS kernel keeps all of the inactive Env structures on the env_free_list . This design allows easy allocation and deallocation of environments, as they merely have to be added to or removed from the free list. The kernel uses the curenv symbol to keep track of the currently executing environment at any given time. During boot up, before the �rst environment is run, curenv is initially set to NULL . Environment state The Env structure is de�ned in inc/env.h as follows (although more �elds will be added in future labs): struct Env { struct Trapframe env_tf; // Saved registers struct Env *env_link; // Next free Env envid_t env_id; // Unique environment identifier envid_t env_parent_id; // env_id of this env's parent enum EnvType env_type; // Indicates special system environments unsigned env_status; // Status of the environment uint32_t env_runs; // Number of times environment has run // Address space pde_t *env_pgdir; // Kernel virtual address of page dir }; Here's what the Env �elds are for: This structure, de�ned in inc/trap.h , holds the saved register values for the environment while that environment is not running: i.e., when the kernel or a different environment is running. The kernel saves these when switching from user to kernel mode, so that the environment can later be resumed where it left off. This is a link to the next Env on the env_free_list . env_free_list points to the �rst free environment on the list. The kernel stores here a value that uniquely identi�es the environment currently using this Env structure (i.e., using this particular slot in the envs array). After a user environment terminates, the kernel may re-allocate the same Env structure to a different environment -- but the new environment will have a different env_id from the old one even though the new environment is re-using the same slot in the envs array. The kernel stores here the env_id of the environment that created this environment. In this way the environments can form a "family tree," which will be useful for making security decisions about which environments are allowed to do what to whom. env_tf: env_link: env_id: env_parent_id: env_type: This is used to distinguish special environments. For most environments, it will be ENV_TYPE_USER . We'll introduce a few more types for