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 B898FC433E7 for ; Sat, 17 Oct 2020 06:32:11 +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 07A6120760 for ; Sat, 17 Oct 2020 06:32:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 07A6120760 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]:33844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTflB-0004yh-M4 for qemu-devel@archiver.kernel.org; Sat, 17 Oct 2020 02:32:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kTeuR-0008RM-GL for qemu-devel@nongnu.org; Sat, 17 Oct 2020 01:37:39 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:43835 helo=1wt.eu) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTeuP-0004tC-Dm for qemu-devel@nongnu.org; Sat, 17 Oct 2020 01:37:38 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 09H5bCCa014109; Sat, 17 Oct 2020 07:37:12 +0200 Date: Sat, 17 Oct 2020 07:37:12 +0200 From: Willy Tarreau To: Jann Horn Subject: Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver Message-ID: <20201017053712.GA14105@1wt.eu> References: <788878CE-2578-4991-A5A6-669DCABAC2F2@amazon.com> <20201017033606.GA14014@1wt.eu> <6CC3DB03-27BA-4F5E-8ADA-BE605D83A85C@amazon.com> 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-Mailman-Approved-At: Sat, 17 Oct 2020 02:27:20 -0400 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 07:01:31AM +0200, Jann Horn wrote: > Microsoft's documentation > (http://go.microsoft.com/fwlink/?LinkId=260709) says that the VM > Generation ID that we get after a fork "is a 128-bit, > cryptographically random integer value". If multiple people use the > same image, it guarantees that each use of the image gets its own, > fresh ID: No. It cannot be more unique than the source that feeds that cryptographic transformation. All it guarantees is that the entropy source is protected from being guessed based on the output. Applying cryptography on a simple counter provides apparently random numbers that will be unique for a long period for the same source, but as soon as you duplicate that code between users and they start from the same counter they'll get the same IDs. This is why I think that using a counter is better if you really need something unique. Randoms only reduce predictability which helps avoiding collisions. And I'm saying this as someone who had on his external gateway the same SSH host key as 89 other hosts on the net, each of them using randoms to provide a universally unique one... Willy