linux-kernel - Re: [PATCH 2/3] random: provide notifier for 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: <CAHmME9r4P+5pdrRxaUZs96nshp7rN4GP2xoV9h=umqMOAgs8iA@mail.gmail.com>
Date:   Wed, 2 Mar 2022 12:41:46 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Alexander Graf <graf@...zon.com>, Jann Horn <jannh@...gle.com>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        "Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH 2/3] random: provide notifier for VM fork

Hi Greg,

On Wed, Mar 2, 2022 at 9:53 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> It seems crazy that the "we just were spawned as a new vm" notifier is
> based in the random driver, but sure, put it here for now!  :)

I was thinking you might say this. I see it both ways, but I think I'm
more inclined to doing it this way, at least for now. Here's how it
breaks down:

VM forking is usually an okay thing to do because computers are
deterministic. Usually. Where is there non-determinism in a place that
it matters? The RNG is supposed to be "the" place of non-determinism.
If anything is going to happen in response to a VM fork, it's going to
necessarily be _after_ the RNG becomes sufficiently non-deterministic
again, and so it's the RNG who announces, "hey I'm safe to use again,
and please read from me again if you're doing non-misuse resistant
crypto." It's the proper place to announce that.

On the other hand, I think you could argue that really this should
come from vmgenid itself, with the caveat that the notifier is called
after add_vmfork_randomness is called. For now that would exist in
vmgenid.o itself, and then if we ever have multiple drivers notifying,
some shared infrastructure could be made. Except vmgenid.o might be
vmgenid.ko, and then the whole problem gets kind of annoying and maybe
we actually want that shared infrastructure _now_ instead. And now we
find ourselves complicating everything with additional Kbuild symbols
and header files and stubs. It just seems like the road of more pain.

Anyway, even if we go with the first solution -- keeping it in
random.o -- now, I wouldn't be opposed to revisiting that decision
later if the landscape becomes more complex. Luckily this is just the
kernel side of things and not userspace, so we can easily change
things down the road.

Jason