Re: [PATCH] Introduce compat_u64 and compat_s64 types

[Andi Kleen <ak@suse.de>]

> For the architecture we use (Blackfin), it does not support unaligned
> accesses, and we purposely never put in the trap/fixup code - we trap, and
> printk("fix your source");

For the kernel you should fix up too in addition to the printk. Otherwise
you risk a ping of death in the field with some more obscure protocol.
Also the printk should be load limited.

> > > people have done
> > > that work so using the types without unaligned.
> >
> > Very brave; we're talking about around half a million lines
> > of non trivial source code here.
>
> Is there something specific that you can think of that we should be
> testing?

A lot of protocols have variable length headers.  Normally everything
is aligned, but an attacker could purposefully misalign some headers
using variable length padding, causing fields in later headers to be 
misaligned.

e.g. the original reason this was forbidden was because the TCP
option parser could be tricked into reading time stamps unaligned.
That code is now using get_unaligned(), but there are probably
other culprits too (there is a lot of code in the network stack) 

Unfortunately it is hard to test all combinations, so the only safe 
alternative would be to audit source code. Another possibility would be to
use a tainted data scheme similar sparse's __user/__iomem annotations with
a static code checker (or extending sparse), but that would also require a lot 
of work to do properly and add the necessarily annotations.

Also watch out for netfilter modules -- they make all this much more 
complex. And drivers possibly too.

> We have done alot of testing, and people have shipped alot of systems
> connected to a varity of networks, and have run all kinds of protocols on
> them.

Well behaved peers normally don't generate unaligned headers. But
that doesn't mean it couldn't be exploited by someone malicious.

-Andi