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?
My idea about call stack
Re: My idea about call stack
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
Re: My idea about call stack
Hi,
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
This is actually a very old idea (e.g. at least as old as Forth).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.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: My idea about call stack
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.
Re: My idea about call stack
Yeah, I bet someone had thought about and implemented this idea, but I didn't know it was Forth.Brendan wrote:This is actually a very old idea (e.g. at least as old as Forth).
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).Brendan wrote:Basically, it fixes symptoms of the problem without doing anything to fix the true cause of the problem.
It doesn't help much, but maybe it help a little?
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: My idea about call stack
Which is why managed languages do not exist.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
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.
Re: My idea about call stack
AFAIK I can inject code into .net runtime at runtime