I think that i get what system programs are, but i would like to understand why exactly they are executed partly in User mode and partly in Kernel mode.
Since computer software designed to provide services to other software, i thought that they may run entirely in kernel mode. In what casses they run in user mode?
the kernel mode and user mode level exists to prevent user software from damaging the system and its features.
how the user mode performs low level instructions?
ans - using system calls
a user-mode program can switch into kernel mode,but have no control over the instructions which will be performed in kernel mode.
so the only way this could happen is using system call, which interface used by User Mode to talk with low level resources (hardware).
The only exception is when a process uses ''ioperm'' system call. In this case a device can be accessed directly by
User Mode process (IRQs cannot be used).
during the process ,
The user-mode program places values in registers, or creates a stack frame with arguments,
to indicate what specific service it requires from the operating system. then performs the trap instruction.
Immediately, the CPU switches to kernel mode, and jumps to instructions at a fixed location in memory.
trap instruction or system call handler, read the details of the requested service + arguments, and then
perform this request in kernel mode.
finally With the system call done, the operating system resets the mode
to user-mode and returns from the system call.
Related
I'm new to RISC-V and operating system developing, and I'm now trying to make a simple hypervisor-like interface in RISC-V. What stops me right now is that I have no idea about how to trigger a machine call (like RISC-SBI) which stands in firmware level and machine-mode for a user-mode applications? Since recently user-level applications communicate with kernel by system calls. However I may have to make the call skip the kernel and directly to the firmware. How to achieve this for a high-levl application?
I' really in a difficult time. So much thanks for your replies.
To make a system call, load register a0 with which call you want to make (and possibly arguments to the syscall in other registers), then execute an ecall instruction with 01 in func3, which specifies Supervisor mode. To return to user mode after executing the system call code, the OS kernel executes an sret instruction, which returns to User mode from Supervisor mode. This is documented in the Privileged Architecture specification, but I'll admit it requires a bit of knowledge ahead of time to figure out where to look.
I would appreciate help with determining which of the following operations should be performed/done only in the kernel mode. I tried finding the answer in Silberschatz "Operating System Concepts" but it is still unclear to me.
Here is the list of operations to decide whether they should be done in the kernel mode or the user mode:
(1) disable interrupts detection
(2) clear memory
(3) switch from the user mode to the kernel mode
(4) read the state of the clock/timer
(5) determine/program timer.
It is just common sense:
Disabling interrupts shouldn't happen in an unprivileged context, so normally you don't allow that.
Clearing memory in itself isn't a privileged operation, so it can happen in either context (if memory is "freed", then you have to decide if the contents are sensitive or not before allowing access from any other context, but always clearing the contents is a safe bet).
Switch from user mode to kernel mode obviously can only happen in user mode.
Reading a clock: if we're talking about hardware clocks, if it provides memory-mapped registers, then you can access it safely from user mode, as long as the mapped region has nothing sensitive (it may or may not, depends on the hardware). If just software you can do anything.
Programming a timer may happen on either context depending on the implementation, for example: real-time scheduled contexts may implement timers entirely in user mode without trouble, either by programming a hardware timer and interrupt routing (the later only needs to happen once even if it requires kernel-mode) or implementing it all in software. If not real-time, programming entirely in user space may still possible, but the implementation will require a kernel-side helper (i.e. a real-time task or an interrupt) to trigger the event.
In a class the prof said "an [assembly] instruction knows if it's running in privileged or user mode because if a trap is produced then it's user mode".
First off I assume it can't be any trap but a specific trap saying that the command cannot be run in user mode.
Second, this seems awfully inefficient: run the whole command and check if there was a trap. Why isn't there a flag set or something? Isn't this like saying if it didn't work then we know there's a problem? So there really is no way to check?
This depends on your platform (i.e. ARM, x86 etc...). I work primarily with ARM so my answer might be ARM specific but I've kept it as generic as possible.
Usually, the CPU keeps track of what processor mode it is in and each instruction is checked as it is being executed. This is done in hardware and not in software so you don't worry about whether it is efficient (leave that to the hardware developers).
If the instruction is trapped by the hardware because there isn't sufficient privileges, the CPU usually starts executing at a set location in a privileged mode. This set location is a trap handler which is usually in the kernel. The trap handler then gathers some information about what caused the trap and handles it appropriately.
I'm not quite understanding one sentence from WIKI about the System Call "The operating system executes at the highest level of privilege, and allows applications to request services via system calls, which are often executed via interrupts; an interrupt automatically puts the CPU into some required privilege level, and then passes control to the kernel, which determines whether the calling program should be granted the requested service."
How physically can an CPU be put into a certain privilege level and what does it mean by passing the control to kernel? Please explain these in the CPU-registers level.
This is an excellent question and privilege levels are one of the most beautiful concepts of Operating Systems.
This forum however is not the right place to ask.
However since you've asked, I'll paint you a general picture. Now you know that the OS does a lot of scheduling of processes. The scheduler must be called at periodic intervals. The CPU maintains a counter which causes a Timer interrupt.
The code which handles the Timer interrupt calls the scheduler. Now during scheduling OS level data structures are modified (process queues, etc.). At this point, if the user program were to be active for some reason, it can mess with those data structures leading to a crash.
This is handled via privilege levels. So, during scheduling, the CPU is said to be in a privilege mode - the kernel mode. The user programs can't access the CPU now.
Here comes the awesome part now. If suppose this switch in privilege level was to be made by the software, if there was a command, it could potentially be exploited by malicious user programs.
For this reason, we can't rely on the software to do the switch. We need hardware support.
The hardware is designed so that receiving interrupts sets the "privilege bit register". When the interrupt code is finished (scheduling is done), the return causes the hardware to clear the bit.
The interrupt handling code is located in a protected area in the memory reserved for OS code. User programs can't access this code (If it tries to access that part of the memory, an exception is thrown by the hardware).
Thus sanity is preserved.
I was just wondering whether the switch between the kernel mode and the user mode in an operating system is done by the hardware or the os itself.
I understand that when a user process wants to get into kernel mode it can make a system call and execute some kernel code. When the system call is made, the process goes into the kernel mode and now all memory becomes accessible, etc. In order for this to happen, I would assume that the interrupt handler needs to switch or alter the page table. Is this true? If not, how does the CPU know, that it is running in the kernel mode and does not need to page fault when accessing restricted (unaccessible to the user process) memory?
Thanks!
The last answer is actually not true....
Changing to kernel mode doesn't go through 'Real mode'. Actually after finishing the boot process, the computer never goes back to real mode.
In normal x86 systems, changing to kernel mode involves calling 'sysenter' (after setting parameters in some registers), which causes jumping a predefined address (saved in the MISR register of the CPU), that was set when the computer booted, because it can be done only from kernel mode (it is a 'privileged' command).
So it basically involves executing a software command, that the hardware responds to, by the way it was set, when it was in kernel mode
This is kind of a broad question - each hardware platform is going to do things slightly differently, but I think the basic answer is that it's done w/ software that leverages hardware facilities for memory protection, etc.
When a user process wants to do a system call, it executes a special CPU instruction, and the CPU switches from virtual mode (for user processes, has page tables specific to processes) to real mode (for the kernel) and jumps to the OS syscall handler. The kernel can then do what it likes.
CPU support for this is required. The CPU keeps track of which mode it is in, where the page tables are located, jumping the instruction pointer, etc. It is triggered by the user software doing the syscall, and is dependent on the kernel providing support for whatever it is trying to do. As with all computation, it's always both hardware and software. I cannot be done solely with software however, because then there would be no way to prevent a process making a syscall from abusing the privelages it gains, e.g. it could start reading /etc/shadow.
Modern x86 computers have a special instruction just for doing system calls. Earlier x86 processors, and some current RISC ones, have an instruction to trigger an interrupt. Older architecures had other ways of switching control.