[bcc'd to Dan Goodin @ theregister]
If anyone wants a choice quote from me about the recent Linux holes,
this is what I have to say:
Linus is too busy thinking about masturabating monkeys, he doesn't
have time to care about Linux security.
For the record, this particular problem was resolved in OpenBSD a
while back, in 2008. We are not super proud of the solution, but it
is what seems best faced with a stupid Intel architectural choice.
However, it seems that everyone else is slowly coming around to the
same solution.
The commit message:
CVSROOT: /cvs
Module name: src
Changes by: dera...@cvs.openbsd.org 2008/06/24 15:24:03
Modified files:
sys/arch/alpha/include: vmparam.h
sys/arch/amd64/include: vmparam.h
sys/arch/arm/include: vmparam.h
sys/arch/i386/include: vmparam.h
sys/arch/sh/include: vmparam.h
sys/arch/sparc/include: vmparam.h
sys/arch/vax/include: vmparam.h
sys/arch/sh/sh : trap.c
Log message:
On user/kernel shared page table machines, do not let processes map their
own page 0, as discussed with miod (and many others previously, including
art and toby). On sparc, make this __LDPGSZ because PAGE_SIZE is non-constant
ok miod tedu
There are four things interesting about this change:
1) The #1 reason why the Linux team has not commited this by default
is because it breaks Wine, which wants to play with page 0 -- so
basically they are resisting this for Windows binary compatibility
Ironic, isn't it? If anyone else tells you that is not the #1
reason, they are lying. We decided we don't care about Wine.
2) At least three of our developers were aware of this exploitation
method going back perhaps two years before than the commit, but we
gnashed our teeth a lot to try to find other solutions. Clever
cpu architectures don't have this issue because the virtual address
spaces are seperate, so i386/amd64 are the ones with the big impact.
We did think long and hard about tlb bashing page 0 everytime we
switch into the kernel, but it still does not look attractive from
a performance standpoint.
3) Last week a bug was found in OpenBSD's kernel which was locally
exploitable before the commit on Jun 24, 2008. Afterwards that fix,
it simply becomes a kernel crash; you cannot gain priviledge from
it. The reality is that kernel bugs will always exist, no matter
how hard we try. Our focus therefore is always on finding innovative
ideas which make bugs very hard to exploit succesfully. Bugs will
exist. At least they should be more difficult to exploit.
3) Note the date of the commit, 2008/06/24. Interestingly, this commit
was done 1 month before Linus posted this:
http://article.gmane.org/gmane.linux.kernel/706950
I'm glad we care about security and trying to make things better, and
I am glad that Linus prefers to write articles about monkey
masturbation. In life, everyone should stick to what they know the
most about. Because Linus knows dick all about security research.
