Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1738551pxu; Fri, 16 Oct 2020 22:45:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDlMX+MDp/nLy4tpfsXmDYCXRuE2JDGFKRwOiqU01pQatGvxVkkV3XGNonPlTwDS/s0hRX X-Received: by 2002:a17:906:4d03:: with SMTP id r3mr6902813eju.364.1602913528178; Fri, 16 Oct 2020 22:45:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602913528; cv=none; d=google.com; s=arc-20160816; b=TQANekKcJvQvNo42hXWYUFe0/ixGl6RHVse9PCPthvWdcMb88S+GpS8QU7vK71tx3P Kgps5IUj9QXQMSTPzz4y9oadjWBSxQOr+gpbA2LN32cEp6Im/8/2rWQ5CNDKI/1TQLiz EnhB9B6yiDWHjkjUeHrwHLIK6iswRfM3M+yDXB/nDPu3+luHlgukPF3HeGP+steIJCoJ sV6p0HZoXkrvNRXRLzivCCG6AVlnTXuXW5qSl8uJpmCFB4sFOczM+vYqrBXMMX+0oF9H BQVanu0v9gd18IcnsUahd3ESh4h1/yotD2uvVaWUI8I73ih0DkC406uI98X20CAEWNlR xueg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=A+xTdittLDjo9CZ6mkgakQT9qYMbeb8b8XH2px2ASgc=; b=l+vILSQd1i3oHCGiy+AAVUcgF1eIxNgVGYRy+zceiKWjikeU5g4Fa7xK0pUm7jnscO 8ZqYyAkU4je6JpdbNpLP7chBfqjj3vF0oB9JtEeu+kRLxp9ISUiNrlARxBqvRTz7Xy6B 4yE/g2OdNdh7n7cedPFiTXXEZ7gwjN+XjZ2EfY5pmv26cL1VGRBCRITL6tEzhiVi3WTG co8QDjnNGmt0+6YQX14vaKM2C5QiCmwDtZobauxROiG/nvXMsfKqlQdU9fkviQ0LLZM5 uV3BmbodxauliP/D20lEBALj4z8k5TyfRoCHmEFig9tEBazoe3DhZ6F7ljLk8XDGNJm8 neBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g13si3317009edu.259.2020.10.16.22.45.06; Fri, 16 Oct 2020 22:45:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2411848AbgJQFhp (ORCPT + 99 others); Sat, 17 Oct 2020 01:37:45 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:43838 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2410829AbgJQFho (ORCPT ); Sat, 17 Oct 2020 01:37:44 -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 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: <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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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