From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web11.4446.1630479436553533426 for ; Tue, 31 Aug 2021 23:57:16 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=lmPkZN1C; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 39AAF6101A for ; Wed, 1 Sep 2021 06:57:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630479435; bh=DieGqOIXmx0ByZRlFf2SfCjbT94sj6EDG56JlhgdJZc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=lmPkZN1CNBH/utj5o39EjlW0hRte7ohtsmL8xI2L+5SWOWPgL8qP+hN9M9jIFcm9z PmvVok4KYlblG9OlUYSD589WgYSF4YoQ2OoOErm9FjKkmfUz8x7UyXjWYCefaRoTyK rG5WSr++oTCr2kzviu89ktUkzB1pdXssoo5v3cCKnRZYO8gZqxoAMs0S77fjz3/ipX Z69GC1oO0qfPF2p9cKud5zYVCPEY9lV2yhqovpm5En0aYNYpzi+VEmjib0GyCMl1qk TcEEbr8akEJVELoInQ73amhTDZAoJXTCuxYeT/oX62S3zWVhPysiCeqNQQWe5KVtZY 8Qp8pOBVS65wQ== Received: by mail-oo1-f47.google.com with SMTP id t1-20020a4a54010000b02902638ef0f883so527129ooa.11 for ; Tue, 31 Aug 2021 23:57:15 -0700 (PDT) X-Gm-Message-State: AOAM531AS0PI4ViViD7PA+okjDKniFnw9ffLGP6m2HmRpshxDzlZXq56 1UK1yOxZxE/qa3EbvPaDeVg27dkeRfVjKfoJz/U= X-Google-Smtp-Source: ABdhPJw+w06olElLA7XmB3tBeBRZ84PA30OpO9W9hKZQFZKAevxdM2CC9xF/EGtQdKrUhBbRCDlBpEphQa6dxp/nSo8= X-Received: by 2002:a4a:dfac:: with SMTP id k12mr17726532ook.41.1630479434566; Tue, 31 Aug 2021 23:57:14 -0700 (PDT) MIME-Version: 1.0 References: <77440edd1e175207dffcaaa052ce26ae71e6c66c.1630289827.git.min.m.xu@intel.com> <20210830070339.u47qq3g7hb4rq3xc@sirius.home.kraxel.org> <20210831051305.dhqvsh4jzqekmjly@sirius.home.kraxel.org> <20210831102120.kh2b6boorxets75j@sirius.home.kraxel.org> <20210901061033.auj6v3nnofmcawxc@sirius.home.kraxel.org> In-Reply-To: <20210901061033.auj6v3nnofmcawxc@sirius.home.kraxel.org> From: "Ard Biesheuvel" Date: Wed, 1 Sep 2021 08:57:03 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb To: devel@edk2.groups.io, kraxel@redhat.com Cc: "Xu, Min M" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Content-Type: text/plain; charset="UTF-8" On Wed, 1 Sept 2021 at 08:10, Gerd Hoffmann wrote: > > Hi, > > > > 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 ... > > > > > The measurement value of the CFV (provisioned configuration data) is extended to > > RTMR registers (similar to TPM PCRs). At the same time it is recorded in the TD Event > > log. > > These information will be used by the Attestation server (This is the so-called Attestation). > > In other words there is a known *good* CFV measurement value. Any changes to > > the CFV, for example the layout, the order of the variables, the content of the variables > > will produce a *bad* CFV measurement. > > Yes. The attacker would need a varstore with a modified layout being > approved by the attestation server as first step, then he would be able > to modify variables unnoticed in a second step. > > So, assuming an attacker isn't able to carry out the first step it > should be all fine in theory. When it comes to security it never hurts > to have another line of defense though, so I would still strongly > recommend to measure the complete varstore (including spare). > > At the end of the day it is your call, I'm not going to veto the patch. > But I'll reserve the right to pull a "told you so" in case someone > manages to exploit that some day. > Have to agree with Gerd here: if those contents are being interpreted by the code, and may therefore affect its execution, I don't think it should be omitted from the measurement unless there is a compelling reason for it. Omitting it simply because you can doesn't seem sufficient justification to me. -- Ard.