USB HID devices not linked to RNG

Hi,

While analyzing the entropy sources for the random number generator in 
drivers/char/random.c, I saw that a USB mouse and a USB keyboard does trigger 
the add_input_randomness function to be triggered.

Is that intended? 

-- 
Ciao
Stephan

Am Montag, 7. September 2015, 02:10:16 schrieb Stephan Mueller:

Hi Stephan,

Hi,

While analyzing the entropy sources for the random number generator in
drivers/char/random.c, I saw that a USB mouse and a USB keyboard does
trigger the add_input_randomness function to be triggered.

I need to reread what I write :-)

I mean that the USB mouse and USB keyboard does *not* trigger the 
add_input_randomness function.

Is that intended?

-- 
Ciao
Stephan

This is just an off the wall guess.  Wouldn't such entropy already be
collected at a lower level, like raw usb traffic?

On Sun, Sep 6, 2015 at 7:12 PM, Stephan Mueller [off-list ref] wrote:

Am Montag, 7. September 2015, 02:10:16 schrieb Stephan Mueller:

Hi Stephan,

quoted

Hi,

While analyzing the entropy sources for the random number generator in
drivers/char/random.c, I saw that a USB mouse and a USB keyboard does
trigger the add_input_randomness function to be triggered.

I need to reread what I write :-)

I mean that the USB mouse and USB keyboard does *not* trigger the
add_input_randomness function.

quoted

Is that intended?

--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Am Montag, 7. September 2015, 15:07:47 schrieb Mike Mestnik:

Hi Mike,

This is just an off the wall guess.  Wouldn't such entropy already be
collected at a lower level, like raw usb traffic?

The RNG collects data from interrupts (that also covers normal PS/2 mice and 
keyboards), block devices and HID (it hooks itself into the input layer).

So, raw USB traffic is not a source of entropy other than for the interrupts 
the base PCI traffic would generate.

What I am wondering: isn't the USB mouse/keyboard support hooking into the 
kernel's input layer?

Ciao
Stephan

On Mon, Sep 7, 2015 at 2:09 PM, Stephan Mueller [off-list ref] wrote:

Am Montag, 7. September 2015, 15:07:47 schrieb Mike Mestnik:

Hi Mike,

quoted

This is just an off the wall guess.  Wouldn't such entropy already be
collected at a lower level, like raw usb traffic?

The RNG collects data from interrupts (that also covers normal PS/2 mice and
keyboards), block devices and HID (it hooks itself into the input layer).

So, raw USB traffic is not a source of entropy other than for the interrupts
the base PCI traffic would generate.

What I am wondering: isn't the USB mouse/keyboard support hooking into the
kernel's input layer?

All input devices add randomness, however I think for mouse
add_input_randomness() will drop majority of events since they are
likely have the same value (well, depends on which direction you are
moving the mouse)...

-- 
Dmitry

Am Dienstag, 8. September 2015, 22:40:07 schrieb Dmitry Torokhov:

Hi Dmitry,

All input devices add randomness, however I think for mouse
add_input_randomness() will drop majority of events since they are
likely have the same value (well, depends on which direction you are
moving the mouse)...

I agree that such mechanism is present, but it is implemented by 
add_input_randomness:

        /* ignore autorepeat and the like */
        if (value == last_value)
                return;

So, when we install a probe at the entry into add_input_randomness, we should 
see invocations.

The problem now is that add_input_randomness is not called at all.

Simply use the following code as a systemtap script, load it and move a USB 
mouse or type on a USB keyboard:

probe kernel.function("add_input_randomness") {
	printf("add_input_randomness triggered\n");
}

Expected behavior: tons of printouts should be received (as it is the case 
with PS/2 mice and keyboards).

Actual behavior: no printout when moving USB HID.


Ciao
Stephan