| 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
| ||
|
Date: Fri, 3 Oct 2014 03:26:27 +0000
From: "Elliott, Robert (Server Storage)" <Elliott@...com>
To: Mike Snitzer <snitzer@...hat.com>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"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
> -----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).
Example of fast_mix only taking 0.071 us:
(from ftrace function_graph)
8) | handle_irq_event() {
8) | handle_irq_event_percpu() {
8) | do_hpsa_intr_msi [hpsa]() {
8) 0.060 us | SA5_performant_completed [hpsa]();
8) 0.397 us | }
8) 0.071 us | add_interrupt_randomness();
8) 0.071 us | note_interrupt();
8) 1.495 us | }
8) 0.045 us | _raw_spin_lock();
8) 2.165 us | }
Example of the 64th bit taking 3.814 us:
8) | handle_irq_event() {
8) | handle_irq_event_percpu() {
...
8) | add_interrupt_randomness() {
8) | __mix_pool_bytes() {
8) 0.312 us | _mix_pool_bytes();
8) 0.688 us | }
8) | credit_entropy_bits() {
8) | __wake_up() {
8) 0.070 us | _raw_spin_lock_irqsave();
8) 0.050 us | __wake_up_common();
8) 0.056 us | _raw_spin_unlock_irqrestore();
8) 1.448 us | }
8) 0.048 us | kill_fasync();
8) 2.313 us | }
8) 3.814 us | }
---
Rob Elliott HP Server Storage
--
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/
Powered by blists - more mailing lists