From: Dan Williams <dan.j.williams@intel.com>
To: Samuel Ortiz <sameo@rivosinc.com>, Alexey Kardashevskiy <aik@amd.com>
Cc: <linux-coco@lists.linux.dev>, <kvm@vger.kernel.org>,
<linux-pci@vger.kernel.org>
Subject: Re: TDISP enablement
Date: Tue, 5 Dec 2023 20:43:00 -0800 [thread overview]
Message-ID: <656ffbd4e2a39_4568a294c5@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <ZVOTsEhQTYxOpxA8@vermeer>
Samuel Ortiz wrote:
[..]
> > There is always a driver which has to enable the device and tell it where it
> > can DMA to/from anyway so the RUN state does not really let the device start
> > doing things once it is moved to RUN
>
> I agree. But setting RUN from the host means that the guest can start
> configuring and using that device at any point in time, i.e. even before
> any guest component could verify, validate and attest to the TDI. RUN is
> precisely defined for that purpose: Telling the TDI that it should now
> accept T-bit TLPs, and you want to do that *after* the TVM accepts the
> TDI. Here, by having the host move the TDI to RUN, potentially even before
> the TVM has even booted, you're not giving the guest a chance to explictly
> accept the TDI.
I wanted to circle back to this to agree about allowing the guest to
control the transition from LOCKED to RUN. Recall the Plumbers
conversation where I mentioned TDX moving closer to TIO to streamline
the common TSM interface in Linux, and foreshadowing other vendors
making similar concessions. This is an example where the "as simple as
possible, but no simpler" threshold looks to have been crossed.
TDX like COVE allows for guest to trigger LOCKED to RUN transition. For
vendor alignment purposes this looks like an opportunity for TIO to
enable the same and prevent a vendor-specific semantic difference in the
TSM common infrastructure.
[..]
[inclue Samuel's further justification that I also Ack]
> > > After that call, the TDI is usable from a TVM perspective. Before that
> > > call it is not, but its configuration and state are locked.
> > Right. I still wonder what bad thing can happen if we move to RUN before
> > starting the TVM (I suspect there is something), or it is all about
> > semantics (for the AMD TIO usecase, at least)?
>
> It's not only about semantics, it's about ownership. By moving to RUN
> before the TVM starts, you're basically saying the host decides if the
> TDI is acceptable by the TVM or not. The TVM is responsible for making
> that decision and does not trust the host VMM to do so on its behalf, at
> least in the confidential computing threat model.
>
> Is there any specific reason why you wouldn't move the TDI to RUN when
> the SEV guest calls into the validat ABI?
>
> Cheers,
> Samuel.
>
prev parent reply other threads:[~2023-12-06 4:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 22:56 TDISP enablement Alexey Kardashevskiy
2023-10-31 23:40 ` Dionna Amalie Glaze
2023-11-01 7:38 ` Lukas Wunner
2023-11-01 7:27 ` Lukas Wunner
2023-11-01 11:05 ` Jonathan Cameron
2023-11-02 2:28 ` Alexey Kardashevskiy
2023-11-03 16:44 ` Jonathan Cameron
2023-11-11 22:45 ` Dan Williams
2023-11-24 14:52 ` Jonathan Cameron
2023-11-10 23:38 ` Dan Williams
2023-11-10 23:30 ` Dan Williams
2023-11-24 16:25 ` Jonathan Cameron
2023-11-13 6:04 ` Samuel Ortiz
2023-11-01 11:43 ` Alexey Kardashevskiy
2023-11-13 5:43 ` Samuel Ortiz
2023-11-13 6:46 ` Alexey Kardashevskiy
2023-11-13 15:10 ` Samuel Ortiz
2023-11-14 0:57 ` Alexey Kardashevskiy
2023-11-14 15:35 ` Samuel Ortiz
2023-12-06 4:43 ` Dan Williams [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=656ffbd4e2a39_4568a294c5@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=aik@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=sameo@rivosinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).