David Shochat <david.shoc...@gmail.com> posted 9b8d5d890902180304w71920aa5w6af337575c078...@mail.gmail.com, excerpted below, on Wed, 18 Feb 2009 06:04:12 -0500:
> I tried last night to post my results through the gmane NG, but for some > reason, that did not work. So I'll repeat myself here. The short answer > is that there is no difference in the ldd output whether I do it while > running XFCE or GNOME. Every line of ldd output ends with a 32-bit hex > value in parentheses and that part does differ. However it also differs > if I simply run the ldd command on pan in the same environment twice in > succession. I used awk to remove the final hex bit and the resulting > filtered output is the same in all cases. I'd be glad to post the output > anyway, if you want to see it. Rats! I was hoping they differed in (ideally) exactly one library or library version. I thought we might be on the way to a solution to that one! ... And I don't think it's possible to do ldd with gnome because gnome is actually a bunch of component applications, not a single monolithic beast. I suppose one could try switching out components from GNOME or switching in components from it to XFCE/KDE and see where the problem stops or starts occurring, but to really do that properly and without huge amounts of trial and error would require a lot of knowledge of component application dependencies and possible substitutes, a far higher level of detail than most would know, and for someone with that level of knowledge, there's likely a far more direct troubleshooting route. There's another step one could take if they knew their way around readelf and function symbols, and there's a reasonable chance I could bumble my way thru it here, but it's not something I know enough about to try to explain. FWIW, AFAIK those hex values in parentheses are library load addresses. On x86(32), from what I've read, a library has a "natural" load address where it works best as function address lookups are direct from the table. If two different libraries overlap, however, one has to be moved to load at a different logical address from the viewpoint of that app, and every function reference then suffers a performance penalty due to an additional layer of indirection. If I'm not mistaken, this is what is referred to as text-relocations, aka textrels. If I understand things correctly, there's also some loss of efficiency in regard to shared libraries being able to exist as a single copy in memory -- the relocated instance can't be memory-shared as naturally located instances normally are. amd64 aka x86_64 works a bit differently. 64-bit libraries must always be compiled as position independent code -- in essence, assigned a random address at runtime. This is the -fPIC that Gentoo amd64 users and other amd64 users that install from source find so frustrating on occasion, because if it's not added to the code as it's compiled, the linker can't link the final library together and spits out an error. But, simply adding it to your normal CFLAGS isn't so good an idea as actual applications (as opposed to libraries) still suffer the performance penalty x86 does. All that said, regardless of the performance penalty, runtime address randomization is a better security practice, since a cracker attempting to exploit a buffer overflow to do anything "interesting" will have a MUCH easier time if he can count on knowing a function's normal memory address ahead of time. While a compile-time determination won't affect from-source users that much since they'll all have their own anyway, if a cracker is familiar with a particular binary distribution and version, he can exploit that knowledge when targeting anyone else running that particular library binary, on x86(32) at least. So it's a question of security vs. performance. Common desktop distributions choose performance, but particularly hardened "server" distributions may choose to take the performance penalty to get the additional security. The other alternative, as I mentioned, is compiling your own or distributing in small enough batches that it's effectively too small a target to be worth worrying about. But that's one of the advantages of x86(64), as the security issue doesn't exist on it, for libraries anyway. The equivalent flag for actual application relocation is -fPIE (E as opposed to C, E=executable, C I think is Code, but that doesn't distinguish application executable from library, so Common may be easier to remember). -fPIE, position independent executable, has the same performance penalty on both 32-bit and 64-bit. It is however a somewhat smaller target security-wise since most of the "interesting" functions tend to be in libraries anyway. Based on the above, I'd /guess/ that you aren't running x86(32), or, if I understand correctly, most of those addresses would remain the same from call to call, as long as the libraries themselves weren't changed. However, I don't seem to be doing so well with my guesses at this point... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
