linux-kernel - SCSI device probing non-deterministic in 5.3

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-next>] [day] [month] [year] [list]

Message-ID: <d2ff27ce-67b0-735e-8652-0e925d5f756c@linode.com>
Date:   Thu, 3 Oct 2019 16:32:45 -0400
From:   Bradley LaBoon <blaboon@...ode.com>
To:     linux-kernel@...r.kernel.org
Subject: SCSI device probing non-deterministic in 5.3

Hello, LKML!

Beginning with kernel 5.3 the order in which SCSI devices are probed and
named has become non-deterministic. This is a result of a patch that was
submitted to add asynchronous device probing (specifically, commit
f049cf1a7b6737c75884247c3f6383ef104d255a). Previously, devices would
always be probed in the order in which they exist on the bus, resulting
in the first device being named 'sda', the second device 'sdb', and so on.

This is important in the case of mass VM deployments where many VMs are
created from a single base image. Partition UUIDs cannot be used in the
fstab of such an image because the UUIDs will be different for each VM
and are not known in advance. Normally you can't rely on device names
being consistent between boots, but with QEMU you can set the bus order
of each block device and thus we currently use that to control the
device order in the guest. With the introduction of the aforementioned
patch this is no longer possible and the device ordering is different on
every boot, resulting in the guest booting into an emergency shell
unless the devices randomly happen to be loaded in the expected order.

I have created a patch which reverts back to the previous behavior, but
I wanted to open this topic to discussion before posting it. I'm not
totally familiar with the low-level details of SCSI device probing, so I
don't know if the non-deterministic device order was the intended
behavior of the patch or just a side-effect. If that is the intended
behavior then is there perhaps some other way to ensure a consistent
device ordering for a guest VM?

I am not subscribed to the list, so please CC me on any replies.

Thank you!
Bradley LaBoon