| |||||||||||||
Security-improving technologies which could be deployed nowSecurity-improving technologies which could be deployed nowPosted Oct 15, 2004 17:44 UTC (Fri) by ballombe (subscriber, #9523)Parent article: Security-improving technologies which could be deployed now
Before asking why such technology is not in Debian or Gentoo,
(Log in to post comments)
Security-improving technologies which could be deployed now Posted Oct 16, 2004 0:22 UTC (Sat) by garloff (subscriber, #319) [Link] > As for the 1% overhead for PIE executable on x86, for programs making> heavy use of global symbols in critical path, the overhead is closer > to 5% and I have examples (using hand-made assembly) where it reach > 20%. Indeed, on x86, where you already have a shortage of general purpose registers, PIC will waste one more integer register. Unfortunately, this happens on compute intensive tasks where you really care. Think bzip2, gcc, ... 5% is the number seen by me as well. On x86-64, you have twice as many GPRs and you normally don't even need to offer one for PIC, due to the nice RIP relative addressing mode. Thus the low overhead. The gcc/toolchain developers have done a nice job of making sure that PIC code runs nicely on x86-64!
Security-improving technologies which could be deployed now Posted Oct 21, 2004 19:51 UTC (Thu) by bluefoxicy (guest, #25366) [Link] "Unfortunately, this happens on compute intensive tasks where you reallycare. Think bzip2, gcc, ..."
icebox ~ # file /lib/libz.so.1.2.1
This isn't PIE; these are shared libraries, which on all systems are PIC. Notice that much if not most or almost all heavy lifting--compression, multimedia encoding/decoding, networking operations, X graphics card drivers, X extensions such as composite and glx and even MESA SW GL, window drawing toolkits such as GTK or QT--are all libraries. Libraries are all shared objects, which are PIC.
PIE (Position Independent Executables) are just PIC executables, i.e. things in */bin.
icebox ~ # file /bin/bzip2
So unfortunately the overhead happens in the most critical places anyway.
As for eating 1%-20%, microbenchmarks are cute but useless. They're theoretical maximums; but as illustrated here, the heavy lifting is done where you can't avoid them.
I got closer to 5% when testing with -fomit-frame-pointer; however, the difference between '-fomit-framepointer -fPIC' and neither is still 1%. It appears that the gains of -fomit-frame-pointer are lost completely with -fPIC, *and* the normal overhead of -fPIC is added, creating an illusionary 5-6% overhead.
Security-improving technologies which could be deployed now Posted Oct 21, 2004 6:54 UTC (Thu) by joib (guest, #8541) [Link] Before asking why such technology is not in Debian or Gentoo, ask why the patches are not merged in linux in gcc by the upstream developers. Here lie part of the answer.GCC has its own libmudflap thingy, whose purpose IIRC is to catch illegal array indexes. Thus it has some overlap with SSP, and gcc apparently is not going to merge it. Which perhaps is a pity, since mudflap is more of a debugging tool rather than something that's supposed to be used for production code.
Security-improving technologies which could be deployed now Posted Oct 21, 2004 16:37 UTC (Thu) by job (guest, #670) [Link] That actually sounds like a better technique. The performance penalty isprobably a little larger, in the real world but who cares? Has there been any work towards using it as a stack overflow exploit prevention?
Security-improving technologies which could be deployed now Posted Oct 21, 2004 18:01 UTC (Thu) by solar (guest, #17536) [Link] 1-3%(ssp) vs 30ish%(mudflap) is a quite a big deal for production use. I can't imagine any vendor releasing production ready media compiled with mudflap. It may be used to do some QA on the back end before the media is deployed out for the masses but in production probably never.
Security-improving technologies which could be deployed now Posted Oct 21, 2004 21:37 UTC (Thu) by bluefoxicy (guest, #25366) [Link] Mudflap is an excellent technology. I would love to see it forced on developers via a Singapore prison guard holding a cane in one hand and a whip in the other. ;)
That being said, deployment of software built with Mudflap is a horribly bad idea. Mudflap is made to be a debugging tool, not a security tool, and has no place in use in production. It is there to help the programmer polish his program, not to play goalie on your web server.
The combination of the technologies is an excellent prospect. On the developer's end, things such as Mozilla are built with Mudflap. These binaries give a load of information about what is broken, which is used to fix that. The binaries shipped to regular users are instead compiled with SSP and without Mudflap. These binaries will run much more efficiently, and will dterminate if a buffer overflow bug still exists and is manifested, such as during an attack.
Let's also note that most software will run fine until attacked with SSP. This shows that the buffers aren't being overflowed in normal use. If they are not overflowed, Mudflap will probably not see anything wrong, and thus will be deployed a vulnerable program. Upon being exploited, SSP will terminate the program, and as a bonus feed back a little bit of data which can be used to track down where the bug occurred.
Both technologies have their uses, and both should be used gratuitously.
|
|||||||||||||