Separate code segment and data segment

[bluemoon]

Since the lack of bound checks usually indicate bugs(or careless) in code, it is still debatable that Precis limit checking by hardware is an advantage, since it enforce a default action for bound check failure - close the process; if it is handled by software it can be handled with flexibility.

So the question is Precis limit checking by hardware is useful for debug / safety guard, considering the price of it, I would say in some case is it possible/better to do it with other method (VM, etc)

[Congdm]

At first, I only use one global segment for both code and data (single address space), but that make code vulnerable to buffer overrun or other errors, leading to unpredictable behaviour, so I divided it into two segments.

But after rethinking carefully, I realized it didn't solve my problem. In order to solve it, I need to utilized more x86 segmentation.

What I want to protection: Code and pointers to code. I don't care about normal data.
But x86 CPUs store the return pointer in stack when calling procedure, if I let stacks stay at data segment, the risk is still there.

Therefore, here is my memory model:
[*] One code segment, all modules stay in this segment
[*] One global data segment
[*] Each thread have one stack segment

However, a thread can still mess its own stack, so I need a more effective mechanism.

[bluemoon]

What I want to protection: Code and pointers to code. I don't care about normal data.

Did you check the execution bit on modern CPU? You can't execute a data page if that feature is enabled.

[Congdm]

Yes, I know, but for now I will only use segmentation. And what I want is to make code cannot be changed by accident, and ensure that the program will not jump to an arbitrary point, on ring 0.

[linguofreak]

Since the lack of bound checks usually indicate bugs(or careless) in code, it is still debatable that Precis limit checking by hardware is an advantage, since it enforce a default action for bound check failure - close the process; if it is handled by software it can be handled with flexibility.

All hardware limit checking does with a beyond-limits access is call an exception handler provided by the OS. That exception handler can do anything, including calling a user-space exception handler in the running program, if one is supplied by the application programmer.

[rdos]

Since the lack of bound checks usually indicate bugs(or careless) in code, it is still debatable that Precis limit checking by hardware is an advantage, since it enforce a default action for bound check failure - close the process; if it is handled by software it can be handled with flexibility.

All hardware limit checking does with a beyond-limits access is call an exception handler provided by the OS. That exception handler can do anything, including calling a user-space exception handler in the running program, if one is supplied by the application programmer.

It's up to the kernel to define what exception handlers do, so the OS has full control of that aspect. Normally, I would not let applications handle protection faults. Those are fatal issues that should terminate the application. An application cannot link the protection fault exception, and shouldn't be allowed to do this by software in the kernel either.