Originally posted by xfcemint
View Post
There is a catch there is a repeating set of issues that turn up.
To be correct there is a direct conflict.
1)Core drivers need physical memory access.
2) Non driver application never need physical memory access virtual memory that you can use any security control you like with will do.
Do note that sinepgib said that /dev/mem is a really bad idea. Having all drivers in userspace means you have to implement this really bad idea of /dev/mem hopefully better.
QNX, Samsung in 2012 with Linux and many others end up with physical memory that basically access anything exposed to userspace.
The monolithic split of drivers in ring 0 and userspace applications in ring 3. In a correctly setup of monolithic you don't end up randomly giving user space application direct physical memory access as that is restricted to code in kernel space.ring 0.
Historic examples of microkernels had the core kernel on ring 0 with drivers on ring 1 with services on ring 2 and userspace on ring 3. Context switching between all those rings was highly expensive on performance. This did reduce the memory assignment problem.
Windows NT was meant to be a microkernel but where are its drivers and services related to drivers in ring 0 these days.
Something you missed I have given a list of specific issues from different solutions that are in fact a single problem that keeps on turning up with userspace drivers. There are practical problems you have to get over when you write drivers.
Remember driver need to communicate with the hardware and userspace. Lets say you have raw physical memory access in the driver in userspace so it need to work. What this is mapped into user space and you are going to need to be sharing memory with application in userspace how close are you to screwing up at this point.
The monolithic ring split between "driver/kernel services" and "userspace application" is happens to make sense on a security ground. Microkernel split being kernel/userspace makes sense on a simpler kernel but it then bundling drivers and general application with each other.
Reality here microkernel and monolithic kernel neither is 100 percent right.
The historic secure design of microkernel.
Ring 0 : Kernel
Ring 1 : Drivers
Ring 2 : Servers
Ring 3 : Userspace programs
Yes this historic design ring 3 userspace programs would only interface with servers. ring 2 Servers would interface with drivers userspace and kernel. and drivers would interface with hardware and kernel and servers. The servers was barrier between driver developer created issues leaking to userspace applications.
Remember every ring change is like context switch. Lots of overahead is the reason why don't have operating systems design like this.
Monolithic kernel takes ring 0 1 and 2 of the historic secure design microcode and fuses all that into ring 0. Modern performant Microkernel takes ring 1 2 and 3 and fuses that all into ring 3. Each way you have instantly degraded the security of the historic secure microkernel designs.
xfcemint get it yet Microkernel is not all the same thing.
The 286 and latter x86 processors was designed to have 4 rings to suite being used for secure microkernel. There are repeating issues with Microkernels caused by solving the Microkernel performance problem. Why because every time a Microkernel developer solves the performance problem they under mine what would have been natural security of the Microkernel design.
Yes having drivers and servers for hardware in ring 0 as monolithic kernel does has danger. Problem is putting drivers and servers all in userspace then having to provide them with the access they need to work also has it dangers yes these dangers are just as bad as the monolithic kernel problem if not worse. This is why over and over again monolithic and microkernels in real world examples have end up just as security flawed.
There are lot of papers written saying microkernel can solve X/Y and Z problems but these brush over for the microkernel to perform you have undermined security in another way. Also those paper nicely ignore that the split line monolithic kernel has happens to have a valid security reason to be there.
Making a high performing micro-kernel and high security microkenrel at the same time from the microkernels developed so far seams like impossible task.
Leave a comment: