OSDev.org

Apart from some obvious disadvantages what are some advantages if any of doing this.

PS. The OS is intended for advanced low level programmers.

Hi,

You mean running what would normally be user tasks in ring 0 instead of ring 3?

As you say - there are some obvious disadvantages which should be enough to put you off. These include:

1) Any process can use direct port IO on any port.
2) Any process can overwrite any other processes paging structures (and its own - intentionally or otherwise).
3) Any process can use memory from any physical address, including already allocated physical memory.
4) Any process can kill the kernel.

Plus all the other disadvantages you already know about.

If you want an OS which allows a large amount of system control, I would suggest you allow for this in your API. Even 'low level programmers' don't want their OS crashing all the time.

Cheers,
Adam

Operating systems without protection can be more efficient. I haven't seen any other advantage of this.

Its better to write much API functions (without the need to access HW directly in user programs) for your OS and let it run in ring 3. Yes, it's better to run programs in ring 0, but then you could leave protected mode and do in unreal mode with more ease (BIOS API etc) But of course it would had a negative impact on stability.

I'm leaning toward ring 3 now.

MTJM wrote:Operating systems without protection can be more efficient. I haven't seen any other advantage of this.

You still need to do context switching and have syscalls regardless if everything runs in ring 0.

There would be obvious performance increases if programs/drivers need access to ports since they could do this directly instead of routing through the kernel.

You could also have a weird memory allocation system whereby processes manage their own page directories and tables. Except this would be really unsecure. This reminds me of the guy who said he thought up a revolutionary memory manager where you allow processes to manage their own memory.

MessiahAndrw wrote:You still need to do context switching and have syscalls regardless if everything runs in ring 0.

You need context switching, but if there's no ring transition, then you don't need syscalls.

If you use a 64-bit address space, and give each process a chunk of it (assuming complete trust) then you don't need any switiching of contexts or system calls. This is of course the idea behind Software Isolated Processes in Singularity, however in that case the Type Checking and JIT compilation assure the trust between processes.

I wouldn't advise the running of applications in Ring 0 for a general purpose OS unless it is based upon Application VM or you can assure the trust and stability between all processes, an almost impossible task. However, if writing a system executive of some other sort, such as a boot tool, system recovery software or Freestanding Forensics enviroment then the advantages of Ring 0 are well worth any risk.

The advantages, happen to be the same as the disadvantages mentioned by AJ above, however in such a situation it's far easier to allow each tool in your Boot System full access then to work on an API to support the functionality you will write in the tools either way. Of course it's much easier to simly package your Software as a Linux application if you were ever to build such an enviroment.

Running in ring0 give you many advantages, the biggest is speed, do not believe that theres little difference, as people who say it are full of bull s**t .
Take for example games consoles, they all run in ring0.
Example here is the xbox spec

While the Xbox kernel is based on the NT/Windows 2000 kernel, it's extremely lean. There's no virtual memory paging, and only a single process is allowed (though that process can spawn multiple threads). The entire kernel fits into 150KB--far less than the 1MB original goal.
The development library is polling-based rather than event driven (unlike Windows). This was due directly to feedback from game developers.
The game owns the hardware--it runs in ring 0, and has direct access to all hardware (including CPU and graphics).
Memory allocation is the responsibility of the app--there's no front-end memory allocation.
While the APIs were familiar (Direct3D, DirectSound), the back ends were different, and highly tuned to the Xbox hardware. However, the input API is different from DirectInput on the PC.

Now if a Co like M$ take protection away, you know there must be a big difference in speed, all things being equal.
So if speed is top of your list, use ring0.

EDIT

I'd like to vote strongly against ring0 at all.
Reasons:
- most systems tend to have more that 1 CPU in the future.
- devices becoming memory mapped and aligned on 4KB limit
- you can keep CPUs in ring3 while allowing hardware interaction thru MMIO
- some ATI/AMD GPU docs that appeared few days ago on this forum seem to use MMIO

MMIO(Memory mapped IO)

One thing i would like to add, is if your making a desktop OS, you should use ring3.

Tyler wrote:If you use a 64-bit address space, and give each process a chunk of it (assuming complete trust) then you don't need any switiching of contexts or system calls.

You still need context switching if you plan to support multithreading.

Dex wrote: Take for example games consoles, they all run in ring0.
Example here is the xbox spec

Yep but that made hacking the XBox easier. Here is a presentation about XBox-Hacking(it's quite long). It's really interesting.

cyr1x wrote:

Dex wrote: Take for example games consoles, they all run in ring0.
Example here is the xbox spec

Yep but that made hacking the XBox easier. Here is a presentation about XBox-Hacking(it's quite long). It's really interesting.

If someone has that much direct access to the hardware, it doesn't make a damn bit of difference if you have your OS running in Ring 3 or not.

Microsoft realized this from their experience with the XBOX, and this is what fueled the hypervisor design for the XBOX 360.

If done correctly, an entirely Ring-0 based machine could thrive, even on desktops. Unfortunately, doing things correctly (quality) and doing things quickly (save money) are different goals within the general software market that demands quick and cheap "improving quality" solutions.