From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.groups.io with SMTP id smtpd.web10.4344.1573135114832213937 for ; Thu, 07 Nov 2019 05:58:34 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: pbonzini@redhat.com) Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4399BC04FF80 for ; Thu, 7 Nov 2019 13:58:34 +0000 (UTC) Received: by mail-wr1-f70.google.com with SMTP id z9so1069383wrq.11 for ; Thu, 07 Nov 2019 05:58:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Pth5O67QkmYj65OQSszsmoJLqCJ0DrQJ04ZmzMDHRHA=; b=OtyoK6cFFiFcGiBAXZaGecdGn9Tqq5roErMirOPlDXJgH6Y0nLcxXip8BszCKOUSu/ GrP2vmtVlWwfOttjuttpj0mV/lRW+d9mluqBrppYKUWxU7me4aOIfVnCPM9ANvB66STq 5sZN50gifiIP+q81riz0gKb5vFeEDGl67D5GA7mGPvVa7DaRRCMizhlJOhm2eromtCiX X9QK/b1IstyO0FrBIu2IYsm+jctM3e+3g7y9EAlB0Eu53A8Auk7lfH64kd4CyFwfyWZ1 kASNgpLCk0UR7Jv4W6pBZqaH7tTk55Xd32FjG556RJvp+horSTxTo/g3mq4dve4K1H0F ludw== X-Gm-Message-State: APjAAAXOZkrhB+3d5FYhTEy0pBN44UcAPzS3YWT2EDtyXBgP06GRhaKn aUwneG6A6Jwk5nxYXFdvRvngI9CFj3hr2i9dIOK588p27YhToBtSbEsfE+Fgb18Jzg2t8V0Ei6p o/jkbU12iya4diA== X-Received: by 2002:a5d:664f:: with SMTP id f15mr2931090wrw.8.1573135112841; Thu, 07 Nov 2019 05:58:32 -0800 (PST) X-Google-Smtp-Source: APXvYqx8sEBUHDkb92/a1fWARFt+OBCx5sO5Jgiz8nb4ef/XJ1/6wjjiseE6lbAhrz8PAicVWqt2TQ== X-Received: by 2002:a5d:664f:: with SMTP id f15mr2931067wrw.8.1573135112559; Thu, 07 Nov 2019 05:58:32 -0800 (PST) Received: from [10.201.49.199] (nat-pool-mxp-u.redhat.com. [149.6.153.187]) by smtp.gmail.com with ESMTPSA id y78sm3137911wmd.32.2019.11.07.05.58.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Nov 2019 05:58:32 -0800 (PST) Subject: Re: privileged entropy sources in QEMU/KVM guests To: Laszlo Ersek , Ard Biesheuvel Cc: qemu devel list , "Daniel P. Berrange" , edk2-devel-groups-io , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Bret Barkelew , Sean Brogan , Jian J Wang , Erik Bjorge References: <03e769cf-a5ad-99ce-cd28-690e0a72a310@redhat.com> <421cf4ef-ea84-c7e6-81aa-c24a91459de5@redhat.com> From: "Paolo Bonzini" Openpgp: preference=signencrypt Message-ID: <659cd76f-2f46-1e08-342b-ee2fa0877fd8@redhat.com> Date: Thu, 7 Nov 2019 14:58:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <421cf4ef-ea84-c7e6-81aa-c24a91459de5@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 07/11/19 14:27, Laszlo Ersek wrote: > The VirtioRngDxe driver is a UEFI driver that follows the UEFI driver > model. Meaning (in this context), it is connected to the virtio-rng > device in the BDS phase, by platform BDS code. > > Put differently, the non-privileged driver that's the source of the > sensitive data would have to be a "platform DXE driver". The virtio > drivers are not such drivers however. Yes, it would have to be a platform DXE driver. What is it that limits virtio to the BDS phase? Paolo