Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Andrew James Wade]

On Wednesday 12 July 2006 18:02, Alan Cox wrote:
...
> Actually measuring time through the network is extremely doable given
> enough samples as is communication through delay perturbation. A good
> viterbi encoder/decoder will fish a signal out of very high noise. Yes
> you pay a lot in data rate at that point but it works.

The data rate is important: it can mean a difference between an attack
that is practical and one that is impractical. Although I suspect the
orders of magnitude in the sampling rate of rdtsc versus network
packet times is more important. Another source of timing information
could be two seccomp threads (scheduled to different cores/SMT
threads) comparing their relative progress. What made the L1 cache
miss side-channel so interesting was its very high bandwidth. Relative
progress timing techniques will yield lower side-channel bandwidth on
many interesting configurations.

> Anyway at the point you pass the bytecode through a processing filter
> you don't need SECCOMP because your filter can remove any syscall
> attempts. 

Both int 80 and the rdtsc instructions are only 2 bytes long: they'll
generate too many false positives. It may be practical to filter out
the "f00f" instructions though. 
And filtering isn't fail-safe from a security point-of-view: if you
miss a case you lose. For example, can the f00f bug still be triggered
if there are prefixes between the lock prefix and the cmpxchg8b? I
don't know, but if so you'll need to filter for those cases too.

Filtering may be a good idea, but I wouldn't want to rely on it alone.

Andrew Wade
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/