[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101112103310.5504cf77@nehalam>
Date: Fri, 12 Nov 2010 10:33:10 -0800
From: Stephen Hemminger <shemminger@...tta.com>
To: Dan Rosenberg <drosenberg@...curity.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...emloft.net>, socketcan@...tkopp.net,
kuznet@....inr.ac.ru, urs.thuermann@...kswagen.de,
yoshfuji@...ux-ipv6.org, kaber@...sh.net, jmorris@...ei.org,
remi.denis-courmont@...ia.com, pekkas@...core.fi, sri@...ibm.com,
vladislav.yasevich@...com, tj@...nel.org, lizf@...fujitsu.com,
joe@...ches.com, hadi@...atatu.com, ebiederm@...ssion.com,
adobriyan@...il.com, jpirko@...hat.com, johannes.berg@...el.com,
daniel.lezcano@...e.fr, xemul@...nvz.org,
socketcan-core@...ts.berlios.de, netdev@...r.kernel.org,
linux-sctp@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 4/10] Fix leaking of kernel heap addresses in net/
On Fri, 12 Nov 2010 12:24:42 -0500
Dan Rosenberg <drosenberg@...curity.com> wrote:
>
> >
> > Also, the whole idea needs to be under a config option, so only
> > the paranoid idiots turn it on.
>
> If that's what's necessary to get it accepted, I'm willing to do that.
> But when a solution does not negatively impact usability or performance
> and improves security, even in a small way, why should it not be enabled
> by default? Of course it's my responsibility to first propose a
> solution that is acceptable from a usability/debugging standpoint, but
> assuming that can be achieved, I don't really see what the problem is.
> There's a difference between being a "paranoid idiot" and wanting to
> protect users from unnecessary exposure.
See earlier discussion about automatically running crypto tests on boot
which caused Linus to flame. This is more intrusive, and is not something
most developers would want; but it might make sense in production
environment.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists