Messages in this thread | | | Date | Sun, 16 Jul 2006 02:51:08 +0200 | From | andrea@cpushare ... | Subject | Re: [2.6 patch] let CONFIG_SECCOMP default to n |
| |
On Fri, Jul 14, 2006 at 10:55:28PM -0400, Valdis.Kletnieks@vt.edu wrote: > In fact, the best you can do here is to reduce the effective bandwidth > the signal can have, as Shannon showed quite clearly.
Yes.
> And even 20 years ago, the guys who did the original DoD Orange Book > requirements understood this - they didn't make a requirement that covert > channels (both timing and other) be totally closed down, they only made > a requirement that for higher security configurations the bandwidth of > the channel be reduced below a specified level...
Why I think it's trivial to guarantee the closure of the seccomp side channel timing attack even on a very fast internet by simply introducing the random delay, is that below a certain sampling frequency you won't be able to extract data from the latencies of the cache. The max length of the random noise has to be >= of what it takes to refill the whole cache. Then you won't know if it was a cache miss or a random introduced delay that generated the slowdown, problem solved.
As you and Pavel correctly pointed out, you can still communicate whatever you want over the wire (between the two points) by using a low enough frequency, but I don't think that has security relevance in this context.
Thanks. - 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/
| |