Re: Pascal Calling Convention

["Randy Brukardt" <randy@rrsoftware.com>]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:e927347b-4f90-471a-b574-878e655eba89@34g2000pru.googlegroups.com...
On Mar 28, 8:32 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>> Not relevant to this discussion, but I think that's sad, as a lot of the
>> security problems inherent in buffer overflows would have been avoided by
>> simply keeping separate code and data segments. That would prevent code 
>> on
>> the stack from being executed. (We found a lot of problems in Janus/Ada 
>> by
>> keeping the code and data segments in our DOS Extender compilers 
>> completely
>> separate; it's been quite a bit harder to find those problems on Windows 
>> or
>> Unix systems that don't properly separate them.) The problem with 
>> segments
>> is segments that are too small, not the basic idea.
>
>...but aren't segments, in 32-bit machines, capable of doing 4GB?

Right. That's why it is sad that operating systems stopped using them when 
they moved to 32-bit. In the 16-bit systems, the segments could be too 
small, which made things messy to use, but that is much less of a problem 
for 32-bit segments.

>But I see what you mean about data/code segment separation... though
>it can also be a source of frustration if you want to do some 
>self-modifying
>code.

But that's actually a feature. To do self-modifying code, you have to ask 
the OS for a read-write-execute code/data segment. The vast majority of 
programs have no good reason for doing that, so they would have no way to 
execute injected code (presuming that the compiler run-time does not include 
unused APIs). That alone would have made programs safer, by blocking most of 
the avenues that buffer overflows could have been exploited.

One could even imagine that using that API would require elevated 
permissions and signed executables (although I think that was not something 
that was worried about in 1990).

Of course, recent OSes have been trying to graft this sort of security back 
on (breaking lots of code), but that all could have been avoided if the code 
and data had been truly separate in the first place.

                              Randy.