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.web11.3629.1630405287998539630 for ; Tue, 31 Aug 2021 03:21:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VpXBG5d2; 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=1630405287; 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=IhKivjRBucekfPvBH5jCoFFMK0hsVzUQLEOrzswOkHo=; b=VpXBG5d2ouZKiYx2gxVGftRPV6FzP6ZKw7CoSAzv1N2Ho3AqQ+AgV0lpRLNhAW1bPPUAnS qkQrTglBSlmyLoVi957niiBxsQqwUHJe6QzSxVy8voCzyGxlFKEbR+5OU80lsrrp6XjlTo 1qvpzI8WzMTEzP/UGBLEczaj/c9pq00= 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-330-_9fVwUXzN_2sBRb7aK0o3w-1; Tue, 31 Aug 2021 06:21:23 -0400 X-MC-Unique: _9fVwUXzN_2sBRb7aK0o3w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1CDCA107ACF5; Tue, 31 Aug 2021 10:21:22 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B619B5D6D5; Tue, 31 Aug 2021 10:21:21 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1C1271800936; Tue, 31 Aug 2021 12:21:20 +0200 (CEST) Date: Tue, 31 Aug 2021 12:21:20 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb Message-ID: <20210831102120.kh2b6boorxets75j@sirius.home.kraxel.org> References: <77440edd1e175207dffcaaa052ce26ae71e6c66c.1630289827.git.min.m.xu@intel.com> <20210830070339.u47qq3g7hb4rq3xc@sirius.home.kraxel.org> <20210831051305.dhqvsh4jzqekmjly@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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 On Tue, Aug 31, 2021 at 06:17:29AM +0000, Xu, Min M wrote: > On August 31, 2021 1:13 PM, Gerd Hoffmann wrote: > > Hi, > > > > > > From a security point of view I don't think it is a good idea to > > > > hard code any assumptions about the layout of the vars volume. > > > Do you mean I cannot assume the layout of VarStore? > > > At least in Ovmf the VarStore.fdf.inc defines the layout of VarStore like > > below. > > > > What prevents an attacker from creating a varstore with a different layout? > > Place the variables at the end of the file, which isn't measured (because you > > assume it is the spare part), then being able to change variables without the > > guest noticing? > If the VarStore does not follow the layout defined in VarStore.fdf.inc, do you mean > the current Variable mechanism still works? From the code of > InitNonVolatileVariableStore(), the first variable is right after the VarStoreHeader. > See GetStartPointer(). I didn't fully investigate what kind of attacks one can do. I'm pretty sure simply making the variable store larger and the spare smaller works, so parts of the variable store are outside the area you are measuring. Not fully sure whenever one can actually reorder the sections to move the varstore completely into the unmeasured area. Or play out other attacks with the same effect, like bloating some header struct. Simply measuring everything (including the spare) will stop all that. Changes wouldn't go unnoticed, period. No ifs and buts. So I'm wondering why you not doing that? Performance? Wouldn't be the first time a performance optimization pokes a hole into a security concept ... take care, Gerd