[lkml]   [2001]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    > Because it looks at inter-IRQ timing, the risk is mainly (as per
    > previous posting) the theoretical risk of being able to determine
    > that inter-IRQ timing from observation of the network(s) connected.

    So I looked at this a bit more. The stuff which increases entropy
    is meant to be secure from non-root users.

    However (standard debian install - headless machine), unpriveleged

    $ cat /proc/interrupts
    0: 1116302985 XT-PIC timer
    1: 2 XT-PIC keyboard
    2: 0 XT-PIC cascade
    8: 1 XT-PIC rtc
    9: 28980016 XT-PIC usb-uhci, eth0
    14: 698146587 XT-PIC ide0
    15: 5 XT-PIC ide1
    NMI: 0
    ERR: 0

    Shock horror - I can continually poll this and spot
    when an IRQ occurs.

    So polling /proc/interrupts gives me a pretty good indication
    of timing for ide0 interrupts (and, if I had one, keyboard
    interrupts). The /proc reading routine is sufficiently fast
    that by repeating reading (as a user) I should be able to
    get the inter-IRQ timing down to a few tens of microseconds,
    which I think is a few tens of possible values added to the
    entropy pool. This tells me that actually keyboard and ide
    interrupt timings are no less observable by non-root people than
    network interrupts.

    Now if you have an IR or radio keyboard, the situation is even worse.

    So I don't think Robert's patch is any more flawed than using
    k/b, mouse, ide IRQs.

    Alex Bligh
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:57    [W:0.027 / U:0.296 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site