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.web11.2870.1573126639061916626 for ; Thu, 07 Nov 2019 03:37:19 -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-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (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 53B857C0A8 for ; Thu, 7 Nov 2019 11:37:18 +0000 (UTC) Received: by mail-wm1-f69.google.com with SMTP id x16so913287wmk.2 for ; Thu, 07 Nov 2019 03:37:18 -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=uz8YLhbDJw58qn6rfxKRJYLEsiNpzO0oItRitYqlaIc=; b=ZT53FZtPTVCJ8N97XKknPoi6sbyklEF2KuBEEqZBFDTth9kaRP2ABaqCVv9mZbSQEu gCB8xlzmHM9aD3nNhRFtNlwEGaiqhdIgNOi9MIsGQC/1Sz9gQf0DVzH0DwXUcuZ7ISyd oYNuwhfRJW7LRcfIiACqv4+qW0XxhQbpkCb3RjH+JjiG0CDvg5I1qoarbKy/M6dcaacA t4ze6uJwBA/+Evg8VgSDzD2rf+uZx3e/H5uSrOE2FYU87BzdCsgtaE7jgoxZ68Z0wSgM vFPlDKtCvrtVtib9NZzLOFQLnZwNFanyPXuAZhT01y7P1vz9yjsbIEt/LMlK1FMLVWjT iDdA== X-Gm-Message-State: APjAAAWeNg4h1eXapBLrt35TkV0C423mNSObi/qH3+j6O/QvaaSg7zO6 9Gw7BxNqlnEqbmhLjfhjg+ZLHGj6AUuoKQuHwqf/uxWHSD5WqAlawppjZ4Hotnv/cRAxdMk9SpN Yp20rgbq60Lx5Iw== X-Received: by 2002:a1c:cc18:: with SMTP id h24mr2545790wmb.40.1573126636032; Thu, 07 Nov 2019 03:37:16 -0800 (PST) X-Google-Smtp-Source: APXvYqyyJPN/JjEcfvGhNLcpsBg1/uzv0Vpp9ztZB8EtsQdh4uJqn51IiumLd3F04fWajyIiXHMziw== X-Received: by 2002:a1c:cc18:: with SMTP id h24mr2545770wmb.40.1573126635696; Thu, 07 Nov 2019 03:37:15 -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 h205sm1891358wmf.35.2019.11.07.03.37.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Nov 2019 03:37:15 -0800 (PST) Subject: Re: privileged entropy sources in QEMU/KVM guests To: Ard Biesheuvel , Laszlo Ersek 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> From: "Paolo Bonzini" Openpgp: preference=signencrypt Message-ID: Date: Thu, 7 Nov 2019 12:37:11 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/11/19 11:25, Ard Biesheuvel wrote: >> This looks problematic on QEMU. Entropy is a valuable resource, and >> whatever resource SMM drivers depend on, should not be possible for e.= g. >> a 3rd party UEFI driver (or even for the runtime OS) to exhaust. >> Therefore, it's not *only* the case that SMM drivers must not consume >> EFI_RNG_PROTOCOL (which exists at a less critical privilege level, i.e= . >> outside of SMM/SMRAM), but also that SMM drivers must not depend on th= e >> same piece of *hardware* that feeds EFI_RNG_PROTOCOL. >> > The typical model is to seed a DRBG [deterministic pseudorandom > sequence generator] using a sufficient amount of high quality entropy. > Once you have done that, it is rather hard to exhaust a DRBG - it is a > mathematical construction that is designed to last for a long time (<=3D > 2^48 invocations [not bytes] according to the NIST spec), after which > it does not degrade although it may have generated so much output that > its internal state may be inferred if you have captured enough of it > (which is a rather theoretical issue IMHO) >=20 > The problem is that using the output of a DRBG as a seed is > non-trivial - the spec describes ways to do this, but wiring > virtio-rng to a DRBG in the host and using its output to seed a DRBG > in the guest is slighly problematic. >=20 > So it seems to me that the correct way to model this is to make the > host's true entropy source a shared resource like any other. >=20 Yes, I would make SMM use a cryptographic pseudo-random number generator=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. Paolo #define ROTL(a,b) (((a) << (b)) | ((a) >> (32 - (b)))) #define QR(a, b, c, d) ( \ a +=3D b, d ^=3D a, d =3D ROTL(d,16), \ c +=3D d, b ^=3D c, b =3D ROTL(b,12), \ a +=3D b, d ^=3D a, d =3D ROTL(d, 8), \ c +=3D d, b ^=3D c, b =3D ROTL(b, 7)) #define ROUNDS 20 // initial state: // in[0] =3D 0x65787061 // in[1] =3D 0x6e642033 // in[2] =3D 0x322d6279 // in[3] =3D 0x7465206b // in[4]..in[11] =3D key (seed) // in[12]..in[13] =3D 0 // in[14]..in[15] =3D nonce, can probably use RDTSC? static uint32_t in[16]; uint32_t chacha_rng(void) { int i; static uint32_t x[16], p; if (p < 16) return in[p++] + x[p++]; if (++in[12] =3D=3D 0) ++in[13]; for (i =3D 0; i < 16; ++i) x[i] =3D in[i]; // 10 loops =C3=97 2 rounds/loop =3D 20 rounds for (i =3D 0; i < ROUNDS; i +=3D 2) { // Odd round QR(x[0], x[4], x[ 8], x[12]); // column 0 QR(x[1], x[5], x[ 9], x[13]); // column 1 QR(x[2], x[6], x[10], x[14]); // column 2 QR(x[3], x[7], x[11], x[15]); // column 3 // Even round QR(x[0], x[5], x[10], x[15]); // diagonal 1 (main diagonal) QR(x[1], x[6], x[11], x[12]); // diagonal 2 QR(x[2], x[7], x[ 8], x[13]); // diagonal 3 QR(x[3], x[4], x[ 9], x[14]); // diagonal 4 } p =3D 1; return in[0] + x[0]; }