Re: [PATCH] block: disable entropy contributions from nonrot devices

[Jens Axboe <axboe@kernel.dk>]

On 2014-10-02 21:26, Elliott, Robert (Server Storage) wrote:
>
>
>> -----Original Message-----
>> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>> owner@vger.kernel.org] On Behalf Of Mike Snitzer
>> Sent: Thursday, 02 October, 2014 7:11 PM
>> To: axboe@kernel.dk; linux-kernel@vger.kernel.org
>> Cc: tytso@mit.edu; gmazyland@gmail.com; agk@redhat.com; mpatocka@redhat.com
>> Subject: [PATCH] block: disable entropy contributions from nonrot devices
>>
>> Introduce queue_flags_set_nonrot_clear_add_random() and convert all
>> block drivers that set QUEUE_FLAG_NONROT over to using it instead.
>>
>> Historically, all block devices have automatically made entropy
>> contributions.  But as previously stated in commit e2e1a148 ("block: add
>> sysfs knob for turning off disk entropy contributions"):
>>      - On SSD disks, the completion times aren't as random as they
>>        are for rotational drives. So it's questionable whether they
>>        should contribute to the random pool in the first place.
>>      - Calling add_disk_randomness() has a lot of overhead.
>>
>> There are more reliable sources for randomness than non-rotational block
>> devices.  From a security perspective it is better to err on the side of
>> caution than to allow entropy contributions from unreliable "random"
>> sources.
>
> blk-mq defaults to off (QUEUE_FLAG_MQ_DEFAULT does not
> include QUEUE_FLAG_ADD_RANDOM).
>
> Even when it's off in block layer completion processing, all interrupts,
> storage or not, are forced to contribute during hardirq processing.
> I've seen this add 3-12 us latency blips every 64 interrupts (when
> the "fast_mix" code runs out of bits).

Yeah, it's a well known problem, and just as large (or larger) as the 
request completion randomness. It has significant performance 
implications, as your trace also shows. I'm pretty sure I complained 
about this 2-3 years ago (or longer), yet it's still poor.

I'd be fine with having an irq registration flag that says "don't 
contribute to randomness", on the grounds of more predictable irq 
latencies one these devices not adding any real entropy to the pool. But 
the suboptimal mixing should really be fixed.

-- 
Jens Axboe