Date: Tue, 15 Sep 2009 19:08:09 +0100 From: Matt Dawson <matt@chronos.org.uk> To: freebsd-security@freebsd.org Cc: des@des.no Subject: Re: Protecting against kernel NULL-pointer derefs Message-ID: <200909151908.10099.matt@chronos.org.uk> In-Reply-To: <863a6our7c.fsf@ds4.des.no> References: <4AAF4A64.3080906@thedarkside.nl> <200909151622.26589.matt@chronos.org.uk> <863a6our7c.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 15 Sep 2009 17:07:35 Dag-Erling Smørgrav wrote: > Pieter strongly implied that there had been numerous such cases, when > in fact there hasn't. Yes, DES, it could be read that way and I apologise. Without trying to wiggle out of that apology, it just seemed a bit harsh when I doubt what was written was meant as "the code is riddled with these things! RIDDLED!" given the fact that Pieter proposed a possible mitigation instead of the expected "El Reg says it's broken! EL REG! Fix it now, goddammit!" ;o) @All: Having put both feet in my mouth and had to publicly apologise, we now have a little more information from Przemyslaw on what is potentially broken and what isn't (7.2, the current production release). That "probably more to come," while still vague and very much unverified, makes me wonder if Pieter's interim mitigation or something very much like it isn't needed Right Now [TM] as he says. So, is there any technically sound reason why raising VM_MIN_ADDRESS to 65536 would not be a good trade-off (or even just a good idea) in security terms until we're sure there are no more of these lurking? A few of us paranoid security types might want to do so manually in the interim if there are no objections. -- Matt Dawson MTD15-RIPE matt@chronos.org.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909151908.10099.matt>