In fact, all those outlaws with their breaching remote machines have exploited overflow issues in code. And there is no street magic to prevent the very mechanism of those attacks.
No, there it gets easier.Unless you're on VMS, which apparently had/has the ability to deal with most buffer overflow attacks.
http://forums.freebsd.org/threads/the-techniques-to-guard-buffers-against-overflow.49208/
To realign buffers is the waste of time: it pounds performance plus if the buffer gets placed within class/struct, it has zero effect. There has to be a simple scheme, which is capable to kill the mechanism of overflows from the very root. It will be fast, reliable and rather simplest one as well.
What you want to do is basically an MMU on software level. While there was the argument for this in the MIPS3K and PPC603 that software tablewalk was faster than hardware, this has changed since those days. Today, the hardware MMUs are much more elaborated, so I would go for the hardware version. And even better would be to switch from C to some other language which does not allow the developer to be so careless. Having range checks on arrays would be a start, obligatory NULL checks on pointers the next. Yes, it sounds like Pascal, but that is a language where you can rarely run out of a data structure by accident.
What exact scheme do you mean with the term "MMU"? NX-bit, for instance, isn't an efficient thing in many cases, plus for some reasons, it's needful to have an executable stack and/or even an executable heap (data). Plus the next moment: yes, it's not been top secret that hardware-implemented algorithms are way faster than even the best counterparts of any software, but hardware-based algorithms cannot be updated in on-the-fly mode and they're more tricky for developing/debugging, to say it gently.
The aspect of memory protection which a Memory Management Unit can provide.
I very much doubt that, this is not needed. Are there any references for this claim?
Hardware based logic can be changed on the fly, it even can change itself while being active. Debugging is somewhat different, sure, but not complicated. But developing this? Not really, it requires you to think in parallel structures, or else you will have complicated code and one hell of a debugging on your hands.
Well, then would you like to explain why hardware-based algorithms have not been the lion share amongst used ones?
It's a matter of the speed: you may use absolute addresses to jump on, or relative ones.
Sure. An algorithm can be implemented in a lot of ways, choosing a hardware description language and going for silicon is only one way to do it. As I was pointing out before, you need to get your mind around the parallel nature of hardware in order to create efficient and maintainable implementations. This kind of thinking is not widely seen, and it is not taught at universities to the masses. So there are not that many people who can do this. That is point number one. Point number two is that reconfigurable hardware is not really cheap.
Since I was asking for reasons to have a stack segment or the heap being executable, and this does not provide a reason why it is needed, I'll ask again: why would I need a stack segment being executable, or the heap space?
Post #17 explains it in more details.
Your words don't contradict with my explanation, they're just more detailed
Yes, computing can be realized in a hell-ish number of ways. The human brain, for instance, is the general-purpose analog computer. Plus reconfigurability is the very cause to pound performance. Actually, all computing always is about flexibility versus performance versus stability versus power-consumption.
