Date: Sun, 27 Sep 2009 20:01:26 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-current@freebsd.org, "Simon L. Nielsen" <simon@FreeBSD.org> Subject: Re: mmap zero mapping disallowed (Re: svn commit: r197537 - head/sys/vm]) Message-ID: <alpine.BSF.2.00.0909271958491.41451@fledge.watson.org> In-Reply-To: <4ABFB5D1.4010408@elischer.org> References: <20090927150233.GH1495@arthur.nitro.dk> <alpine.BSF.2.00.0909271733090.70406@fledge.watson.org> <4ABFB5D1.4010408@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Sep 2009, Julian Elischer wrote: > What they need to do now is find a fault where the offset is > 4096.. > > I wouldn't bet against it.. Oh, certainly -- this isn't a security policy, it's a vulnerability mitigation technique. It can be bypassed in the right (wrong?) circumstances, just like stack overflow protection, etc. However, it's also a potentially effective tool for limiting easier exploit paths. The kernel has a lot of 0x$smallnum failure modes, and probably significantly fewer 0x$arbitraryconstant ones, so limiting the former has benefit even if it doesn't limit the latter. To more thoroughly eliminate this type of exploit path, we'd need to move to independent kernel/user address spaces, which would increase robustness at signficant cost to performance. I think the current strategy offers some nice middle-ground benefits, and certainly makes it more tricky to exploit several reported vulnerabilities in the last year. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0909271958491.41451>