linux-kernel - Re: [PATCH 2/2] random: add fork_event sysctl for polling VM forks

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:   Mon, 2 May 2022 21:41:57 +0200
From:   Alexander Graf <graf@...zon.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
CC:     Lennart Poettering <mzxreary@...inter.de>,
        <linux-kernel@...r.kernel.org>, <linux-crypto@...r.kernel.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Theodore Ts'o <tytso@....edu>,
        "Colm MacCarthaigh" <colmmacc@...zon.com>,
        Torben Hansen <htorben@...zon.co.uk>,
        Jann Horn <jannh@...gle.com>,
        "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
Subject: Re: [PATCH 2/2] random: add fork_event sysctl for polling VM forks


On 02.05.22 21:27, Jason A. Donenfeld wrote:
> On Mon, May 02, 2022 at 08:56:05PM +0200, Alexander Graf wrote:
>> On 02.05.22 20:46, Jason A. Donenfeld wrote:
>>> On Mon, May 02, 2022 at 08:34:38PM +0200, Alexander Graf wrote:
>>>> Michael, since we already changed the CID in the spec, can we add a
>>>> property to the device that indicates the first 4 bytes of the UUID will
>>>> always be different between parent and child?
>>>>
>>>> That should give us the ability to mmap the vmgenid directly to user
>>>> space and act based on a simple u32 compare for clone notification, no?
>>> That is not a good idea. We want an _additional_ 4 bytes, so that we can
>>> keep the first 16 bytes (128 bits) as a kernel space secret.
>>
>> An additional 4 bytes would be an additional 4kb (or 64kb on ARM) page.
>> Do we really rely on these 16 bytes to reseed after clone? If so, we'd
>> need to bite the bullet and provide an additional page, yes.
> Ugh, you're right; memory mapping is pages. The other option would be
> relying on RDRAND (both existing and being trusted by the user etc), but
> generally people aren't too jazzed about that. We pretty much have to
> assume that the existing pool is compromised, since people share cloned
> VMs casually. The 128-bit vmgenid is a nice input to have.


I can see the merit. So yes, we'd want a second function to the 
VM_GEN_COUNTER device in addition to "ADDR" that - in a fully user space 
mappable separate page - gives us a 32-bit vmgenid that is guaranteed to 
be different from the previous one.


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879