Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Pavel Machek <pavel@ucw.cz>]

Hi!

I do not want to enter seccomp flamewar, and that's why I did not
answer to Ingo.

> > Actually random delays are unlike to help (much). You have just added
> > noise, but you can still decode original signal...
> 
> You're wrong, the random delays added to every packet will definitely
> wipe out any signal.

Strictly speaking, this is wrong. This is like adding noise into the
room. You have to pick up maximum delay (ammount of noise), and you
clearly can't override signal that's longer than maximum delay. But
you also can't override signal that's half the maximum delay, given
that transmitter will retransmit it 4-or-so times. Just average 4
samples, and your random delays will cancel out.

No, this probably does not apply to seccomp, because we are picking
unintended noise from affected computer.

OTOH I'm pretty sure I could communicate from seccomp process by
sending zeros alone, and I cound communicate from another process on
box running seccomp through your randomizing packetizer to my machine.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/