I learned that a Privileged Instruction is only executed when current privileged level(CPL) is kernel mode and if not a interrupt is occurred.
And the way to check the current CPL is looking up some mode bit in registers.
I think there should be some process that check a instruction with a mode bit using some special table. And I read this process is on decode state in an unverified blog.
It is true? If not where this process is done?
I wonder where mode bits be checked.
Privileged Instructions are defined by CPU but operating-system.It uses a different branch to run,and hardware will do it.To be honest,you should check Intel Software Developer's Manual,but internel process is not public.
Related
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 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 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.