From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.8bytes.org (mail.8bytes.org [85.214.250.239]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EFAB93C2D for ; Thu, 23 May 2024 09:52:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=85.214.250.239 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716457962; cv=none; b=sTPL0bon2YJFB6EIwYXX26XawG3zM1b/pY+ziYrzWoPky6xARTrG5ycIhl158gmt4urWw7U8BXO3TZvnaTpt4oRGyPG3q8kCLRi0eE6yBFGp0WHW1gOlPfjxdEZfvIBjLlPYZ739K2ROTbVYGYzRHkIrd/916Rl+hhxTA/yiDT4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716457962; c=relaxed/simple; bh=t72ds1a9tPvIHi+0m7UGqYMr+HpevzYQBBemqmIY8vI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ilBwCQg5DtNTp6ZjyiW0I7oNQNEqv6KDWS2Bs+u59YxcsmKEtLlxMpGTmgP6ds57vsOJklRry9O2E9OXOFB3ww0+u2kF8mUYOfLdops7iJ76izizJLifz33KlalXmQ1dZ/2m5ij9A6Fn/vgc48k3EfiYmhyrTo7YI8X+P2qV0qM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=8bytes.org; spf=pass smtp.mailfrom=8bytes.org; dkim=pass (2048-bit key) header.d=8bytes.org header.i=@8bytes.org header.b=wwDBPo2R; arc=none smtp.client-ip=85.214.250.239 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=8bytes.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=8bytes.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=8bytes.org header.i=@8bytes.org header.b="wwDBPo2R" Received: from 8bytes.org (pd9fe9dd8.dip0.t-ipconnect.de [217.254.157.216]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.8bytes.org (Postfix) with ESMTPSA id 8ACCB1C68CC; Thu, 23 May 2024 11:52:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=8bytes.org; s=default; t=1716457953; bh=t72ds1a9tPvIHi+0m7UGqYMr+HpevzYQBBemqmIY8vI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wwDBPo2RkdERKWBJDnsmlhNrp3bpZ0WXKSYh2ubzEzCLH7O7gzCGMZIT/Dtsgbh3A xrwmhCNNrYmMALLP78Ba2lMlgHQx0xfUgg4dNm1MIRP4TdIRPM6+H8R7WXKJPGEx27 RBJkAXnSpxx6yrwYL4nPwHCD5H23QpVJIsiMdOOGPT56t+q312H1R/o0anREjeUTxf U6oVegerKoY8AWBZXQLp4BE3aEPqi5nP4xmVELWxHJubgMrg8We5ZOYtEimPxMOUb3 45IyUvUpSU9gg8dEi+9CHlE2v/TdMlwURUstgnzr4DedT9SYSdpr0k9C5H5I+XJoL1 Rx8V6Qa2STp+A== Date: Thu, 23 May 2024 11:52:32 +0200 From: =?iso-8859-1?Q?J=F6rg_R=F6del?= To: "Reshetova, Elena" Cc: "Rodel, Jorg" , "svsm-devel@coconut-svsm.dev" , "linux-coco@lists.linux.dev" Subject: Re: [svsm-devel] Development Plan Document Message-ID: References: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Elena, On Fri, May 17, 2024 at 10:01:01AM +0000, Reshetova, Elena wrote: > Coconut as a service VM closely relates to the concept of service TDs that > we have in TDX (for example a Migration TD is an example of a such a service TD). > However, in my understanding there was not enough general > interest in this model (due to complexities of managing separate service VM > in addition to the guest OS VM) but looks like I had a wrong impression. Service VMs might be a niche use-case in the end. But since there is not much effort needed to make them work I see no reason to not support them. > We are affected by a double accept albeit differently. Since every page > that is accepted by a guest starts as a zero page, host/vmm can turn any > private page into a zero page (with potential security consequences) at > any time if acceptance status for the page is not tracked. Okay, right. Seems like the attacks work on Intel as well, just with a different outcome. Anyway, the mitigation should work on TDX as well. > Yes, anything that can affect coconut-svsm itself and which can be > security-relevant but at the same time stays stable over different boots. > Memory map is likely not stable, so i dont think we can measure it, > Coconut-svsm just should sanitize the values. ACPI tables is a candidate. > I know that currently coconut-svsm takes very little of such inputs/configurations, > but it will probably grow in the future, so having a guidance on what configuration > must be measured or not is good to have imo. We briefly touched that topic in yesterdays development call, it seems there are diverging requirements for different platforms. Some platforms do not want to measure any configuration data while others want to measure at least parts of it. Currently IGVM is used to pass any configuration data to the SVSM and the specification requires this data to be unmeasured. So an IGVM extension would be needed as well to pass measured configuration data. Regards, Joerg