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=C3=B8rgrav 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=20 wiggle out of that apology, it just seemed a bit harsh when I doubt what=20 was written was meant as "the code is riddled with these things! RIDDLED!"= =20 given the fact that Pieter proposed a possible mitigation instead of the=20 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= =20 a little more information from Przemyslaw on what is potentially broken and= =20 what isn't (7.2, the current production release). That "probably more to=20 come," while still vague and very much unverified, makes me wonder if=20 Pieter's interim mitigation or something very much like it isn't needed=20 Right Now [TM] as he says. So, is there any technically sound reason why=20 raising VM_MIN_ADDRESS to 65536 would not be a good trade-off (or even just= =20 a good idea) in security terms until we're sure there are no more of these= =20 lurking? A few of us paranoid security types might want to do so manually=20 in the interim if there are no objections. =2D-=20 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>