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

\
 
 \ /
  Last update: 2005-03-22 12:57    [W:0.200 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site