Protecting against kernel NULL-pointer derefs

[Matt Dawson]

On Tuesday 15 Sep 2009 13:42:28 Dag-Erling Smørgrav wrote:

> there must be a better way to make your case than to sow FUD?

Where? To paraphrase yourself: Please define "sowing FUD." There's an issue; 
there have been two previously. Nobody is blaming anyone, blowing it out of 
proportion, leaving FBSD in droves or pointing fingers. We know it's local and 
we're all well aware of the axiom "if someone else has physical access to your 
box, it isn't your box any more." I don't see or feel any fear, uncertainty or 
doubt. I just see a concerned but dedicated FBSD user discussing an issue 
sensibly with the information currently to hand.

Providing it does not seriously affect anything else (Pieter has already asked 
for information and opinions before the thread went off on this tangent), if 
setting this #define downgrades arbitrary code execution vulnerabilities and 
privilege escalations to crashes where system and, more importantly IMHO, host 
integrity is preserved then I am all for it. I'd certainly rather have a DoS 
and the risk of cached data loss than a potential information leak or a 
reputation-destroying spamming session run. That we don't have multiple places 
that this could be overridden/reset similar to the SELinux issue also inspires 
confidence in Pieter's method. As simple as it seems, it would appear to be 
(sorry, buzzword-that-fits coming up) proactive in its approach, addressing 
and mitigating any future issues of this type and limiting the possible 
damage.

Also worth thinking about: Do we need to consider -fno-delete-null-pointer-
checks or a downgrade to -O for kernel/world optimisation level for now until 
we're sure there are no more of these lurking? Linux found out the hard way 
that code order matters when compiling at >-O and that perfectly acceptable 
code coupled with assumptions made by the compiler can bite you in the 
backside.
-- 
Matt Dawson
MTD15-RIPE
matt at chronos.org.uk