I wanted to test out something when the process is in kernel mode. A period of 10-15 seconds completely in kernel mode should be enough.
Is there any way to force a program written in C to run in kernel mode for a while? Would a single read system call on a huge buffer do?
There is no way to force running program to run in kernel mode.
In kernel mode there are more privileges available. It means that
program could execute special instructions that it cannot execute in
user mode.
Obviously, there are no way, AFAIK, to force program in user mode to
switch to kernel mode, because it compromises security: imagine,
that every process on will could switch to user mode, malicious
code can cause disaster by altering page tables, changing CPU settings, turning off interrupts and so on.
The only valid way of "switching" to kernel mode is executing system call.
That will cause trap to the kernel and after some kernel code is executed
control will return back to user code. However, I think that is not what you
asked about.
Related
I am having a question for myself while taking operating system course.
If I type in any C code to my text editor or though IDE and execute it with the compiler
it translates the code into machine code.
Then I would guess if I run the program, the OS will allocate a memory address to the code which is done by kernel code.
And if there was IO interrupt typed into my code, the kernel code executes.
And so...which bit is the user mode code then?
In the ordinary course of events, any code you write is 'user mode code'. Kernel mode code is executed only when you execute a system call and the control jumps from your user code to the operating system.
Obviously, if you're writing kernel code, or loadable kernel modules, then things are different — that code will be kernel mode code. But most people most of the time are only writing user mode code.
Kernel mode versus user mode actually reflects how the processor is running.
With modern operating systems, code only runs (with the processor) in kernel mode if it is trusted by the operating system, and all other code runs in user mode.
The functional difference, under modern operating systems, is that kernel mode code runs in a single (virtual) address space that represents all system resources, so all functions in kernel mode can affect each other directly. For example, all actions by a kernel mode driver can directly affect functioning of the operating system itself and of any other kernel mode driver. (The specifics implementation details vary somewhat between operating system types, for example between windows, linux, BSD, etc but the basic principles are the same)
Which means that, if you are writing code that will execute within the internal workings of the operating system or within a kernel mode driver, then it might be said to be kernel mode code. Otherwise, it will be user-mode code. Code that attempts some action that can only be executed in kernel mode will be prevented from doing so by the processor itself, unless the processor itself is in kernel mode. The operating system itself mediates when the processor enters kernel mode, which is why code need to be recognised by the operating system (or installed, in the case of kernel mode drivers) in order to do things that can only be done in kernel mode. User mode code can't arbitrarily escalate the processor to kernel mode, without the help of some code that is already recognised by the operating system.
Practically, modern operating systems also supply a set of functions (e.g. in an API) that can be called from user mode. A lot of those functions are, themselves, executed solely in user mode. Some, however, result in the the processor being switched into kernel mode to perform some specific actions, and then the processor is switched back to user mode by the time control returns to the caller. Which code, within the OS itself, executes in user mode or kernel mode depends both on the design of the operating system and administrative settings (e.g. only suitably privileged users (aka administrators) can, for example, install kernel mode drivers).
Why is calling callback functions in kernel-space from user-space considered 'bad' vs calling callback functions in user-space from user-space?
Allowing the user to execute code in kernel mode would be an enormous security risk. That is to say, if a user space program is executing in kernel mode, there is no security: the game is completely lost and the user has full access to everyone and everything.
Consider that if you're executing in kernel mode, virtual memory lookups are no longer protected by privilege level. In x86, when in kernel mode, you have a privilege level of 0; meaning you can access anything in physical memory. So, if a process' callback were executing in kernel space, it would be able to do anything it wanted to literally anything on the machine.
Want to erase everybody's page tables? K. Want to instead see what's in those page tables? You got it. Want to zero out kernel memory and cause the entire system to crash? Lolz good idea. Want to hack another process on the machine so that it logs its I/O traffic? Seems legit.
Don't let the user run code in kernel space.
There are systems that support such callbacks. E.g.:
http://h41379.www4.hpe.com/doc/732final/4527/4527pro_001.html#index_x_190
In such a case, your process must have the appropriate privilege to execute in kernel mode.
Allowing code to execute in kernel mode opens the system up to crashes and security holes.
How can one print some arbitrary text on-screen without the call to any function ?
Another way of asking this question is how are i/o functions implemented ?
I tried searching in google, but unluckily, no result was found similarly to as if it was some sort of a top secret thing.
For study purposes.
I personally don't feel even close to a real programmer without knowing this.
Well, in the end, loosely speaking, the low level software in the computer sets a special memory location or uses a special instruction that changes the voltage on some pins on the CPU, and the hardware responds to these changes.
But user-level processes don't have access to those instructions or memory locations. Messing with stuff that drives the hardware is the responsibility of "device drivers" that execute in the kernel. They use these special memory locations or instructions, and each one is given responsibility over a particular hardware device.
User-level processes communicate with device drivers via system calls as mentioned in the comments. A system call is not quite like a normal function call -- you don't just call the code. After setting up a "request" for what it wants to do, the user-level process pokes the kernel, usually by using a software interrupt instruction. The kernel wakes up, looks at what you request, and then decides itself what code to execute. The kernel code runs at a higher privilege level and will call directly into the device drivers that access the hardware.
This is how the kernel keeps processes safe from each other.
To actually get from stdout to the screen is a lengthy process:
the standard library ends up making a system call that writes to a "pipe" that is attached to stdout. This is where it leaves your process.
The other end of the pipe is being read by the console. The console is a user-level process, so it has to do a system call to do the reading.
The console decides what to display, and how to make it visible to you. There will be a bunch more layers, but eventually there will be system calls into drivers that control the graphics hardware. They will mess with the bits that turn into pixels on the screen, making your text visible.
As I understood, the UNIX function read() will cause an interrupt(TRAP) and invoke the system call read. I also remembered that it has to switch to "Kernel Mode" before invoking the system call read and the switching is expensive..
I was wondering that why the read operation has to be delegated to system call in "Kernel Mode", instead of being done in "User Mode" completely.
For example, if there could be a service in "User Mode" which manages the access permissions of files, the read operation can just request this service, not disturbing the Kernel..
And for the disk driver, it is said in this link that
Device drivers can run in either user or kernel mode
Does anyone have ideas about this? Why does read have to be in Kernel Mode?
Is not the way Operating Systems are designed. The definition of OS is to handle the computers' hardware and to bring resources to their users. Operating Sysmtes also have the concept of user mode and kernel mode (as you said).
By having these concepts, OS define an specific line to what a user might do and what not. Letting them manage hardware is definitely something OS don't want users to do.
read usually involves a hardware access. Accessing hardware is cumbersome and error prone and can leave the computer in an unusable state. Operating System uses drivers to control the computer's hardware.
Issuing a read (assuming a hard disk IO) generally makes a driver to send a set of commands to the disk controller, read it's output, pass it to main memory, etc. This are dangerous operations that shouldn't be trusted to User Mode.
If there would be a service in user mode to handle this. Context switch still would be needed to be done, because the service would be running as another process.
Sure thing it can be done an Operating System that allows this. But modern operating systems aren't design to fulfill this behavior.
There are other approaches to building operating systems that relies on microkernels. A microkernel just do the minimum to get the pc started and leave everything else to other modules. Meaning that if a module crashes, the system still up. That's the case of specific drivers, filesystems, etc. I don't know if microkernels let these run in user space though.
Hope this helps!
First of all: it's no longer true that calling kernel is very expensive. It used to be when causing an exception/trap/fault/interrupt were the only way to switch from user mode to kernel mode in x86 systems, but that all changed with the addition of the systenter/sysexit machine code instructions, which perform a more lightweight transition.
Even if it is/were expensive, in terms of time consumed, system calls that deal with character and block device drivers should run in kernel mode because dealing with hardware devices involves reading and writting to hardware registers, which could be memory mapped or accessed thru I/O ports.
These registers must be protected from any access from userspace process. Not doing so may lead to any process to not to use the established API for reading a file, and directly use the hardware registers to read and write to the device. In the case of a disk with file, this would allow the userprocess to bypass the filesystem entirely, and hence, all the security and permission system.
So, if we need to protect these hardware registers so no user process can use them, code that does use them cannot run at the same priviledge level as any other user process. Hence, they run in another (more priviledged) mode, which is what is called "kernel mode".
Think on what would happen if you configure a Linux system so /dev/sda (usually the main harddisk in which the root filesystem lives) is read/write to anybody and everybody:
# chmod 666 /dev/sda
Having done this is more or less the equivalent of exposing the hard disk device to any user process. You can effectively write a program that could open, read, and write files stored within this device, but at the same time, you can write a program that open, read and write ANY files within the partition, no matter which permissions files have.
That said, there are cases in which a system runs only trusted applications. This kind of system doesn't need the level of protection that is present in a general purpose system, and hence it can benefit from the increased speed that comes by not depending on layers of APIs to isolate the process from the hardware. The most widely known example would be a videoconsole system. I recall that Windows CE used to run all its programs and device drivers at the same privilege too.
what do we mean by thread running in User mode and running in kernel mode? Is this related to thread execution instruction from User mode and thread executing instruction from Kernel mode? Kindly elaborate.
Also, is it possible that if a thread is executing in user mode is put to suspended state, then it may start executing in kernel mode? if yes, how is it possible? Until now I am only aware that a thread if suspended will be SUSPENDED completely, i.e. the context switch will take place by CPU to schedule another thread.
what do we mean by thread running in User mode and running in kernel mode?
There is no way to know what a person means by a phrase without context. If I had to guess, I'd say they are talking about whether the thread is scheduled by a user-space scheduler or a kernel scheduler. But it's also possible they are actually asking whether the thread is running user code or kernel code.
Is this related to thread execution instruction from User mode and thread executing instruction from Kernel mode? Kindly elaborate.
It could be. It also might not be. There's no way to know what a person means by a phrase without context.
Also, is it possible that if a thread is executing in user mode is put to suspended state, then it may start executing in kernel mode? if yes, how is it possible?
For implementations where the kernel schedules threads, the scheduler is running in kernel space. The code that actually suspends the thread typically runs in kernel space too because it has to add the thread to the various kernel scheduler data structures. So the thread that resumes the thread will run in kernel space too. At a higher level view, the same thread of execution can "become" the kernel scheduler, choose a user-space thread to execute, and then "become" that thread.
Until now I am only aware that a thread if suspended will be SUSPENDED completely, i.e. the context switch will take place by CPU to schedule another thread.
Right, and that's kernel code. So the same core is running user space code, then it's running kernel code, then it's running the user space code of another thread.
Modern operating systems have hardware support for separating the user code from the kernel code. On the x86 architecture you can set up memory pages that are not accessible to normal user code, and will trigger a page fault, so that the OS can survive faulty programs.
Code running in kernel mode has higher privileges, but also more responsibillities, as not everything is as easily accessible as from user space. If the user code gets stuck, then the OS can clean it up. If a kernel mode code hangs it might not be that easy, depending on how high the privilege level is.