From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web11.4035.1573133624193722655 for ; Thu, 07 Nov 2019 05:33:44 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bclaJV3v; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573133623; 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=hne8Xc9Prw56eV219P4K2oThuCZJY7wVOK3aW/c/52A=; b=bclaJV3vYNtuVVMXFqBB4k6I0UAx1yRD6VBYkifHjnSNR+c2roEgJnIT0Q/VZA0pVXQ0Ff bNYTObTgCcbZF92VScLwpNouggeI+wwNnY1jRPIWPDCOmMa9Hhbmxu7dew/yq6hcIfTfxy qkUSYeqn45t5QBVer1+ewcAt6lv5zro= 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-241-xznmCGDMPz2FDbiVBnClKw-1; Thu, 07 Nov 2019 08:33:40 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BC144477; Thu, 7 Nov 2019 13:33:38 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (unknown [10.36.118.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8F38A196AE; Thu, 7 Nov 2019 13:33:33 +0000 (UTC) Subject: Re: privileged entropy sources in QEMU/KVM guests To: Paolo Bonzini , =?UTF-8?Q?Daniel_P._Berrang=c3=a9?= Cc: Ard Biesheuvel , Jian J Wang , edk2-devel-groups-io , Bret Barkelew , qemu devel list , Erik Bjorge , Sean Brogan , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= References: <03e769cf-a5ad-99ce-cd28-690e0a72a310@redhat.com> <20191107115511.GE120292@redhat.com> <19fc6a42-e773-f8b8-db4a-c8ed853da30c@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 7 Nov 2019 14:33:33 +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: <19fc6a42-e773-f8b8-db4a-c8ed853da30c@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: xznmCGDMPz2FDbiVBnClKw-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:50, Paolo Bonzini wrote: > On 07/11/19 12:55, Daniel P. Berrang=C3=A9 wrote: >>> Yes, I would make SMM use a cryptographic pseudo-random number generato= r=20 >>> and seed it from virtio-rng from DXE, way before the OS starts and can= =20 >>> "attack" it. >>> >>> Once you've gotten a seed, you can create a CSPRNG with a stream cipher= =20 >>> such as ChaCha20, which is literally 30 lines of code. >> If all we need is a one-time seed then virtio-rng is possibly overkill a= s >> that provides a continuous stream. Instead could QEMU read a few bytes >> from the host's /dev/urandom and pass it to EDK via fw_cfg, which can >> use it for the CSPRNG seed. EDK would have to erase the fw_cfg field >> to prevent the seed value leaking to the guest OS, but other than that >> its quite straightforward. >=20 > That would need anyway a change to the emulated hardware. If the guest > is able to use virtio-rng after the firmware exits (which is the case is > all the firmware needs is a one-time seed), then using virtio-rng is the > simplest alternative as it needs no change at all outside the firmware. This is a really good point! I'll think more about using virtio-rng, hopefully without horribly hacking OVMF's BDS code. Thanks Laszlo