lkml.org 
[lkml]   [2006]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2006-07-14 01:23    [W:4.224 / U:0.480 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site