From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19A9CC433DF for ; Sat, 17 Oct 2020 07:18:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D85FA20758 for ; Sat, 17 Oct 2020 07:18:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2411784AbgJQHSC (ORCPT ); Sat, 17 Oct 2020 03:18:02 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:43868 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2411783AbgJQHSC (ORCPT ); Sat, 17 Oct 2020 03:18:02 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 09H7HL0w014146; Sat, 17 Oct 2020 09:17:21 +0200 Date: Sat, 17 Oct 2020 09:17:21 +0200 From: Willy Tarreau To: Jann Horn Cc: Colm MacCarthaigh , "Catangiu, Adrian Costin" , Andy Lutomirski , Jason Donenfeld , "Theodore Y. Ts'o" , Eric Biggers , "open list:DOCUMENTATION" , kernel list , "open list:VIRTIO GPU DRIVER" , "Graf (AWS), Alexander" , "Woodhouse, David" , bonzini@gnu.org, "Singh, Balbir" , "Weiss, Radu" , oridgar@gmail.com, ghammer@redhat.com, Jonathan Corbet , Greg Kroah-Hartman , "Michael S. Tsirkin" , Qemu Developers , KVM list , Michal Hocko , "Rafael J. Wysocki" , Pavel Machek , Linux API Subject: Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver Message-ID: <20201017071721.GA14143@1wt.eu> References: <788878CE-2578-4991-A5A6-669DCABAC2F2@amazon.com> <20201017033606.GA14014@1wt.eu> <6CC3DB03-27BA-4F5E-8ADA-BE605D83A85C@amazon.com> <20201017053712.GA14105@1wt.eu> <20201017064442.GA14117@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Sat, Oct 17, 2020 at 08:55:34AM +0200, Jann Horn wrote: > My suggestion is to use a counter *in the UAPI*, not in the hypervisor > protocol. (And as long as that counter can only miss increments in a > cryptographically negligible fraction of cases, everything's fine.) OK I got it now and I agree. > > If what is sought is pure > > randomness (in the sense that it's unpredictable, which I don't think > > is needed here), then randoms are better. > > And this is what *the hypervisor protocol* gives us (which could be > very useful for reseeding the kernel RNG). As an external source, yes very likely, as long as it's not trivially observable by everyone under the same hypervisor :-) > > Now the initial needs in the forwarded message are not entirely clear > > to me but I wanted to rule out the apparent mismatch between the expressed > > needs for uniqueness and the proposed solutions solely based on randomness. > > Sure, from a theoretical standpoint, it would be a little bit nicer if > the hypervisor protocol included a generation number along with the > 128-bit random value. But AFAIU it doesn't, so if we want this to just > work under Microsoft's existing hypervisor, we'll have to make do with > checking whether the random value changed. :P OK got it, thanks for the explanation! Willy