Messages in this thread |  | | | Subject | Re: [2.6 patch] let CONFIG_SECCOMP default to n | | Date | Wed, 12 Jul 2006 22:56:01 -0400 | | From | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |