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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <542F141A.8020601@kernel.dk>
Date:	Fri, 03 Oct 2014 15:24:42 -0600
From:	Jens Axboe <axboe@...nel.dk>
To:	"Elliott, Robert (Server Storage)" <Elliott@...com>,
	Mike Snitzer <snitzer@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	"tytso@....edu" <tytso@....edu>,
	"gmazyland@...il.com" <gmazyland@...il.com>,
	"agk@...hat.com" <agk@...hat.com>,
	"mpatocka@...hat.com" <mpatocka@...hat.com>
Subject: Re: [PATCH] block: disable entropy contributions from nonrot devices

On 2014-10-02 21:26, Elliott, Robert (Server Storage) wrote:
>
>
>> -----Original Message-----
>> From: linux-kernel-owner@...r.kernel.org [mailto:linux-kernel-
>> owner@...r.kernel.org] On Behalf Of Mike Snitzer
>> Sent: Thursday, 02 October, 2014 7:11 PM
>> To: axboe@...nel.dk; linux-kernel@...r.kernel.org
>> Cc: tytso@....edu; gmazyland@...il.com; agk@...hat.com; mpatocka@...hat.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/