linux-kernel - Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

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: <Yhj1nYHXmimPsqFd@zx2c4.com>
Date:   Fri, 25 Feb 2022 16:28:29 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Alexander Graf <graf@...zon.com>
Cc:     kvm@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
        adrian@...ity.io, ardb@...nel.org, ben@...portsystems.com,
        berrange@...hat.com, colmmacc@...zon.com, decui@...rosoft.com,
        dwmw@...zon.co.uk, ebiggers@...nel.org, ehabkost@...hat.com,
        gregkh@...uxfoundation.org, haiyangz@...rosoft.com,
        imammedo@...hat.com, jannh@...gle.com, kys@...rosoft.com,
        lersek@...hat.com, linux@...inikbrodowski.net, mst@...hat.com,
        qemu-devel@...gnu.org, raduweis@...zon.com, sthemmin@...rosoft.com,
        tytso@....edu, wei.liu@...nel.org
Subject: Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing
 RNG on VM fork

Hi Alex,

On Fri, Feb 25, 2022 at 04:15:59PM +0100, Alexander Graf wrote:
> I'm not talking about a notification interface - we've gone through 
> great length on that one in the previous submission. What I'm more 
> interested in is *any* way for user space to read the current VM Gen ID. 
> The same way I'm interested to see other device attributes of my system 
> through sysfs.

Again, no. Same basic objection: we can do this later and design it
coherently with the rest. For example, maybe it's better to expose a
generation counter rather than 16 byte blob, and expect userspace to
call getrandom() subsequently to get something fresh. Or not! But maybe
it should be hashed with a fixed prefix string before being exposed to
userspace. Or not! I don't know, but that's not going to happen on this
patchset. There is no reason at all why that needs to be done here and
now. Trying to do too much at the same time is likely why the previous
efforts from your team stalled out last year. Propose something later,
in a new thread, and we can discuss then. One step at a time...

Jason