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 42325C433E7 for ; Sat, 17 Oct 2020 07:19:45 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B6E1420758 for ; Sat, 17 Oct 2020 07:19:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6E1420758 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:56274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTgVD-0002bJ-TM for qemu-devel@archiver.kernel.org; Sat, 17 Oct 2020 03:19:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kTgTT-0000Zp-Gd for qemu-devel@nongnu.org; Sat, 17 Oct 2020 03:17:55 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:43865 helo=1wt.eu) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTgTR-0005he-JW for qemu-devel@nongnu.org; Sat, 17 Oct 2020 03:17:54 -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 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) Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/17 01:37:18 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jason Donenfeld , KVM list , "open list:DOCUMENTATION" , ghammer@redhat.com, "Weiss, Radu" , Qemu Developers , "open list:VIRTIO GPU DRIVER" , Pavel Machek , Colm MacCarthaigh , Jonathan Corbet , "Michael S. Tsirkin" , Eric Biggers , "Singh, Balbir" , bonzini@gnu.org, "Graf \(AWS\), Alexander" , oridgar@gmail.com, "Catangiu, Adrian Costin" , Andy Lutomirski , Michal Hocko , "Theodore Y. Ts'o" , Greg Kroah-Hartman , kernel list , Linux API , "Rafael J. Wysocki" , "Woodhouse, David" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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