Messages in this thread | | | Date | Sun, 19 Aug 2001 23:08:46 +0100 | From | Alex Bligh - linux-kernel <> |
| |
> 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 account:
$ cat /proc/interrupts CPU0 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 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/
| |