From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by mx.groups.io with SMTP id smtpd.web11.2302.1573122323283356151 for ; Thu, 07 Nov 2019 02:25:23 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=EiwVPdHx; spf=pass (domain: linaro.org, ip: 209.85.128.47, mailfrom: ard.biesheuvel@linaro.org) Received: by mail-wm1-f47.google.com with SMTP id a17so3740413wmb.0 for ; Thu, 07 Nov 2019 02:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qAdGETN6AixEqw+ThOSssQbz6q56ocX/c6J8cAihWig=; b=EiwVPdHxSxG04If6SrQjC03OgSWjUnB9hiG0bwTKeoH7Z8sTsKsneDW86ZtZIMp41w nVaQConMSHp94cgKobmgpfsqvYTaP/3XB4vYS0Lphq8cH1deKqEMMyXlsSGe2pyFsBfh shvA1T6bzI6T7nNoeKPO7f48dzXqFLXJ4ZEkJnaYcWusF8ZC9lzpT8ccB5oqCb9sQdOq 6EKyGFBtputXZVP5yS16zv5skRqeEl1JauhufcAogR/VEqcVt+jyef+Aelhd4NU9BgMM iKQhJtcjb2BEidKE4iqFRPT/adGdHpU3KrebMytX/QQQELMbndT9ivIiOkrc4GOJyyzQ elsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qAdGETN6AixEqw+ThOSssQbz6q56ocX/c6J8cAihWig=; b=Ro1UCz0ITf2WOpXhHfbSu+G7V5H8khVQp9FwZQ5B4y0plEl6rb2H1hY5C4BIikhgXX Tp6fU1PVzUzSyEpHn5fFOY/pteCshntSwGyv6kNU7XQFU9vW8NQiiUTvwwXQmnihiSr8 iJUVRpYmcXGx6TCcUc7wlNpneMIrGZYPnMVkLkjEfBs5Uu5HFU3RWDPpKAmV/ye8hL+6 jT9LGtH4sFWvhja88NRMFr9TBAk2QsoQQQlFhJaruoIgSU/0zNQZDSpgRhtHIwexB+Mx z+xRenZs/Fjxv2n/CLUbokFLe20LAdpEz+TpgayLQyXblPXaYPOaOHAsLi2YXgteIhfr 1MTQ== X-Gm-Message-State: APjAAAWTDt1V542fQL7G3aIfcZpaIctALukdIyyrTHLOXyfgILr/nqUt emFkcQ+r89l3l+3zocBWCQ6dTnvfQh62YHD5c6klvw== X-Google-Smtp-Source: APXvYqy3QX1Gh2dO9py3eFifZjoRwObsWWYZcYFqejsGOV3ObuHly0OTAWUTrRrnWnadTzer6aWiSfKShJghuXaIqz4= X-Received: by 2002:a1c:b1c3:: with SMTP id a186mr2181483wmf.10.1573122321759; Thu, 07 Nov 2019 02:25:21 -0800 (PST) MIME-Version: 1.0 References: <03e769cf-a5ad-99ce-cd28-690e0a72a310@redhat.com> In-Reply-To: <03e769cf-a5ad-99ce-cd28-690e0a72a310@redhat.com> From: "Ard Biesheuvel" Date: Thu, 7 Nov 2019 11:25:10 +0100 Message-ID: Subject: Re: privileged entropy sources in QEMU/KVM guests To: Laszlo Ersek Cc: qemu devel list , "Daniel P. Berrange" , Paolo Bonzini , edk2-devel-groups-io , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Bret Barkelew , Sean Brogan , Jian J Wang , Erik Bjorge Content-Type: text/plain; charset="UTF-8" Hi Laszlo, Thanks for starting this thread. On Thu, 7 Nov 2019 at 11:11, Laszlo Ersek wrote: > > Hi, > > related TianoCore BZ: > > https://bugzilla.tianocore.org/show_bug.cgi?id=1871 > > (I'm starting this thread separately because at least some of the topics > are specific to QEMU, and I didn't want to litter the BZ with a > discussion that may not be interesting to all participants CC'd on the > BZ. I am keeping people CC'd on this initial posting; please speak up if > you'd like to be dropped from the email thread.) > > QEMU provides guests with the virtio-rng device, and the OVMF and > ArmVirtQemu* edk2 platforms build EFI_RNG_PROTOCOL on top of that > device. But, that doesn't seem enough for all edk2 use cases. > > Also, virtio-rng (hence EFI_RNG_PROTOCOL too) is optional, and its > absence may affect some other use cases. > > > (1) For UEFI HTTPS boot, TLS would likely benefit from good quality > entropy. If the VM config includes virtio-rng (hence the guest firmware > has EFI_RNG_PROTOCOL), then it should be used as a part of HTTPS boot. > > However, what if virtio-rng (hence EFI_RNG_PROTOCOL) are absent? Should > UEFI HTTPS boot be disabled completely (or prevented / rejected > somehow), blaming lack of good entropy? Or should TLS silently fall back > to "mixing some counters [such as TSC] together and applying a > deterministic cryptographic transformation"? > > IOW, knowing that the TLS setup may not be based on good quality > entropy, should we allow related firmware services to "degrade silently" > (not functionally, but potentially in security), or should we deny the > services altogether? > TLS uses a source of randomness to establish symmetric session keys for encryption. So it really depends on the use case whether HTTPS is used for authentication or for confidentiality, and it seems to me that it would typically be the former. So disabling HTTPS boot in this case seems counterproductive to me. > > (2) It looks like the SMM driver implementing the privileged part of the > UEFI variable runtime service could need access to good quality entropy, > while running in SMM; in the future. > > 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 the > 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 (<= 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) 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. 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. > Furthermore, assuming we dedicate a hardware entropy device specifically > to SMM drivers, such a device cannot be PCI(e). It would have to be a > platform device at a fixed location (IO port or MMIO) that is only > accessible to such guest code that executes in SMM. IOW, device access > would have to be restricted similarly to pflash. (In fact the variable > SMM driver will need, AIUI, the entropy for encrypting various variable > contents, which are then written into pflash.) > > Alternatively, CPU instructions could exist that return entropy, and are > executable only inside SMM. It seems that e.g. RDRAND can be trapped in > guests ("A VMEXIT due to RDRAND will have exit reason 57 (decimal)"). > Then KVM / QEMU could provide any particular implementation we wanted -- > for example an exception could be injected unless RDRAND had been > executed from within SMM. Unfortunately, such an arbitrary restriction > (of RDRAND to SMM) would diverge from the Intel SDM, and would likely > break other (non-SMM) guest code. > > Does a platform device that is dynamically detectable and usable in SMM > only seem like an acceptable design for QEMU? >