From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B69920E702 for ; Fri, 14 Aug 2026 05:46:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786686364; cv=none; b=L37fNxUKtGs+lPcj9WWb/fpcn2Ao6dlFPr8QOGLpOQwan8ZLONunP8CUK80BtH258ho0A1h40pFdmRsqcheiObJkJwyFOgmxu2Eah7AUHajltUmv0K17hejFbZ2JqFGwG8+VRceE5WriGp+sHx0sbKDBnAm7uRHf80rkPa9KVkY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786686364; c=relaxed/simple; bh=B5+V8aDXSgyHBeZtsMhJdBvt5jrhqFzJiO/bvbPuF3Y=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=WHP86Irnoq72W4wbtB2GKcuLsi0xkGAmygHXa4Dm3CpZsBXc5HNggV2NywDZoHJFJPbAKq0S2U5vpjT5rXgqFduN3oYYVXj0EI1Ek3b2g7JaeUkmEzHNyY/HVgWR81Ri6/ysqTyuHCWWzXQDyRJfn+6keL9ng/kWfWUd+4Zexx0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=KTVRRWmE; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KTVRRWmE" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-47f3b39f2a1so511521f8f.2 for ; Thu, 13 Aug 2026 22:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786686361; x=1787291161; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=Q8H/CbRo+VwI/8mgs+C0XfBgtzPkoXXEyoqc4BkrmCk=; b=KTVRRWmEBvbPBm6fTcKufv2MI3aPNJEDwzC+VSTskYpRgQR7NHnWUFvMQjCiDfauTY Uqt6rztXPqsIXY8yfEWWda4PG7WmZ3G2dfG8YFIiZtaYxJ3AErmltIesSG2tUGzrsDsV LKPR544HB78132buvXDCxtzL2Z4nDz0xkDtecjtitOzbJEuaJgAXI6gwIUPKR1VEvwn3 plpCpamOYIjnQRYA7SOucebZSc8ZOKY57pEmsosV0PUNygJLSCGRhu6DwJ/v1xsxYLHi X8WNuSwemaYbZFW370mZMbUVwzhn5X5Bm18wT/TSqBIzrO6IfWNI3lMpuI71OurluWTr 8URw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786686361; x=1787291161; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Q8H/CbRo+VwI/8mgs+C0XfBgtzPkoXXEyoqc4BkrmCk=; b=GbYcKELVj3NuSTnGeZ1XCfdbhArSM9MQwv2tSSI74iHonMVzaeRZ43KTV08VHZr/5N EThT7pUrPsfXcjC59vqr61Wug3UuXVRjrhbOQZTjJJ9kXInSJpWfm8uKidsj6N26MoSR /XxRjWPNrTrZtyWo7b7V+hwn2LjIarGiEZrkrEN61KRP5sysdtHXpIgpP+zs7MbPOmDm HF0517ORzRxXOzatqg31hMQEVtLRuO48ecLGT8TtA7dEpfhglyD3ViW/Pvc+t9xYgGgv Ss5m+EOsb15zcWt7CBO2xdQw0RvGWMFkg7gfqI8bRcijhicL+HvN5TM6C3YcB6FB9GLX D9KQ== X-Forwarded-Encrypted: i=1; AHgh+RrMwrIy6EPRQ7atyM9CCFor+v8smieBMNq6nt8YFq9Y9DCRsscy9qaMLmBM4gAJAAFUl13+l+beWfASXfU=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2DUkSODu6rfxoQph9mUg4edgGA9AImMltlYITDlTvOo/cUgyi VwHzjyImurZT5RAYVg2E9P7NEIqDVs9pQEoPHuOGy873Lo3wTa1cGEGs X-Gm-Gg: AR+sD13KaN2jHzjYpo4agk67C1pDBS8X5OvzRccKT2JwQbF12fCTb3vlNK0LJ5xxfE4 HT02RnBsVwqZoo6fy7OEQq9bobuHEMrZfoK2fUwoy+RdRKuwBCEFoNmSs9DLPeY4CcOn2W/BPfz 9JB/3U3LhoU4ZJ9XtLw+gT5X7YXY8CoregdpgvI/5oq3zGUdKa1TKXf6qnguHPRTQh+5lhE6J7V NBwumJUjI6Y9ukFHRYYsxBLfwKz+zs3K6Jk2xjQDGxujVzXDtC6rDRqh12j4Lqe4ScCAkGa2tMl uV/pePrPrEQGURQ6e2UzDaJ3e4xLdZTN3L3Dp+gMGyJyusDx/HNCnDZD97eMMGVjJ1zIHCoUuvK lcQtFAqZVfmVcYszzOqTVLk3GXLrIIu6+7+9h6128Ha14awgHhHrOjxpPUHk9vYHCfrnPBe/Zbc Nvq4rY8WomPSZ0Bnu5KDS2wsZp25W+mXT+G0gdCT42g18kAr5QyZMuBua/8kX0TPpk X-Received: by 2002:a05:6000:2612:b0:47f:c648:e265 with SMTP id ffacd0b85a97d-48160758afcmr4474351f8f.17.1786686360494; Thu, 13 Aug 2026 22:46:00 -0700 (PDT) Received: from [10.245.244.143] ([134.191.227.46]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-481626fd0f0sm1280557f8f.28.2026.08.13.22.45.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 22:45:59 -0700 (PDT) Message-ID: <8b432c8731167e97432b2e917d0b1c855fedf47c.camel@gmail.com> Subject: Re: [PATCH v3 0/4] tdx-guest: Make Quote buffer size dynamic From: Artem Bityutskiy To: "Edgecombe, Rick P" , "seanjc@google.com" Cc: "linux-coco@lists.linux.dev" , "x86@kernel.org" , "dave.hansen@linux.intel.com" , "kas@kernel.org" , "binbin.wu@linux.intel.com" , "Li, Xiaoyao" , "linux-kernel@vger.kernel.org" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "bp@alien8.de" , "kvm@vger.kernel.org" , "tglx@kernel.org" , "hpa@zytor.com" , "mingo@redhat.com" , "Fang, Peter" Date: Fri, 14 Aug 2026 08:45:55 +0300 In-Reply-To: <4ad451969522eecb445289ca74a88ee73d51336d.camel@intel.com> References: <20260729122939.1340412-1-peter.fang@intel.com> <80b4ea89ebf17398c3bee21d157c7f97ea32aadf.camel@intel.com> <86d532f33816cd4fa3e29c40079a6003abf89324.camel@intel.com> <20260812223707.GD1013044@pedri> <6191a69559e58e04c8e3f1efa776e9639796af3d.camel@intel.com> <98dcc8a12f117745a1cb9981dc8f0f1548e9c96f.camel@gmail.com> <4ad451969522eecb445289ca74a88ee73d51336d.camel@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Thu, 2026-08-13 at 20:14 +0000, Edgecombe, Rick P wrote: > > 3. Why freezing TD report size > >=20 > > Linux supports 1024-byte TD reports via the `TDX_CMD_GET_REPORT0` > > ioctl. It is already full, no more TD evidence fits, and changing TD > > report size would require a new ioctl. > >=20 > > Also, as I understand it, based on TDX feature requests from customers, > > there may be a need to increase TD report size more often and more > > significantly than one would expect. > >=20 > > Therefore, for DICE-based attestation the TDX module adds new TD > > evidence in the quote instead of expanding the TD report. > >=20 > > Is this the cleanest approach? Maybe not.=C2=A0 > >=20 >=20 > I was thinking the cleanest, time-travel facilitated, approach would be t= o have > the "report" really just be a replay protection thing and not include any= TD > details. Then the quote could add everything it needed in the final forma= t > location. So no re-verifying and shuffling things between formats. But si= nce > that didn't work for SGX based attestation, the report has extra stuff du= e to > legacy. But from Linux's POV, going forward we can consider the report as= really > an oversized replay protection blob and forget about the TD details in it= . Isn't > it a pretty clean separation of concerns? And for Linux (guest), the bene= fit > shows up in not having to increase TD report size since it has really onl= y one > job. Replay attack protection is a binding value between the remote party and the final quote. It must sit in final quote. It only needs to exist in the TD report because of the 2-flow design. But why DICE-based attestation uses 2-flow design? Could TD run a TDCALL[TDG.GET.QUOTE2] or something directly. No concept of TD report would be needed. That would be my current vision of "cleanest". But the approach that was taken is to minimize software changes. Within that tradeoff, keeping the 2-step flow, preserving the TD report format and size absolutely intact, and adding the extra information in the quote is arguably a clean practical path. Is this the cleanest in some absolute sense? No. Is it acceptable? I would say yes. > >=20 > > 4. Migration-specific case > >=20 > > For the normal user attestation path, the TD report is TD-scoped. For > > migration, the report is effectively platform-scoped, just because the > > migration flow does not need TD-specific evidence. > >=20 > > I would say that clean design is when Linux does not need to know this > > and care about this specific case: be able to treat all TD reports as > > per-TD. >=20 > I was hoping you could chime in about the thing you mentioned off-list re= garding > *when* the quote operation is needed for migration. As in, what stage of = the TD > lifecycle and how it fits into a KVM VM TD scoped ioctl. The first step in TDX live migration is `TDH.MIG.SETUP` seamcall. It is=C2=A0called multiple times on both the source and destination hosts. The TDX=C2=A0 module keeps the setup session state and drives the protocol by telling the VMM what to do next through exit codes. Each call follows the same pattern: 1. The VMM calls `TDH.MIG.SETUP` for the source TD or the destination TD. 2. The TDX module reads the optional input buffer and may produce an output buffer. 3. The exit code tells the VMM what to do before the next call. One of the possible exit codes is TDX_MIG_SETUP_GET_QUOTE. It means: deliver me the quote. The output buffer contains the TD report. The idea was to pass this directly to QEMU. QEMU would call the proposed "get quote" ioctl on the TD under migration, and provide the TD report from `TDH.MIG.SETUP` on ioctl input. QEMU would not need to care about the scope rules and would just treat the TD report as belonging to the TD under migration. The ioctl would then run TDH.GET.QUOTE with TDR for the TD under migration. The seamcall would handle the scope logic internally. It would be an internal TDX module detail. Did you mean this or something else?