Re: Updated SELinux Release
On Thu, 04 Nov 2004 13:15:44 +0000, Luke Kenneth Casson Leighton wrote:
> On Thu, Nov 04, 2004 at 01:02:35AM -0600, Manoj Srivastava wrote:
>> On Wed, 03 Nov 2004 21:15:38 -0500, Colin Walters <walters@verbum.org> said:
>>
>> > On Wed, 2004-11-03 at 19:21 +0000, Dhruv Gami wrote:
>> >> Personally, i would prefer to have those two tarballs available. I
>> >> know most people using SELinux are familiar with patching the
>> >> kernel, and are generally familiar with how Linux works and know
>> >> their way around on a Linux system.
>>
>> > But moving forward, we don't want people to have to patch their
>> > kernel or utilities.
>>
>> Moving waaay forward. I asked the Debian kernel team to
>> consider compiling in SELinux (perhaps disabled by default, for
>> starters), and was told that that is not going to fly because of
>> "significant performance hit" one takes by compiling SELinux in. I
>> did not have any data to refute the claim, so that is where we sit.
>
Manoj, if you're referring to our conversation earlier on IRC, I said that
I have no personal interest in selinux, but I had no problems with it
being included as long as it's not a significant performance hit. I
requested that you take it up on the debian-kernel list, though. That
request still stands; the kernel team is not a single person, nor is it
comprised an IRC channel.
> i had a bun-fight with the people who have taken over from
herbert: at
> the point where i told them that recompiling applications to be
> optimised like yoper and gentoo distributions gives back performance
> far in excess of that lost by selinux, i stopped hearing back from
> them.
>
I assume you're referring to #249510, in which Christoph mentioned it was
a 5% performance penalty. That's significant, especially for people who
don't care about selinux. Your argument of "well it's not 20%, is it?" is
bogus; throwing features into the kernel, each having a 5% performance
penalty hit, quickly add up.
Furthermore, this isn't even going to be considered until post-sarge, so
there's little point arguing about it now. Just like we've told the PAX
people (who, quite frankly, interest me more than the selinux people);
provide solid benchmarks showing exactly how little of a performance hit
the feature is, and we'll be more likely to include it. Without hard
data, all you have are guesses (2%, 5%, hell, it could be 20% for all we
know. List your sources).
And yes, different compilers may compile code that runs faster; that's
not news. That does not mean we're going to slow other parts of the
system down to balance that out, if we obtain any speed benefits with
gcc-3.4.
Reply to: