linux-kernel - Re: [PATCH] scsi: sd: Contribute to randomness when running rotational device

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]

Date:   Thu, 06 Sep 2018 15:27:53 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     Xuewei Zhang <xueweiz@...gle.com>,
        "James E . J . Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Ming Lei <ming.lei@...hat.com>, Hannes Reinecke <hare@...e.de>,
        Christoph Hellwig <hch@....de>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org, Aditya Kali <adityakali@...gle.com>,
        tytso@....edu, Guenter Roeck <groeck@...omium.org>, maze@...gle.com
Subject: Re: [PATCH] scsi: sd: Contribute to randomness when running
 rotational device

On Thu, 2018-09-06 at 13:37 -0700, Xuewei Zhang wrote:
> Currently a scsi device won't contribute to kernel randomness when it
> uses blk-mq. Since we commonly use scsi on rotational device with
> blk-mq, it make sense to keep contributing to kernel randomness in these
> cases. This is especially important for virtual machines.
> 
> commit b5b6e8c8d3b4 ("scsi: virtio_scsi: fix IO hang caused by automatic
> irq vector affinity") made all virtio-scsi device to use blk-mq, which
> does not contribute to randomness today. So for a virtual machine only
> having virtio-scsi disk (which is common), it will simple stop getting
> randomness from its disks in today's implementation.
> 
> With this patch, if the above VM has rotational virtio-scsi device, then
> it can still benefit from the entropy generated from the disk.
> 
> Reported-by: Xuewei Zhang <xueweiz@...gle.com>
> Signed-off-by: Xuewei Zhang <xueweiz@...gle.com>
> ---
>  drivers/scsi/sd.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index b79b366a94f7..5e4f10d28065 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2959,6 +2959,9 @@ static void sd_read_block_characteristics(struct
> scsi_disk *sdkp)
>  	if (rot == 1) {
>  		blk_queue_flag_set(QUEUE_FLAG_NONROT, q);
>  		blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, q);
> +	} else {
> +		blk_queue_flag_clear(QUEUE_FLAG_NONROT, q);
> +		blk_queue_flag_set(QUEUE_FLAG_ADD_RANDOM, q);
>  	}
>  
>  	if (sdkp->device->type == TYPE_ZBC) {

Although this patch looks fine to me, seeing this patch makes me wonder
whether the default should be changed (QUEUE_FLAG_MQ_DEFAULT) instead of
modifying the sd driver. Can anyone remind me why QUEUE_FLAG_MQ_DEFAULT does
not include QUEUE_FLAG_ADD_RANDOM?

Thanks,

Bart.