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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 EEA18C4363A for ; Sun, 18 Oct 2020 03:15:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB3A520866 for ; Sun, 18 Oct 2020 03:15:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="p1tEFy1Z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725919AbgJRDO6 (ORCPT ); Sat, 17 Oct 2020 23:14:58 -0400 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:55809 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725272AbgJRDO5 (ORCPT ); Sat, 17 Oct 2020 23:14:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1602990896; x=1634526896; h=from:to:cc:date:message-id:in-reply-to:references: mime-version:content-transfer-encoding:subject; bh=kIh+rRe+DAK991cXZIDGGhSKZFK3HLJICasoN4MVkPs=; b=p1tEFy1Zye/SOQhYaLeT6QwLv0nk0xZO7pJpCbV/HDQiJagPDBG9mG6+ 4dkZRDwJpXl+sk4J0A5xPC7pAbTM1aq+iLvv1a96NBDW0lsFKhd7NzwGX bD3nyU53Y9IDXg6609aC1a5nWndYQxp6l2Q6nBxyoLFQzDkiCm/t30/Jq E=; X-IronPort-AV: E=Sophos;i="5.77,388,1596499200"; d="scan'208";a="85580626" Subject: Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-87a10be6.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 18 Oct 2020 03:14:50 +0000 Received: from EX13MTAUWA001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-87a10be6.us-west-2.amazon.com (Postfix) with ESMTPS id 3B7C8A1D8B; Sun, 18 Oct 2020 03:14:49 +0000 (UTC) Received: from EX13D01UWA003.ant.amazon.com (10.43.160.107) by EX13MTAUWA001.ant.amazon.com (10.43.160.58) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 18 Oct 2020 03:14:48 +0000 Received: from [10.50.20.109] (10.43.160.125) by EX13d01UWA003.ant.amazon.com (10.43.160.107) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 18 Oct 2020 03:14:48 +0000 From: Colm MacCarthaigh To: "Jason A. Donenfeld" CC: Jann Horn , Willy Tarreau , "Catangiu, Adrian Costin" , Andy Lutomirski , "Theodore Y. Ts'o" , Eric Biggers , "open list:DOCUMENTATION" , kernel list , "open list:VIRTIO GPU DRIVER" , "Graf (AWS), Alexander" , "Woodhouse, David" , , "Singh, Balbir" , "Weiss, Radu" , , , Jonathan Corbet , Greg Kroah-Hartman , "Michael S. Tsirkin" , Qemu Developers , KVM list , Michal Hocko , "Rafael J. Wysocki" , Pavel Machek , Linux API Date: Sat, 17 Oct 2020 20:14:47 -0700 X-Mailer: MailMate Trial (1.13.2r5673) Message-ID: <6A556D58-04B7-4FC6-A7F9-138BD7E41731@amazon.com> In-Reply-To: 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="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.43.160.125] X-ClientProxiedBy: EX13D36UWB002.ant.amazon.com (10.43.161.149) To EX13d01UWA003.ant.amazon.com (10.43.160.107) Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 17 Oct 2020, at 6:24, Jason A. Donenfeld wrote: > There are a few design goals of notifying userspace: it should be > fast, because people who are using userspace RNGs are usually doing so > in the first place to completely avoid syscall overhead for whatever > high performance application they have - e.g. I recall conversations > with Colm about his TLS implementation needing to make random IVs > _really_ fast. That’s our old friend TLS1.1 in CBC mode, which needs a random explicit IV for every record sent. Speed is still a reason at the margins in cases like that, but getrandom() is really fast. A stickier problem is that getrandom() is not certified for use with every compliance standard, and those often dictate precise use of some NIST DRBG or NRBG construction. That keeps people proliferating user-space RNGs even when speed isn’t as important. > It should also happen as early as possible, with no > race or as minimal as possible race window, so that userspace doesn't > begin using old randomness and then switch over after the damage is > already done. +1 to this, and I’d add that anyone making VM snapshots that they plan to restore from multiple times really needs to think this through top to bottom. The system would likely need to be put in to some kind of quiescent state when the snapshot is taken. > So, anyway, here are a few options with some pros and cons for the > kernel notifying userspace that its RNG should reseed. > > 1. SIGRND - a new signal. Lol. > > 2. Userspace opens a file descriptor that it can epoll on. Pros are > that many notification mechanisms already use this. Cons is that this > requires syscall and might be more racy than we want. Another con is > that this a new thing for userspace programs to do. A library like OpenSSL or BoringSSL also has to account for running inside a chroot, which also makes this hard. > Any thoughts on 4c? Is that utterly insane, or does that actually get > us somewhere close to what we want? I still like 4c, and as a user-space crypto-person, and a VM person, they have a lot of appeal. Alex and Adrian’s replies get into some of the sufficiency challenge. But for user-space libraries like the *SSLs, the JVMs, and other runtimes where RNGs show up, it could plug in easily enough. - Colm