Protected Memory - how?

[CTho9305]

How does protected memory work? In order to protect memory, you must first set up some sort of permission flag in the given page/segment. Now, when you yield and the next thread is on the CPU, what prevents it from writing in your memory space?

The processor must know that the "current" thread is not in fact you. How is this implemented? You could have some area in the processor which stores the current PID, and that would (I assume) most likely be set by the kernel/task scheduler. But how does the processor know when the kernel/task scheduler is running? What is to prevent the current thread from writing over that and claiming to have privileges?

Basically, I guess I'm asking how a process "authenticates" itself when it wants to write somewhere.

 

[Sohcan]

There's a number of different methods to support memory protection, either using hardware or software: linker-loaders, relocation, protection codes, base/limit registers....

These days, the hardware approach of virtual addressing and memory management is most often used. All addresses generated by the CPU are virtual addresses, and are translated by the MMU into physical addresses, thus guaranteeing the mutual exlusion of address space between processes. I believe that the technique most often used is that each process is assigned base and limit address values, which are stored in those respective registers on the CPU. If a process tries to read or write outside of that address range, it throws an exception.



<< how does the processor know when the kernel/task scheduler is running? >>

The CPU (just like the OS) has two modes, user and kernel. When you're in kernel mode, you have complete access to all hardware instructions and address ranges, whereas user mode is limited a smaller set of instructions and the process's address space. The TRAP hardware instruction can switch modes on the CPU...the state goes from user -> kernel on an interrupt (timer or IO), exception, or a system call. System calls are routines that run in kernel mode that do process, file, and other management procedures.

When a new process is scheduled on the CPU, all the state information of that process is saved: the general purpose registers, the base and limit registers, the program counter, etc. All of the state information of the new process is loaded, the CPU is set back to user mode, and the process begins executing at the address in the PC.

In order for processes to share memory, you have to use interprocess communication, which is mediated by the OS...you can use direct or indirect naming, synchronous or asynchronous communication, automatic or explicit buffering, send-by-copy or send-by-reference, etc, etc....

So as you can see, memory and process protection is guaranteed in hardware with virtual addressing and user/kernel modes, but its effectiveness is still determined by how well the OSs code adheres to these methods.

BTW, threads have their own stack, registers, and PC, but they share the data and address space of their parent process.

 

[CTho9305]

Alrighty.... so now how does the processor enter/leave kernel mode? Could any thread "move itself" into kernel mode somehow?

 

[Sohcan]

<< so now how does the processor enter/leave kernel mode >>

At the lowest level, there has to be hardware support. The actual implementation depends on the ISA, but there has to be a specific hardware instruction that enters and leaves the kernel mode as well as specific address where the kernel space starts (IIRC for MIPS it's the TRAP instruction and the OP_SYSCALL address).

The user thread doesn't specifically call the TRAP instruction, since it's only available to libraries and kernel processes. There are although three ways a thread can call the kernel mode:
1. On an interrupt: this happens on an event such as a timer interrupt or an I/O interrupt. If, for example, a running process wants to access the disk, it generates a disk interrupt, which causes the OS to call a library (a system call, more on this later), which switches the processor to kernel mode. Then the CPU can look at the interrupt number (aka IRQ), and using the interrupt vector, determine which address to jump to in the OS code in order to handle that specific interrupt (in this case, a disk interrupt). A modern system would use DMA, in which the CPU would set up the disk request and let the disk directly access memory; meanwhile, the OS would remove the current process A off the CPU, and schedule a new process B. When the process A finishes its disk access, it will throw another interrupt (which puts the OS and CPU back into kernel mode), at which time (based on the CPU scheduling method) can put process A back on to the CPU or insert process A into a ready queue.

2. On an exception: If a process throws an exception (such as divide by zero), the OS switches context and runs a handler to determine what to do with the exception.

3. On a system call: system calls are OS specific procedures that make the programmer's job much much easier. They handle things like creating and managing processes, reading to and from the disk, file system management, etc. Since interfacing with a hard disk requires a lot of esoteric knowledge about interface-specific I/O commands and such, the OS designers instead write the system calls (such as read() and write() in POSIX) and thus hide the hardware interface from the programmer. When a processes calls a system call, it usually accesses a library first, which executes the TRAP instruction, and jumps to the appropriate kernel address to execute the system call.

So ideally, a user process should never be running in kernel mode; that's only available to OS code to handle the three events described above. A poorly coded OS may forget, for example, to switch back to user mode after it schedules a new process on the CPU, but that would be very, very bad.

 

[CTho9305]

what prevents an application from doing the same things the kernel code does? are bits and bytes not equal?

ah, at least now I understand DMA