From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web12.4196.1573134273288706084 for ; Thu, 07 Nov 2019 05:44:33 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R8h8nnCi; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573134272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MtTv65/cUTSV/C5FC9Kyjuj/mKdxOnEinOVdFDzlhIs=; b=R8h8nnCif2s7kCM91+mhqv37/0YS8vUnaxUzue4UG/wwRZ3WOMuFGGMi66OQ0SQLvZ/SgS bdl/EUEt0WWjsVio5+FuCntP7nFAz2puKp1oRnPEAX683mSaeDdF5yBvFBge8DjJfbaCX1 qik949kc1YVQwYj0IVmYAoUg/wpa37Q= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-228-UR4GN-N1OKO43jlNzUUIHQ-1; Thu, 07 Nov 2019 08:44:26 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4D1D91005500; Thu, 7 Nov 2019 13:44:25 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.36.118.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id A30115D72D; Thu, 7 Nov 2019 13:44:12 +0000 (UTC) Subject: Re: privileged entropy sources in QEMU/KVM guests To: Paolo Bonzini , =?UTF-8?Q?Daniel_P._Berrang=c3=a9?= Cc: qemu devel list , Ard Biesheuvel , Jian J Wang , edk2-devel-groups-io , Bret Barkelew , Erik Bjorge , Sean Brogan , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= References: <03e769cf-a5ad-99ce-cd28-690e0a72a310@redhat.com> <20191107115203.GD120292@redhat.com> <31917972-da28-8e0d-432d-1cb7607ff3e7@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 7 Nov 2019 14:44:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <31917972-da28-8e0d-432d-1cb7607ff3e7@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: UR4GN-N1OKO43jlNzUUIHQ-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/07/19 13:47, Paolo Bonzini wrote: > On 07/11/19 12:52, Daniel P. Berrang=C3=A9 wrote: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi= t/?id=3Dbb5530e4082446aac3a3d69780cd4dbfa4520013 >> >> Is it practical to provide a jitter entropy source for EDK2 >> too ? >=20 > The hard part is not collecting jitter (though the firmware might be too > deterministic for that), but rather turning it into a random number seed > (mixing data from various sources, crediting entropy, etc.). If there is *any* entropy source that (a) we can trust to be random enough and (b) depends only on the CPU, then we shouldn't struggle with virtio-rng (or similar devices) at all. RDRAND would be a no-brainer, but the "community literature" suggests it should not be trusted in itself. I've read the commit message linked above, and it appears too good to be true. The CPU Jitter RNG provides a source of good entropy by collecting CPU executing time jitter. [...] The RNG does not have any dependencies on any other service in the kernel. The RNG only needs a high-resolution time stamp. [...] http://www.chronox.de/jent.html The CPU Jitter Random Number Generator provides a non-physical true random number generator that works equally in kernel and user land. The only prerequisite is the availability of a high-resolution timer that is available in modern CPUs. http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html Today=E2=80=99s operating systems provide non-physical true random numb= er generators which are based on hardware events. With the advent of virtualization and the ever growing need of more high-quality random numbers, these random number generators reach their limits. Additional sources of entropy must be opened up. This document introduces an entropy source based on CPU execution time jitter. The design and implementation of a non-physical true random number generator, the CPU Jitter random number generator, its statistical properties and the maintenance and behavior of entropy is discussed in this document. If this construct is legit, a core edk2 implementation (available to all platforms, and on all edk2 arches) would be a huge win. On the other hand, we're having this discussion because the premise of TianoCore#1871 is that we shouldn't rely on just the CPU and a high resolution timer... I simply cannot decide if this construct is trustworthy. (With any solution that was based in the host's /dev/random or /dev/urandom, the trustworthiness question would be side-stepped in the firmware.) Laszlo