I am aware of the difference between a process running in user mode and one running in kernel mode (based on access restrictions, access to hardware etc.). But just out of curiosity, what is the difference between a process running in kernel mode and one running as root?
kernel mode and root are two separate ideas that aren't really related to each other. The concept of running a process as root is a unix/linux term that means you're logged in as the administrator of the system.
Any process you run, whether as root or a normal user, generally runs in both user mode and kernel mode. The system is continually switching between user mode (where the application code runs) and kernel mode (where the kernel code runs).
Some programs, like many device drivers, always run in kernel mode, meaning they have full access to the hardware. A normal application running with root privileges still exists in user mode and only switches to kernel mode when a kernel system call is made and then switches right back to user mode.
Related
When a process makes a system call, the CPU will be switched to kernel mode, and the process will be blocked (because if the process is not blocked, then it can execute privileged instructions when the CPU becomes in kernel mode).
But shouldn't all processes also get blocked? because what if when the CPU is switched to kernel mode, some other process execute a privileged instruction (for example: hlt)?
Kernel or user mode is a per-CPU attribute, that is at the same moment one CPU may be in kernel mode while another CPU - in user mode.
As you can see, nothing prevents another CPU from executing a process: privileged instructions are still prohibited on it.
I understand that an Operating System forces security policies on users when they use the system and filesystem via the System Calls supplied by stated OS.
Is it possible to circumvent this security by implementing your own hardware instructions instead of making use of the supplied System Call Interface of the OS? Even writing a single bit to a file where you normally have no access to would be enough.
First, for simplicity, I'm considering the OS and Kernel are the same thing.
A CPU can be in different modes when executing code.
Lets say a hypothetical CPU has just two modes of execution (Supervisor and User)
When in Supervisor mode, you are allowed to execute any instructions, and you have full access to the hardware resources.
When in User mode, there is subset of instructions you don't have access to, such has instructions to deal with hardware or change the CPU mode. Trying to execute one of those instructions will cause the OS to be notified your application is misbehaving, and it will be terminated. This notification is done through interrupts. Also, when in User mode, you will only have access to a portion of the memory, so your application can't even touch memory it is not supposed to.
Now, the trick for this to work is that while in Supervisor Mode, you can switch to User Mode, since it's a less privileged mode, but while in User Mode, you can't go back to Supervisor Mode, since the instructions for that are not permitted anymore.
The only way to go back to Supervisor mode is through system calls, or interrupts. That enables the OS to have full control of the hardware.
A possible example how everything fits together for this hypothetical CPU:
The CPU boots in Supervisor mode
Since the CPU starts in Supervisor Mode, the first thing to run has access to the full system. This is the OS.
The OS setups the hardware anyway it wants, memory protections, etc.
The OS launches any application you want after configuring permissions for that application. Launching the application switches to User Mode.
The application is running, and only has access to the resources the OS allowed when launching it. Any access to hardware resources need to go through System Calls.
I've only explained the flow for a single application.
As a bonus to help you understand how this fits together with several applications running, a simplified view of how preemptive multitasking works:
In a real-world situation. The OS will setup an hardware timer before launching any applications.
When this timer expires, it causes the CPU to interrupt whatever it was doing (e.g: Running an application), switch to Supervisor Mode and execute code at a predetermined location, which belongs to the OS and applications don't have access to.
Since we're back into Supervisor Mode and running OS code, the OS now picks the next application to run, setups any required permissions, switches to User Mode and resumes that application.
This timer interrupts are how you get the illusion of multitasking. The OS keeps changing between applications quickly.
The bottom line here is that unless there are bugs in the OS (or the hardware design), the only way an application can go from User Mode to Supervisor Mode is through the OS itself with a System Call.
This is the mechanism I use in my hobby project (a virtual computer) https://github.com/ruifig/G4DevKit.
HW devices are connected to CPU trough bus, and CPU does use to communicate with them in/out instructions to read/write values at I/O ports (not used with current HW too much, in early age of home computers this was the common way), or a part of device memory is "mapped" into CPU address space, and CPU controls the device by writing values at defined locations in that shared memory.
All of this should be not accessible at "user level" context, where common applications are executed by OS (so application trying to write to that shared device memory would crash on illegal memory access, actually that piece of memory is usually not even mapped into user space, ie. not existing from user application point of view). Direct in/out instructions are blocked too at CPU level.
The device is controlled by the driver code, which is either run is specially configured user-level context, which has the particular ports and memory mapped (micro-kernel model, where drivers are not part of kernel, like OS MINIX). This architecture is more robust (crash in driver can't take down kernel, kernel can isolate problematic driver and restart it, or just kill it completely), but the context switches between kernel and user level are a very costly operation, so the throughput of data is hurt a bit.
Or the device drivers code runs on kernel-level (monolithic kernel model like Linux), so any vulnerability in driver code can attack the kernel directly (still not trivial, but lot more easier than trying to get tunnel out of user context trough some kernel bug). But the overall performance of I/O is better (especially with devices like graphics cards or RAID disc clusters, where the data bandwidth goes into GiBs per second). For example this is the reason why early USB drivers are such huge security risk, as they tend to be bugged a lot, so a specially crafted USB device can execute some rogue code from device in kernel-level context.
So, as Hyd already answered, under ordinary circumstances, when everything works as it should, user-level application should be not able to emit single bit outside of it's user sandbox, and suspicious behaviour outside of system calls will be either ignored, or crash the app.
If you find a way to break this rule, it's security vulnerability and those get usually patched ASAP, when the OS vendor gets notified about it.
Although some of the current problems are difficult to patch. For example "row hammering" of current DRAM chips can't be fixed at SW (OS) or CPU (configuration/firmware flash) level at all! Most of the current PC HW is vulnerable to this kind of attack.
Or in mobile world the devices are using the radiochips which are based on legacy designs, with closed source firmware developed years ago, so if you have enough resources to pay for a research on these, it's very likely you would be able to seize any particular device by fake BTS station sending malicious radio signal to the target device.
Etc... it's constant war between vendors with security researchers to patch all vulnerabilities, and hackers to find ideally zero day exploit, or at least picking up users who don't patch their devices/SW fast enough with known bugs.
Not normally. If it is possible it is because of an operating system software error. If the software error is discovered it is fixed fast as it is considered to be a software vulnerability, which equals bad news.
"System" calls execute at a higher processor level than the application: generally kernel mode (but system systems have multiple system level modes).
What you see as a "system" call is actually just a wrapper that sets up registers then triggers a Change Mode Exception of some kind (the method is system specific). The system exception hander dispatches to the appropriate system server.
You cannot just write your own function and do bad things. True, sometimes people find bugs that allow circumventing the system protections. As a general principle, you cannot access devices unless you do it through the system services.
Windows Internals, 6th Edition from Microsoft Press says that in Windows NT, each thread has 2 stacks: one used when running in user mode, and one used in kernel mode.
Why is this so? It seems that the user-mode stack could also be used while in a system call. Is there some advantage to this design?
The main reason is that the kernel mode cannot trust user mode. If the kernel used a user-mode stack, some other user mode thread could observe the values on that stack and modify them at will. It would be trivial for malware to gain complete control of the system.
In a UNIX like system, we have a user mode and a kernel mode. There are some instructions which cannot be accessed in the user mode. However when we do sudo, we can access many critical sections of our OS, perform critical actions.
My question is: When a program is executed in the sudo mode, does the whole program run in kernel mode? Or is it the case that the sudo mode is simply an administrative user whose powers are a mere subset of the operations which can be performed by the kernel?
Yes, a huge difference between sudo and kernel mode.
Kernel mode is related to CPU modes. Most processors (in particular all running a common Linux kernel, not a µCLinux one) e.g. your Intel processor inside your laptop have several modes of operation, at least two: the privileged (or supervisor) mode where all machine instructions are possible (including the most unsafe ones, like those configuring the MMU, disabling interrupts, halting the machine, doing physical I/O i.e. sending bytes on network, or to a printer or a disk) and the user mode where some machine instructions are prohibited (in particular physical I/O instructions, MMU configuration, interrupt disabling, etc...)
On Linux, only kernel code (including kernel modules) is running in kernel mode.
Everything else is in user mode.
Applications (even commands running as root) are executing in user mode, and interacting with the Linux kernel through system calls (and this is the only way for an application to interact with the kernel) listed in syscalls(2). So application code sees a "virtual machine" capable of doing syscalls and executing user-mode instructions. The kernel manage the authentication and credentials (see credentials(7) & capabilities(7) ...)
sudo is simply giving a command (using setuid techniques) the permissions for root (i.e. user id 0). Then, some more syscalls are possible... But the command (i.e. the process running that command) is still running in user mode and uses virtual memory and has its address space.
There is no such thing as sudo mode. There is only user space and kernel space.
As you said, kernel mode may execute any instruction offered by the CPU and do anything to the hardware. User mode programs may only access memory that is mapped to the running process, and they are blocked from any direct hardware access. Via the system call mechanism, a user mode program may call the kernel code, which will perform the hardware access on its behalf and return the result back into user space.
In user space, there are additional restrictions on users who are not root (root being user ID number 0). For example, they can only access certain files, and they can only listen on TCP ports numbered above 1024. Running sudo will start a process as the root user, who does not have these restrictions in force.
But processes which are run as the root user (via sudo) are still running in user space, and are still subject to all the same restrictions that implies.
I was asked this question from my friend that
when you login our logout from a Linux based system then what all
process run and in which sequence?
Being a noob in Linux and not into real system admin kind of job, so it was difficult for me to answer. Is there any particular tutorial on such concepts or can somebody explain what exactly happens while logging in or logging out from the Linux System?
Assume it is console terminal not GUI.
In Linux, the flow of control during a boot is from BIOS, to boot loader, to kernel. The kernel then starts the scheduler (to allow multi-tasking) and runs the first userland (i.e. outside kernel space) program Init (which is mostly responsible to run startup scripts for each runlevel), at which point the kernel goes idle unless called externally.
init (short for initialization) is a program for Unix-based computer operating systems that spawns all other processes. It runs as a daemon and typically has PID 1. The boot loader starts the kernel and the kernel starts init. If one were to delete init without a replacement, the system would encounter a kernel panic on the next reboot.
When init starts, it reads a file called inittab, usually located in /etc. This file tells init which programs should be run under which conditions. Not only does init run the startup scripts that bring the rest of the system up, but init also takes care of shutting the system down. Commonly, init will start a program called "getty" to spawn a new terminal (or tty), and "login" for login prompt. This configuration is set inside inittab. In recent version of linux, inittab is replaced with /etc/init/*.conf and scripts inside /etc/init.d/
On shutdown, Init is called to close down all user space functionality in a controlled manner, again via scripted directions, following which Init terminates and the Kernel executes its own shutdown.
See Linux startup process Wiki page
Login: Getty is the process which will take care of complete login process.
Init creates the getty process
getty process initiates login command
login command try to check user credentials
getty creates user shell process
getty read shell property files
getty provides you with PS1 prompt
On logout, the shell program exits and we return to step 1.
See login process at this website 1
See login process at this website 2