Messages in this thread | | | Date | Fri, 14 Jul 2006 01:20:26 +0200 | From | Pavel Machek <> | Subject | Re: [2.6 patch] let CONFIG_SECCOMP default to n |
| |
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/
| |