rminnich@super.ORG (Ronald G Minnich) (06/12/90)
In article <1990Jun2.134157.14516@oracle.com> csimmons@oracle.com writes: >Ah! I can't pass this one up. Turns out that one of your favorite >machines, the GE 6something (well, one of its descendents), does this >sort of thing. The Dartmouth College Time Sharing system started >putting shared libraries in segments in around 1985 or so. Worked >great. Well, ok, as i think maybe Guy pointed out, if you consider /vmunix as a library, then it is a large text segment that has entry points, and thus falls into this class too. But what about a big chunk of code like libc or libX11? On the DG MV/10000 libc was in Ring 3 (if memory serves ... this was 7 years ago). User processes lived in Ring 7. This was in hardware. And of course B. has had library segments for going on 30 years now. The question I keep wondering: EMT or whatever your favorite trap instruction is provides a way, supported in hardware, of calling a library (/vmunix) with a parameter (for sysent) which allows you to call a function without knowing its address. Hardware support for dynamic binding, sort of. In most Unix implementations I have seen /vmunix is the only place this is used, with the aforementioned DG machine being an interesting exception. Stdio and all that good stuff is called with straight standard jsr instructions. My question is now that Unix is finally catching up with dynamic binding in some implementations do we want architectural support so that e.g. calls to libc.a have the same mechanism as the kernel calls (probably not it is pretty expensive) or a *similar* mechanism that is supported in hardware (e.g. mv10000 call gates, 386 call gates, and so on). To put it another way do any of you out there see any change in architecture to support dynamic libraries or dynamic binding or do we stick with traps and munging all this stuff in software? 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. 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? ron -- Grad student, ca 1976: Gosh, the v6 kernel is < 64K! Compare it to that OS/MVS hog at 400K! Grad student, ca 1986: Look at all the good stuff in Gnu Emacs for only 600K!
guy@auspex.auspex.com (Guy Harris) (06/15/90)
>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.
rminnich@super.ORG (Ronald G Minnich) (06/15/90)
In article <3466@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > 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.... Yeah, but look, the "dynamic linking" to the kernel text segment always works because there is "hardware support" for it. "" are there because it isn't really that great, but it does work. That is not the case for SunOS style software supported dynamic linking. If for some reason ld.so should get hashed by something then I can no longer run anything. Period. So the "dynamic linking" to the kernel is more robust (I think) because of hardware support, such as it is. Do we not care about having the same degree of robustness for libraries? Of course it is not unique to dynamic linking; it is just that nowadays on sunos i run ld everytime I run a program, and am thus significantly more exposed to problems should there be a problem with ld.so. Oh, heck, I will say it: like a virus in ld.so. With the way things work now on SunOS you can instantly infect every program on the system by changing one little file. > 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.... Honest, I have seen this sort of thing happen. "This could never have worked"- except it did, for years. We really saw this when we made the big move from -11 to VAX in 1980. I can easily find linker screwups in a statically linked object with adb. Not so with dynamic linking. Not that this has ever happened (well, actually, it did to me once long ago), but there is a distinct difference in how easy it is to detect. My original question stands. This list generally discusses getting lotsa flops, but I don't see much discussion of whether there should be a second look at such things as architectural support for such things as dynamic linking. Does that mean there should not be? ron -- Grad student, ca 1976: Gosh, the v6 kernel is < 64K! Compare it to that OS/MVS hog at 400K! Grad student, ca 1986: Look at all the good stuff in Gnu Emacs for only 600K!
guy@auspex.auspex.com (Guy Harris) (06/27/90)
>Again, the more important hardware support was for intra-domain >procedure calls. "*Inter*-domain procedure calls", dummy. :-)