Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Putting libc.a into a segment
Message-ID: <3466@auspex.auspex.com>
Date: 14 Jun 90 17:25:28 GMT
References: <383@garth.UUCP> <1990Jun2.134157.14516@oracle.com> <27411@metropolis.super.ORG>
Organization: Auspex Systems, Santa Clara
Lines: 33

>In the current systems I have seen (e.g. SunOS) i tend to worry a
>little about undetected (and undetectable) jumps into the middle of
>a function in libc.

Well:

	1) if you jump into the middle of a function in "libc", it's
	   either because a) the linker is malfunctioning, b) you
	   overwrote code (unlikely given that it's generally
	   write-protected) or smashed a function pointer, or c) because
	   you were *trying* to.  In all those cases, the same thing can
	   happen with static linking, so it's not unique to dynamic
	   linking....

	2) They're not *completely* undetectable; jumping into the
	   middle of a function means you don't run the function prolog,
	   don't copy the right stuff into registers, etc. so there's
	   what I suspect is a good chance that the misbehaving program
	   won't misbehave silently....

>How do we know this is not happening now? As far as I can tell, we
>don't.  What happens when we find out that maybe it is? 

Fix the linker, or fix the program not to overwrite code or smash
function pointers....

This is somewhat along the lines of doing other checks at run-time (or
even compile-time, for some checks), e.g. array-bounds checking.  If you
do the latter (especially if the compiler can figure out when it's
needed and when it's not), you may be less likely to overwrite code or
smash function pointers - or do *other* nasty things, so putting the
"architectural" support (whether in the instruction set or the compiler)
there may buy you more.