From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752694AbcFUSYP (ORCPT ); Tue, 21 Jun 2016 14:24:15 -0400 Received: from mail-it0-f50.google.com ([209.85.214.50]:38288 "EHLO mail-it0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751530AbcFUSYN (ORCPT ); Tue, 21 Jun 2016 14:24:13 -0400 X-Greylist: delayed 90994 seconds by postgrey-1.27 at vger.kernel.org; Tue, 21 Jun 2016 14:24:13 EDT Subject: Re: [PATCH v4 0/5] /dev/random - a new approach To: Tomas Mraz , Stephan Mueller References: <1466007463.20087.11.camel@redhat.com> <3381856.qSaz1KcX2Z@positron.chronox.de> <8999970.pstTbGZv5G@positron.chronox.de> <6b8c8f6a-862a-3e7c-e950-75cd93cdc1f7@gmail.com> <1466515196.17017.8.camel@redhat.com> Cc: "Theodore Ts'o" , =?UTF-8?Q?David_Ja=c5=a1a?= , Andi Kleen , sandyinchina@gmail.com, Jason Cooper , John Denker , "H. Peter Anvin" , Joe Perches , Pavel Machek , George Spelvin , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org From: "Austin S. Hemmelgarn" Message-ID: Date: Tue, 21 Jun 2016 13:18:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1466515196.17017.8.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-06-21 09:19, Tomas Mraz wrote: > On Út, 2016-06-21 at 09:05 -0400, Austin S. Hemmelgarn wrote: >> On 2016-06-20 14:32, Stephan Mueller wrote: >>> >>> [1] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf >> Specific things I notice about this: >> 1. QEMU systems are reporting higher values than almost anything >> else >> with the same ISA. This makes sense, but you don't appear to have >> accounted for the fact that you can't trust almost any of the entropy >> in >> a VM unless you have absolute trust in the host system, because the >> host >> system can do whatever the hell it wants to you, including >> manipulating >> timings directly (with a little patience and some time spent working >> on >> it, you could probably get those number to show whatever you want >> just >> by manipulating scheduling parameters on the host OS for the VM >> software). > > You have to trust the host for anything, not just for the entropy in > timings. This is completely invalid argument unless you can present a > method that one guest can manipulate timings in other guest in such a > way that _removes_ the inherent entropy from the host. When dealing with almost any type 2 hypervisor, it is fully possible for a user other than the one running the hypervisor to manipulate scheduling such that entropy is reduced. This does not imply that the user who is doing this has any other control over the target VM, and importantly, often does not require administrative access on the host, only regular user access. Such an attack is very difficult to effect outside of a clean-room environment, but is still possible. You can't use this to force generation of arbitrary data, but you can definitely starve a VM for entropy. By nature, something that relies on interrupt timings will be more impacted by such an attack than something that does not. In most cases, such an attack will be a DoS attack on the host as well (as that's the simplest way to do this). This is less of an issue with proper practices on a type 1 hypervisor, but is still possible there too (although pulling this off on at least Xen when you have proper VCPU isolation is functionally impossible without administrative access to the control domain).