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.
Related
I need to implement a multitasking system with MPU for ARM Cortex M3/M4 processors.
In that system, there will be a Kernel which manages resource in Privileged mode and user applications in Unprivilege mode. And I want to seperate User Application from rest of it and system resources.
Therefore, when I switch to a new task, I am releasing Stack and Global Memory area of user application.
It can be done easily using ARM Cortex MPU registers.
But problem is that, when a context switching is occurred, I need to use also some global variables of Kernel.
For example, I am calling a function to get next TCB in PendSV Handler during context switching but task pool is out of user app area and it is protected from user application.
So, it seems there should be balance, right? What are the secure and efficient strategies for memory protection?
Privilieged mode can be raised before context switching when Yield function is called but it does not seem a good solution.
What are the general strategies on that issue?
Perhaps you might take a look at an existing open source implementation and see what design decisions were made there. FreeRTOS for example has Cortex-M MPU support here; it may not answer your exact question directly and you may have to inspect the source code to get complete details.
Possibly divide the data memory into three regions - user, kernel and shared.
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.
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 have these options in my homework. I will explain my reason and I hope someone can critique them?
Indicate whether the following CPU instructions are the user-only or the O/S only or both?
Execution of 'sleep' instruction that halts CPU execution
user-only because I've only seen programmers writing sleep
Loading the 'program counter' PC register with a new memory address
I think it's O/S only.
Reading of disk controller register
O/S only.
'trap' that generates interrupt
From what I understand trap is usually a user-program fault and since O/S is a software application, so probably BOTH
Loading of alarm timeout value into clock register
O/S only
Reading the processor status word PSW register
O/S only.
Loading the memory lower bounds register
O/S only
Adding the contents of two memory locations
both. O/S needs to do computation too.
I don't really understand how to make a distinction between user and O/S specific instructions. They are all essentially "user" programs..
Can someone verify these answers, tell me why I am wrong, and how to tackle these questions?
I don't really understand how to make a distinction between user and O/S specific instructions. They are all essentially "user" programs.
Here's the difference: Did you start a task to have that happen, or did it happen on its own?
Did you start a task to read from the hard drive, or did you merely instruct the OS to do so? (all device access is an OS instruction, for the most part)
Sometimes professors want you to say that "reading the hard drive is user initiated" but "preemptive multitasking by the OS is always OS initiated" or "user actions may remain in a limited state while waiting on a device to finish responding and the OS to return control in a pre-emptive multitasking OS"
These are how I interpret the answers, but if you can't find these answers in the coursework then adopting my answers won't help you any. Notice that I gave a short blurb after each to explain why I chose these things. I am not your professor and have no way to know what he/she intends, so be sure that you can understand my responses. Also, having programmed in ASM helps to answer some of these ...
Execution of 'sleep' instruction that halts CPU execution
O/S. Sleep is actually just a counter that says to skip execution for one or more cycles, and is most often modeled by an API call. This can allow the scheduler access to delay reloading the pre-empted task until many rounds later. Once again, many very basic platforms would require a NOP loop counter to even come close to emulating a sleep command.
Loading the 'program counter' PC register with a new memory address
O/S. The Program Counter register is intended to be used by the system to keep track of the current execution of a program, and during multi-process pre-emption may be used to save the current execution point of the program.
Reading of disk controller register
O/S. In general User commands do not interface the disk subsystem, although on older systems they may be accessed, often by direct register access. In more modern systems, the disk is accessed only by the O/S, and is only accessed by the User via API.
'trap' that generates interrupt
User, O/S. This is when we generate a request for the O/S to handle a situation for us, so we give up control to the internal kernel. It can also result in something returning a faulted condition.
Loading of alarm timeout value into clock register
O/S. These timers are often regarded as having system-only level access, as they are used to monitor the rest of the system. Will be generally protected in CPUs that support such protection (such as those that support ring-level execution prevention).
Reading the processor status word PSW register
User, O/S. Notably the PSW registers are system-level controlled ONLY. On rare occasion one may find a system which allows one, two or merely some of the PSW registers to be read by a user. Since these are status fields for program execution, they aren't normally required to be user readable.
Loading the memory lower bounds register
User, O/S. All memory register assignment is done through CPU commands which are directly received from the binary executable loaded into the CPUs registers. There are no restrictions (aside from changing execution ring level, in participating processors) which are particularly prevented from happening at the application level. Some device interaction may or may not be permitted, and often registers are how devices are interacted with on older hardware. Note that the base memory address may not be 0, and the O/S may intercept memory calls specifically to sandbox the application.
Adding the contents of two memory locations
User, O/S. This is a fundamental requirement of algorithm design, and is often one of the first and most basic commands designed into a CPU unit.
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.