I must say that I'm no expert in security, so I don't know the how to prevent attacks and, probably even worse, I don't know what the risks are. But I do appreciate a computer with no antivirus/antispyware etc, that can safely surf on most websites and remain connected to a chat without too many risks.
That said, I must say that I also appreciate a computer that is as fast as the hardware allows. After a quick look at the blog, I see that -fPIE and -fPIC are related. PIC requires a lookup table, making every library call pass through an extra jump. The cost is negligible on intel-like computers, and is comparable to the cost of a virtual call. Hardware branch prediction makes such calls very cheap. And all in all, we rarely see the CPU go up to 100% for a long time. In conclusion, I would say I don't mind to get an invisible performance hit if there is a good reason behind this change, with the exception that I'd like time-critical code to be optimized at its best. That includes openGL, Loki, Boost, MPC, MPFR and maybe stdlib. I don't have the knowledge to tell how those binaries are packaged at the moment, and especially with templated code this won't make any difference. The best would be to try some stress code and see if there's a significant performance loss. Again, I'm not speaking about boot time or similar things, but about time critical software, like games, scientific programs and so on. Mic On 28/02/2012 20:42, Anthony G. Basile wrote: > Sorry but -fPIE does has a perf hit on x86. It doesn't on amd64. > > On 02/28/2012 01:44 PM, Steven Cristian wrote: >> I agree with Mitch, and also hardening with -fPIE has no performance cost, >> so why not :) ? >> >>> Date: Tue, 28 Feb 2012 12:07:57 -0600 >>> From: [email protected] >>> To: [email protected] >>> Subject: [sabayon-dev] Hardening in Sabayon >>> >>> Now is a good time to try to implement some hardened features in Sabayon. >>> >>> Since hardening has the potential to break some applications, Sabayon >>> will want to approach the issue incrementally. Some of the first >>> steps may just be to lay the groundwork, and not really provide any >>> significant security enhancements. >>> >>> "Hardening" is a very broad topic, with many overlapping subtopics. >>> Right now, there are a handful of show-stoppers that would probably >>> prevent Sabayon from implementing across-the-board hardening (not the >>> least of which is a lack of consensus as to what would constitute a >>> fully hardened Desktop system). But, over time, I expect the blockers >>> to gradually support hardening. >>> >>> Linux server applications are much further along in supporting >>> hardening than the Linux Desktop world. So since Sabayon is heavily >>> invested in the Desktop area of Linux, we'll need to be careful how we >>> proceed. >>> >>> It would be counter-productive for me to provide a tutorial on >>> hardening. But, here's a few links I've found helpful. >>> >>> http://www.gentoo.org/proj/en/hardened/ >>> >>> http://blog.flameeyes.eu/2009/11/02/the-pie-is-not-exactly-a-lie >>> >>> I found flameeye's blog very enlightening for someone who is just >>> trying to get their head around hardening. >>> >>> Sabayon will probably wait on implementing the hardened patches in >>> Gentoo's hardened kernel. But, there are some really interesting >>> capabilities bundled into the Gentoo hardened kernel, and we will >>> certainly want to evaluate what can be implemented (or perhaps when). >>> >>> Our initial focus will probably be on building a subset of >>> applications with PIE. This is a topic that has recently been active. >>> And the ASLR that is already in the kernel should work "well-enough" >>> with binaries built with PIE. >>> >>> Supporting PaX/NX will probably take longer. >>> >>> Since there are several sub-topics to discuss, I'm going to cut this >>> post off here, and try to keep the messages to being only slightly >>> long. I'll get into some of the sub-topics in separate posts. >>> >> >> >> > > > -- > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] > E-Mail : [email protected] > GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 > GnuPG ID : D0455535 > > > >
