From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web12.27903.1629966701213301743 for ; Thu, 26 Aug 2021 01:31:41 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Je7E9KQu; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629966700; 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: in-reply-to:in-reply-to:references:references; bh=CjYrUftDsorTkcu7redFBCTlUcwThIuqaazRzuLzpeU=; b=Je7E9KQucntGAy1UHMX8vvJL0Aoo5FqVcIYnnGunHWumXZDHCiP/ayxR38wLH0sRF9TMcj 1ZhLqdbAuM4sZFfzBpDFMxhkoVkaZMHTJ6fom8wRKpVp/OCkjcBRT2jZU3zkwqyfWyA8BC 9K7AmSZLJQjLq9VAQ0Fxf4qaUcFaDA0= 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-284-jCa4G_tIOMKBaFgI3nlg9A-1; Thu, 26 Aug 2021 04:31:36 -0400 X-MC-Unique: jCa4G_tIOMKBaFgI3nlg9A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F344B802936; Thu, 26 Aug 2021 08:31:34 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EBD385C25A; Thu, 26 Aug 2021 08:31:33 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 57D2B18003AA; Thu, 26 Aug 2021 10:31:32 +0200 (CEST) Date: Thu, 26 Aug 2021 10:31:32 +0200 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , "Xu, Min M" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , Tom Lendacky , "Yamahata, Isaku" Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c Message-ID: <20210826083132.owdvtvylzklskc4q@sirius.home.kraxel.org> References: <20210819064937.o646vxjebwzgfgoz@sirius.home.kraxel.org> <20210820072253.plne3mudm3dj6777@sirius.home.kraxel.org> <20210825075218.mpmkcwu3zo6tykm2@sirius.home.kraxel.org> <20210825145143.rp3gqcqzd6fktkjk@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > Some reference for QEMU: > https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg01682.html Ah, good. /me adds an entry to the todo list. > > > The fw_cfg is still allowed in the TDVF design guide, just because we > > > feel it is a burden to convert everything suddenly. > > > > What is the longer-term plan here? > > > > Does it make sense to special-case the memory map? > > > > If we want handle other fw_cfg items that way too later on, shouldn't we > > better check how we can improve the fw_cfg interface so it works better > > with confidential computing? > > [Jiewen] So far, my hope is to limit the fw_cfg as much as possible. > My worry is that we have to measure fw_cfg everywhere. If we miss one place, it will be a completeness vulnerability for trusted computing. > > I also think if we can add measurement code inside of fw_cfg get function. > Then we need improve the FwCfg API - Current style: QemuFwCfgSelectItem() + QemuFwCfgReadxxx() is not friendly for measurement. For example, we can combine them and do QemuFwCfgSelectRead (). I was more thinking about a completely different way to pass (constant) fw_cfg data. Something like defining a fw_cfg hob and adding that to the td hob. QemuFwCfgLib could lookup the hob and use that when it finds the needed entry there. In case the entry is not there try use io instead. We'll continue to need that for the acpi tables for example, these entries are not constant. qemu will adapt them when the firmware maps hardware resources referenced in acpi tables (mmconfig region, power management registers, ...). > The QemuFwCfgWritexxx() interface may also bring inconsistency issue. > If we use this API, we have 2 copy data. Do you need any writable fw_cfg entries in TDX mode? 'git grep' shows the ramfb driver, smi feature negotiation and s3 support use QemuFwCfgWrite() > One is in TDVF (trusted), and > the other is in VMM/QEMU (untrusted). What if the VMM modifies its > untrusted copy? > What I can see is many potential attack surfaces. :-( Well, you have to trust VMM/QEMU to a certain degree. TDX can prevent data leaking, but it can't prevent VMM misbehaving. > Please let me know if you need any other information. Sure. For now I have to read more docs and patches ... take care, Gerd