To: linux-kernel@vger.kernel.org
Path: not-for-mail
From: Bill Davidsen <davidsen@tmr.com>
Newsgroups: mail.linux-kernel
Subject: Re: [PATCH] OpenBSD Networking-related randomization port
Date: Tue, 01 Feb 2005 09:54:42 -0500
Organization: TMR Associates, Inc
Message-ID: <41FF9832.3010609@tmr.com>
References: <1106932637.3778.92.camel@localhost.localdomain><1106932637.3778.92.camel@localhost.localdomain> <1106935677.7776.29.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: =?UTF-8?B?TG9yZW56byBIZXJuw6FuZGV6IEdhcmPDrWEtSGllcnJv?= 
	<lorenzo@gnu.org>,
       "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
       torvalds@osdl.org
To: Arjan van de Ven <arjan@infradead.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
In-Reply-To: <1106935677.7776.29.camel@laptopd505.fenrus.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2011
Lines: 42

Arjan van de Ven wrote:
> On Fri, 2005-01-28 at 18:17 +0100, Lorenzo Hernández García-Hierro
> wrote:
> 
>>Hi,
>>
>>Attached you can find a split up patch ported from grSecurity [1], as
>>Linus commented that he wouldn't get a whole-sale patch, I was working
>>on it and also studying what features of grSecurity can be implemented
>>without a development or maintenance overhead, aka less-invasive
>>implementations.
> 
> 
> 
> why did you make it a config option? This is the kind of thing that is
> either good or isn't... at which point you can get rid of a lot of, if
> not all the ugly ifdefs the patch adds.

If there is a performance hit (there is), it's not bad to have it be an 
option, since some people will choose to go fast ("damn the torpedos, 
full speed ahead). Your point on ifdefs *may* be able to be addressed 
somewhat by putting them in macros, or similar tricks. But some are 
going to be visible even so, and you're right, they are distracting.
> 
> Also, why does it need to enhance the random driver this much, the
> random driver already has a facility to provide pseudorandom numbers
> good enough for networking use (eg the PRNG rekeys often enough with
> real entropy that brute forcing it shouldn't be possible).

I'm curious about this one as well, unless there's some proof that the 
output is "better" by actual analysis, why change? And that's better in 
terms of realized security, not by some change in the 5th insignificant 
digit of a statistical measure.

In general I do like to have the option of more security as a tradeoff, 
even if it is more than is generally needed.


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/