OSDev.org

In 80x86 computer, programs often use call stack to store local data. This lead to some cases when programs accidentally or intentionally modify the return pointer.

Therefore, my suggestion is: A program should refrain from using hardware call stack to store local data, instead, it should use a private software based stack for that purpose. That is, a thread (or execution flow) having double stacks.

But IA-32 has a limited usable register set, so using double stack can have negative impact on performance. Have anyone thought about (or implemented) this idea?

X86-32 is obsolete, and x86-64 has page flags that will prevent execution because of say stack overflows. But otherwise I see no reason why you would limit the application that is running in its own address space to refrain from modifying the stack pointer

Hi,

Congdm wrote:Therefore, my suggestion is: A program should refrain from using hardware call stack to store local data, instead, it should use a private software based stack for that purpose. That is, a thread (or execution flow) having double stacks.

This is actually a very old idea (e.g. at least as old as Forth).

Unfortunately it doesn't actually help much. If you've got something like a buffer overflow; then it doesn't matter much if someone uses it to change a return address, or uses it to change a function pointer, or uses it to change data (e.g. a password, a client IP address or whatever), or just uses it to cause "denial of service".

Basically, it fixes symptoms of the problem without doing anything to fix the true cause of the problem.


Cheers,

Brendan

I would say that this made it far more difficult to keep track of stack frames during nested function calls. Having the data on the same stack as the return address makes this far more natural. User programs already use a separate stack from the kernel, and each has its own stack, so I'm not sure there is anything much to be gained from your suggestion.

Brendan wrote:This is actually a very old idea (e.g. at least as old as Forth).

Yeah, I bet someone had thought about and implemented this idea, but I didn't know it was Forth.

Brendan wrote:Basically, it fixes symptoms of the problem without doing anything to fix the true cause of the problem.

The root of problem is from human (bad designers, bad programmers, malicious attackers, users that aren't careful, etc), not from the machine itself and no one can fix this problem (human, just like everything in the world, aren't perfect).

It doesn't help much, but maybe it help a little?

Congdm wrote:The root of problem is from human (bad designers, bad programmers, malicious attackers, users that aren't careful, etc), not from the machine itself and no one can fix this problem

Which is why managed languages do not exist.

Granted, they don't solve crashes caused by bugs or exploits over failing logic, but it completely solves the problem of code injection.

Also, if you really need perfection, there's always that monster called Hoare Logic. Make sure you get some painkillers before you try.

AFAIK I can inject code into .net runtime at runtime