Making the WRONG choices.. is it viable?

[ar5007eg]

I wanna do something different, making use of x86 features that seems very nice to me!, but aren't used by major OSes, by (maybe) most of the people here, and even not implemented by some VMs. So here are some features I'd like my kernel to have:

-No paging. Memory protection achievable by segmentation only (I'm tempted by "making every buffer overflow catchable" idea).
-Hardware Task Switching (I guess it makes sense when using segmentation and I wanna use this part of silicon that few seems to be using fully)
-Kernel is ring 0. Tasks can be ring 1, 2 or 3.
-Modular design with a minimal kernel, but don't know if could be called a microkernel, since the idea initially is making the kernel give no IPC mekans apart from shared memory.
-Initially, on top of DOS, allowing me to go back to real mode and call int 21 to perform some low level stuff (like harddrive IO), as a placeholder.

The kernel would just be able to:

-Allocate Memory.

-Creating a new task.
A loader (which maybe can be a separated task) must be able to load some sort of binary format (like aout)
having unresolved external references like
"keyboard_read", which then is translated to a inter task call (using taskgates or something, I don't know yet)
registered in the kernel.

-Associating a task service (just a pointer in its code seg) to a symbol.
So a keyboard driver could associate its keyboard (user-)read key function with a symbol, like "keyboard_read".

-Associating a task int handler (just a pointer in its code seg) to an interrupt.
So a keyboard driver could associate its function to handle a physical keypress to the keyboard's int.

-Shared memory requests


So, I know there are several drawbacks and the maybe one of the biggest is having to stick with assembly for kernel and user programs.
But besides that, is there something really not recommended/possible with that idea?

[NickJohnson]

Memory protection achievable by segmentation only (I'm tempted by "making every buffer overflow catchable" idea).

Even if you were to use segmentation to bound every object you're trying to access (which would kill performance and be a pain to manage) you still wouldn't be able to catch buffer overflows on the stack, which is where they are dangerous in the first place.

-Hardware Task Switching (I guess it makes sense when using segmentation and I wanna use this part of silicon that few seems to be using fully)

Hardware task switching is implemented in microcode nowadays, and is much less efficient than software task switching. There also isn't anything you can do with hardware task switching that you can't do with software.

-Initially, on top of DOS, allowing me to go back to real mode and call int 21 to perform some low level stuff (like harddrive IO), as a placeholder.

You don't want to switch back to real mode. There's a processor feature called VM86 that exists for that purpose. It's not hard to implement either.

[iansjack]

Even if you were to use segmentation to bound every object you're trying to access (which would kill performance and be a pain to manage) you still wouldn't be able to catch buffer overflows on the stack, which is where they are dangerous in the first place.

That's one of the big advantages of paging, IMO. You can place the stack(s) so far away from other memory that an overflow is not going to trash anything. And you can start with a small stack and easily let it grow if necessary. Also, you don't have to figure out free addresses for multiple stacks for multiple tasks - they can all use the same addresses.

Also, I'm a fan of 64-bit processing (all those nice extra registers), where the choice is already made for you.

[ar5007eg]

Even if you were to use segmentation to bound every object you're trying to access (which would kill performance and be a pain to manage) you still wouldn't be able to catch buffer overflows on the stack, which is where they are dangerous in the first place.

Well, I don't have anything to do with the way the user handle the perfectly non-overflowable memory I give to him . I mean if he chooses to allocate 1024 bytes and use it as two separated 512 bytes arrays, there's nothing to be done. In the same way, if he stores a buffer in the stack, he's at his own. The difference is that he would have the choice to, instead, use a global buffer instead or, if the function is reentrant, to allocate and free it at each function call. There would be a trade-off of safety/performance (which would not be very good already, so...).

[NickJohnson]

Even if you were to use segmentation to bound every object you're trying to access (which would kill performance and be a pain to manage) you still wouldn't be able to catch buffer overflows on the stack, which is where they are dangerous in the first place.

That's one of the big advantages of paging, IMO. You can place the stack(s) so far away from other memory that an overflow is not going to trash anything.

I'm not talking about flowing over the stack and onto something else. The danger of buffer overflows on the stack is that they can modify control information (stored stack pointer, stored instruction pointer) which can in turn trash anything. If the person causing the overflow is malicious, a buffer overflow can allow complete control of the executable.

[Mikemk]

This sounds like an outdated, insecure (Is insecure saying anything?), and really technical version of android.

[brain]

last i read, hardware task switching only works on x86 32 bit, so you'll be tying yourself to an obsolete platform making it very hard to port to 64-bit...

[ar5007eg]

last i read, hardware task switching only works on x86 32 bit, so you'll be tying yourself to an obsolete platform making it very hard to port to 64-bit...

For sure. Even if I don't use hardware task switching, using non trivial segments doesn't seem to stack very well with long mode, although I still can't find which instructions actually assume a flat memory model.

But anyway, it's 2013 and there's still support for 8086 systems in current processors. I bet by the time I'm dead, Intel will still be making 32-bit compatible processors

[Combuster]

I still can't find which instructions actually assume a flat memory model.

The opcodes are: cc, gcc, g++, cl, pcc, and probably a few more nobody in their sane mind uses.

[Brendan]

Hi,

For sure. Even if I don't use hardware task switching, using non trivial segments doesn't seem to stack very well with long mode, although I still can't find which instructions actually assume a flat memory model.

That's because the difference is in the way CPUs handle segmentation and not in the instructions themselves. Basically, in long mode you can run 16-bit code, 32-bit code or 64-bit code; and in 64-bit code the CPU ignores the base and limit for most segments (everything except FS and GS).

But anyway, it's 2013 and there's still support for 8086 systems in current processors. I bet by the time I'm dead, Intel will still be making 32-bit compatible processors

Even if Intel and AMD stop making 32-bit CPUs and also stop making CPUs that support protected mode; an OS designed for long mode can run 32-bit processes that still use segmentation. In the same way, you could probably dig up Marilyn Monroe's corpse and take it on a date and pretend to develop a meaningful relationship. Of course just because something is still technically possible doesn't mean it's not pointlessly retarded.


Cheers,

Brendan