[PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Nikolay Borisov]

IOCTL based interface was the natural choice for interacting with the
quote generation machine at a time when there wasn't anything better.
Fortunately, now we have a vendor-agnostic, configfs-based one which
obviates the need to have the IOCTL-based interface.

Gate the relevant code behind a Kconfig option, clearly marking it as
deprecated as well as introduce a runtime warning.

Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
---
 drivers/virt/coco/tdx-guest/Kconfig     |  9 +++++++++
 drivers/virt/coco/tdx-guest/tdx-guest.c | 13 +++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/drivers/virt/coco/tdx-guest/Kconfig b/drivers/virt/coco/tdx-guest/Kconfig
index 22dd59e19431..0f1cfdfbbd28 100644
--- a/drivers/virt/coco/tdx-guest/Kconfig
+++ b/drivers/virt/coco/tdx-guest/Kconfig
@@ -9,3 +9,12 @@ config TDX_GUEST_DRIVER
 
 	  To compile this driver as module, choose M here. The module will
 	  be called tdx-guest.
+
+config TDX_GUEST_DRIVER_LEGACY_IOCTL
+	def_bool y
+	prompt "Enable legacy ioctl interface (DEPRECATED)"
+	depends on TDX_GUEST_DRIVER
+	help
+	  Enable the legacy IOCTL-based interface to get the TDX report. It's
+	  deprecated in favor of the configfs based one and will be removed
+	  in a future release.
diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c
index 1253bf76b570..b8cea9486daf 100644
--- a/drivers/virt/coco/tdx-guest/tdx-guest.c
+++ b/drivers/virt/coco/tdx-guest/tdx-guest.c
@@ -66,6 +66,7 @@ static DEFINE_MUTEX(quote_lock);
  */
 static u32 getquote_timeout = 30;
 
+#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
 static long tdx_get_report0(struct tdx_report_req __user *req)
 {
 	u8 *reportdata, *tdreport;
@@ -100,6 +101,7 @@ static long tdx_get_report0(struct tdx_report_req __user *req)
 
 	return ret;
 }
+#endif
 
 static void free_quote_buf(void *buf)
 {
@@ -249,6 +251,9 @@ static int tdx_report_new(struct tsm_report *report, void *data)
 	return ret;
 }
 
+
+
+#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
 static long tdx_guest_ioctl(struct file *file, unsigned int cmd,
 			    unsigned long arg)
 {
@@ -271,6 +276,7 @@ static struct miscdevice tdx_misc_dev = {
 	.minor = MISC_DYNAMIC_MINOR,
 	.fops = &tdx_guest_fops,
 };
+#endif
 
 static const struct x86_cpu_id tdx_guest_ids[] = {
 	X86_MATCH_FEATURE(X86_FEATURE_TDX_GUEST, NULL),
@@ -290,9 +296,12 @@ static int __init tdx_guest_init(void)
 	if (!x86_match_cpu(tdx_guest_ids))
 		return -ENODEV;
 
+#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
+	pr_info("Legacy IOCTL-based interface is deprecated and will be removed in a future release\n");
 	ret = misc_register(&tdx_misc_dev);
 	if (ret)
 		return ret;
+#endif
 
 	quote_data = alloc_quote_buf();
 	if (!quote_data) {
@@ -310,7 +319,9 @@ static int __init tdx_guest_init(void)
 free_quote:
 	free_quote_buf(quote_data);
 free_misc:
+#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
 	misc_deregister(&tdx_misc_dev);
+#endif
 
 	return ret;
 }
@@ -320,7 +331,9 @@ static void __exit tdx_guest_exit(void)
 {
 	tsm_unregister(&tdx_tsm_ops);
 	free_quote_buf(quote_data);
+#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
 	misc_deregister(&tdx_misc_dev);
+#endif
 }
 module_exit(tdx_guest_exit);
 
-- 
2.34.1

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Nikolay Borisov]

On 24.01.24 г. 11:38 ч., Nikolay Borisov wrote:
> IOCTL based interface was the natural choice for interacting with the
> quote generation machine at a time when there wasn't anything better.
> Fortunately, now we have a vendor-agnostic, configfs-based one which
> obviates the need to have the IOCTL-based interface.
> 
> Gate the relevant code behind a Kconfig option, clearly marking it as
> deprecated as well as introduce a runtime warning.
> 
> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>

Ping?

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Kuppuswamy Sathyanarayanan]

+ Dan Middleton

Hi Boris,

On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> IOCTL based interface was the natural choice for interacting with the
> quote generation machine at a time when there wasn't anything better.
> Fortunately, now we have a vendor-agnostic, configfs-based one which
> obviates the need to have the IOCTL-based interface.
>
> Gate the relevant code behind a Kconfig option, clearly marking it as
> deprecated as well as introduce a runtime warning.
>
> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> ---

In the following thread, Dan Middleton raised a point about this interface
being used for local attestation use cases.

https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a

Currently, the configfs-based ABI does not support the local attestation use cases.

IMO, for now we can just add a config option to allow the user to selectively
enable it. We can add the runtime warning once we address the local attestation
use case via configfs ABI.

>  drivers/virt/coco/tdx-guest/Kconfig     |  9 +++++++++
>  drivers/virt/coco/tdx-guest/tdx-guest.c | 13 +++++++++++++
>  2 files changed, 22 insertions(+)
>
> diff --git a/drivers/virt/coco/tdx-guest/Kconfig b/drivers/virt/coco/tdx-guest/Kconfig
> index 22dd59e19431..0f1cfdfbbd28 100644
> --- a/drivers/virt/coco/tdx-guest/Kconfig
> +++ b/drivers/virt/coco/tdx-guest/Kconfig
> @@ -9,3 +9,12 @@ config TDX_GUEST_DRIVER
>  
>  	  To compile this driver as module, choose M here. The module will
>  	  be called tdx-guest.
> +
> +config TDX_GUEST_DRIVER_LEGACY_IOCTL
> +	def_bool y
> +	prompt "Enable legacy ioctl interface (DEPRECATED)"
> +	depends on TDX_GUEST_DRIVER
> +	help
> +	  Enable the legacy IOCTL-based interface to get the TDX report. It's
> +	  deprecated in favor of the configfs based one and will be removed
> +	  in a future release.
> diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c
> index 1253bf76b570..b8cea9486daf 100644
> --- a/drivers/virt/coco/tdx-guest/tdx-guest.c
> +++ b/drivers/virt/coco/tdx-guest/tdx-guest.c
> @@ -66,6 +66,7 @@ static DEFINE_MUTEX(quote_lock);
>   */
>  static u32 getquote_timeout = 30;
>  
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
>  static long tdx_get_report0(struct tdx_report_req __user *req)
>  {
>  	u8 *reportdata, *tdreport;
> @@ -100,6 +101,7 @@ static long tdx_get_report0(struct tdx_report_req __user *req)
>  
>  	return ret;
>  }
> +#endif
>  
>  static void free_quote_buf(void *buf)
>  {
> @@ -249,6 +251,9 @@ static int tdx_report_new(struct tsm_report *report, void *data)
>  	return ret;
>  }
>  
> +
> +
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
>  static long tdx_guest_ioctl(struct file *file, unsigned int cmd,
>  			    unsigned long arg)
>  {
> @@ -271,6 +276,7 @@ static struct miscdevice tdx_misc_dev = {
>  	.minor = MISC_DYNAMIC_MINOR,
>  	.fops = &tdx_guest_fops,
>  };
> +#endif
>  
>  static const struct x86_cpu_id tdx_guest_ids[] = {
>  	X86_MATCH_FEATURE(X86_FEATURE_TDX_GUEST, NULL),
> @@ -290,9 +296,12 @@ static int __init tdx_guest_init(void)
>  	if (!x86_match_cpu(tdx_guest_ids))
>  		return -ENODEV;
>  
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
> +	pr_info("Legacy IOCTL-based interface is deprecated and will be removed in a future release\n");
>  	ret = misc_register(&tdx_misc_dev);
>  	if (ret)
>  		return ret;
> +#endif
>  
>  	quote_data = alloc_quote_buf();
>  	if (!quote_data) {
> @@ -310,7 +319,9 @@ static int __init tdx_guest_init(void)
>  free_quote:
>  	free_quote_buf(quote_data);
>  free_misc:
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
>  	misc_deregister(&tdx_misc_dev);
> +#endif
>  
>  	return ret;
>  }
> @@ -320,7 +331,9 @@ static void __exit tdx_guest_exit(void)
>  {
>  	tsm_unregister(&tdx_tsm_ops);
>  	free_quote_buf(quote_data);
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
>  	misc_deregister(&tdx_misc_dev);
> +#endif
>  }
>  module_exit(tdx_guest_exit);
>  

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dave Hansen]

On 1/30/24 23:28, Nikolay Borisov wrote:
> On 24.01.24 г. 11:38 ч., Nikolay Borisov wrote:
>> IOCTL based interface was the natural choice for interacting with the
>> quote generation machine at a time when there wasn't anything better.
>> Fortunately, now we have a vendor-agnostic, configfs-based one which
>> obviates the need to have the IOCTL-based interface.
>>
>> Gate the relevant code behind a Kconfig option, clearly marking it as
>> deprecated as well as introduce a runtime warning.
>>
>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> 
> Ping?

There is no clear consensus from this changelog, nor the tags about this
approach.  It would be much appreciated if you could make this changelog
more freestanding and  make it clear that this approach is acceptable to
both the authors and users of the code you are modifying.

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Nikolay Borisov]

On 31.01.24 г. 17:27 ч., Dave Hansen wrote:
> On 1/30/24 23:28, Nikolay Borisov wrote:
>> On 24.01.24 г. 11:38 ч., Nikolay Borisov wrote:
>>> IOCTL based interface was the natural choice for interacting with the
>>> quote generation machine at a time when there wasn't anything better.
>>> Fortunately, now we have a vendor-agnostic, configfs-based one which
>>> obviates the need to have the IOCTL-based interface.
>>>
>>> Gate the relevant code behind a Kconfig option, clearly marking it as
>>> deprecated as well as introduce a runtime warning.
>>>
>>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
>>
>> Ping?
> 
> There is no clear consensus from this changelog, nor the tags about this
> approach.  It would be much appreciated if you could make this changelog
> more freestanding and  make it clear that this approach is acceptable to
> both the authors and users of the code you are modifying.


So how about something along the lines of:

IOCTL based interface was the natural choice for interacting with the
quote generation machine at a time when there wasn't anything better. In 
its current form it's only usable for local attestation but that use 
case is also going to be switched to the config-tsm interface. In 
preparation for this introduce a Kconfig option which allows the user to 
choose to disable the legacy code.

This strikes a balance between starting the deprecation process, yet not 
prevent existing users to continue using the code.


---------------------------------------

And the next version of the patch won't have the runtime warning.

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dave Hansen]

On 1/31/24 10:18, Nikolay Borisov wrote:
>> There is no clear consensus from this changelog, nor the tags about this
>> approach.  It would be much appreciated if you could make this changelog
>> more freestanding and  make it clear that this approach is acceptable to
>> both the authors and users of the code you are modifying.
> 
> So how about something along the lines of:
> 
> IOCTL based interface was the natural choice for interacting with the
> quote generation machine at a time when there wasn't anything better. In
> its current form it's only usable for local attestation but that use
> case is also going to be switched to the config-tsm interface. In
> preparation for this introduce a Kconfig option which allows the user to
> choose to disable the legacy code.

That's an interesting theory.  Do the users and authors of the TDX code
you're Kconfig'ing away agree with you?

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dan Williams]

Kuppuswamy Sathyanarayanan wrote:
> + Dan Middleton
> 
> Hi Boris,
> 
> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> > IOCTL based interface was the natural choice for interacting with the
> > quote generation machine at a time when there wasn't anything better.
> > Fortunately, now we have a vendor-agnostic, configfs-based one which
> > obviates the need to have the IOCTL-based interface.
> >
> > Gate the relevant code behind a Kconfig option, clearly marking it as
> > deprecated as well as introduce a runtime warning.
> >
> > Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> > ---
> 
> In the following thread, Dan Middleton raised a point about this interface
> being used for local attestation use cases.
> 
> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
> 
> Currently, the configfs-based ABI does not support the local attestation use cases.

What are local attestation use cases, and what happens if Linux does not
provide a local attestation interface and standardizes on remotely
attestable as the standard?

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Nikolay Borisov]

On 31.01.24 г. 21:50 ч., Dan Williams wrote:
> Kuppuswamy Sathyanarayanan wrote:
>> + Dan Middleton
>>
>> Hi Boris,
>>
>> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
>>> IOCTL based interface was the natural choice for interacting with the
>>> quote generation machine at a time when there wasn't anything better.
>>> Fortunately, now we have a vendor-agnostic, configfs-based one which
>>> obviates the need to have the IOCTL-based interface.
>>>
>>> Gate the relevant code behind a Kconfig option, clearly marking it as
>>> deprecated as well as introduce a runtime warning.
>>>
>>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
>>> ---
>>
>> In the following thread, Dan Middleton raised a point about this interface
>> being used for local attestation use cases.
>>
>> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
>>
>> Currently, the configfs-based ABI does not support the local attestation use cases.
> 
> What are local attestation use cases, and what happens if Linux does not
> provide a local attestation interface and standardizes on remotely
> attestable as the standard?

The local attestation use case must be expanded on by your colleague Dan 
Middleton as he was the one mentioning it:

https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a

Other than this Redhat/Ubuntu said they shipped this ioctl and Google as 
one of the major CSP's said they are using the config-tsm interface. 
Jeremi from Azure said that this particular ioctl interface is not 
accessible to guests - 
https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m46070ba40150234d30dbc7cefc89a2ccb53b59e4 



So it might as well be a dead-end.

RE: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dan Williams]

Nikolay Borisov wrote:
> IOCTL based interface was the natural choice for interacting with the
> quote generation machine at a time when there wasn't anything better.

That's not quite how I would phrase it. Perhaps just quote configfs-tsm
changelog? Something like:

---
"The commit that added configfs-tsm noted that the concept of
attestation reports is '...common across TSMs, but the implementations
are unfortunately vendor specific. While the industry grapples with a
common definition of this attestation format [1], Linux need not make
this problem worse by defining a new ABI per TSM that wants to perform a
similar operation. The current momentum has been to invent new ioctl-ABI
per TSM per function which at best is an abdication of the kernel's
responsibility to make common infrastructure concepts share common
ABI.'

While the SEV-SNP implementation exposed remotely verifiable reports
from day1 the TDX implementation started with a locally verifiable
report retrieved over ioctl, but adopted configs-tsm for conveying its
remotely verifiable report"
---

Then there needs to be a discussion here to describe who is still using
the local attestation reports, what their migration path is (if one is
needed), and some indication how does a distribution vendor know when
those users have migrated or dropped their interest.

> Fortunately, now we have a vendor-agnostic, configfs-based one which
> obviates the need to have the IOCTL-based interface.
> 
> Gate the relevant code behind a Kconfig option, clearly marking it as
> deprecated as well as introduce a runtime warning.
> 
> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> ---
>  drivers/virt/coco/tdx-guest/Kconfig     |  9 +++++++++
>  drivers/virt/coco/tdx-guest/tdx-guest.c | 13 +++++++++++++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/virt/coco/tdx-guest/Kconfig b/drivers/virt/coco/tdx-guest/Kconfig
> index 22dd59e19431..0f1cfdfbbd28 100644
> --- a/drivers/virt/coco/tdx-guest/Kconfig
> +++ b/drivers/virt/coco/tdx-guest/Kconfig
> @@ -9,3 +9,12 @@ config TDX_GUEST_DRIVER
>  
>  	  To compile this driver as module, choose M here. The module will
>  	  be called tdx-guest.
> +
> +config TDX_GUEST_DRIVER_LEGACY_IOCTL
> +	def_bool y
> +	prompt "Enable legacy ioctl interface (DEPRECATED)"
> +	depends on TDX_GUEST_DRIVER
> +	help
> +	  Enable the legacy IOCTL-based interface to get the TDX report. It's
> +	  deprecated in favor of the configfs based one and will be removed
> +	  in a future release.

This too should document how a user would know if they need this or not.

> diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c
> index 1253bf76b570..b8cea9486daf 100644
> --- a/drivers/virt/coco/tdx-guest/tdx-guest.c
> +++ b/drivers/virt/coco/tdx-guest/tdx-guest.c
> @@ -66,6 +66,7 @@ static DEFINE_MUTEX(quote_lock);
>   */
>  static u32 getquote_timeout = 30;
>  
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
>  static long tdx_get_report0(struct tdx_report_req __user *req)
>  {
>  	u8 *reportdata, *tdreport;
> @@ -100,6 +101,7 @@ static long tdx_get_report0(struct tdx_report_req __user *req)
>  
>  	return ret;
>  }
> +#endif

Please no sprinkling of ifdef throughout the file.  Create a new file
like drivers/virt/coco/tdx-guest/miscdev.c, and optionally compile it.
With a tdx_misc_register() that stubs out the setup, something like:

#ifdef CONFIG_TDX_GUEST_REPORT_IOCTL
int tdx_misc_register(void);
#else
static inline int tdx_misc_register(void) { return 0; }
#endif

>  
>  static void free_quote_buf(void *buf)
>  {
> @@ -249,6 +251,9 @@ static int tdx_report_new(struct tsm_report *report, void *data)
>  	return ret;
>  }
>  
> +
> +
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
>  static long tdx_guest_ioctl(struct file *file, unsigned int cmd,
>  			    unsigned long arg)
>  {
> @@ -271,6 +276,7 @@ static struct miscdevice tdx_misc_dev = {
>  	.minor = MISC_DYNAMIC_MINOR,
>  	.fops = &tdx_guest_fops,
>  };
> +#endif
>  
>  static const struct x86_cpu_id tdx_guest_ids[] = {
>  	X86_MATCH_FEATURE(X86_FEATURE_TDX_GUEST, NULL),
> @@ -290,9 +296,12 @@ static int __init tdx_guest_init(void)
>  	if (!x86_match_cpu(tdx_guest_ids))
>  		return -ENODEV;
>  
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
> +	pr_info("Legacy IOCTL-based interface is deprecated and will be removed in a future release\n");

No, don't spam the log on driver load, maybe add a pr_info_once() in the
ioctl path itself. Then you get some rough telemmetry of actual usage if
people post kernel logs to the kernel mailing list(s).

>  	ret = misc_register(&tdx_misc_dev);
>  	if (ret)
>  		return ret;
> +#endif
>  
>  	quote_data = alloc_quote_buf();
>  	if (!quote_data) {
> @@ -310,7 +319,9 @@ static int __init tdx_guest_init(void)
>  free_quote:
>  	free_quote_buf(quote_data);
>  free_misc:
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
>  	misc_deregister(&tdx_misc_dev);
> +#endif
>  
>  	return ret;
>  }
> @@ -320,7 +331,9 @@ static void __exit tdx_guest_exit(void)
>  {
>  	tsm_unregister(&tdx_tsm_ops);
>  	free_quote_buf(quote_data);
> +#ifdef CONFIG_TDX_GUEST_DRIVER_LEGACY_IOCTL
>  	misc_deregister(&tdx_misc_dev);
> +#endif
>  }
>  module_exit(tdx_guest_exit);
>  
> -- 
> 2.34.1
> 

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Kuppuswamy Sathyanarayanan]

On 1/31/24 11:50 AM, Dan Williams wrote:
> Kuppuswamy Sathyanarayanan wrote:
>> + Dan Middleton
>>
>> Hi Boris,
>>
>> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
>>> IOCTL based interface was the natural choice for interacting with the
>>> quote generation machine at a time when there wasn't anything better.
>>> Fortunately, now we have a vendor-agnostic, configfs-based one which
>>> obviates the need to have the IOCTL-based interface.
>>>
>>> Gate the relevant code behind a Kconfig option, clearly marking it as
>>> deprecated as well as introduce a runtime warning.
>>>
>>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
>>> ---
>> In the following thread, Dan Middleton raised a point about this interface
>> being used for local attestation use cases.
>>
>> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
>>
>> Currently, the configfs-based ABI does not support the local attestation use cases.
> What are local attestation use cases, and what happens if Linux does not
> provide a local attestation interface and standardizes on remotely
> attestable as the standard?


Local attestation is used by one TD on the same platform to prove to another TD
in the same platform about its identity. It is mainly used in cases where a TD provides
some special services required by other TDs. Since they are all in the same platform,
there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
to check the correctness of the TD.

I am not sure about actual local attestation users. May be Dan can share that info.

Regarding your question about using "remotely attestable as the standard", I think
remote attestation can handle all local attestation use cases. But, does it make sense to
force users to run a Quoting service if they don't need to communicate with 3rd party
servers?

SGX also seems to have local attestation concept

https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation/inter-process-local-attestation

>
-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Daniel P. Berrangé]

On Wed, Jan 31, 2024 at 12:44:46PM -0800, Kuppuswamy Sathyanarayanan wrote:
> 
> On 1/31/24 11:50 AM, Dan Williams wrote:
> > Kuppuswamy Sathyanarayanan wrote:
> >> + Dan Middleton
> >>
> >> Hi Boris,
> >>
> >> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> >>> IOCTL based interface was the natural choice for interacting with the
> >>> quote generation machine at a time when there wasn't anything better.
> >>> Fortunately, now we have a vendor-agnostic, configfs-based one which
> >>> obviates the need to have the IOCTL-based interface.
> >>>
> >>> Gate the relevant code behind a Kconfig option, clearly marking it as
> >>> deprecated as well as introduce a runtime warning.
> >>>
> >>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> >>> ---
> >> In the following thread, Dan Middleton raised a point about this interface
> >> being used for local attestation use cases.
> >>
> >> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
> >>
> >> Currently, the configfs-based ABI does not support the local attestation use cases.
> > What are local attestation use cases, and what happens if Linux does not
> > provide a local attestation interface and standardizes on remotely
> > attestable as the standard?
> 
> 
> Local attestation is used by one TD on the same platform to prove to another TD
> in the same platform about its identity. It is mainly used in cases where a TD provides
> some special services required by other TDs. Since they are all in the same platform,
> there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
> to check the correctness of the TD.

As an example of where this might be needed, consider supporting a vTPM in
TDX. The TPM impl would likely be run in a separate service TD, and need to
be locally attested by the primary TD, to establish trust in the vTPM.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dan Williams]

Kuppuswamy Sathyanarayanan wrote:
> 
> On 1/31/24 11:50 AM, Dan Williams wrote:
> > Kuppuswamy Sathyanarayanan wrote:
> >> + Dan Middleton
> >>
> >> Hi Boris,
> >>
> >> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> >>> IOCTL based interface was the natural choice for interacting with the
> >>> quote generation machine at a time when there wasn't anything better.
> >>> Fortunately, now we have a vendor-agnostic, configfs-based one which
> >>> obviates the need to have the IOCTL-based interface.
> >>>
> >>> Gate the relevant code behind a Kconfig option, clearly marking it as
> >>> deprecated as well as introduce a runtime warning.
> >>>
> >>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> >>> ---
> >> In the following thread, Dan Middleton raised a point about this interface
> >> being used for local attestation use cases.
> >>
> >> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
> >>
> >> Currently, the configfs-based ABI does not support the local attestation use cases.
> > What are local attestation use cases, and what happens if Linux does not
> > provide a local attestation interface and standardizes on remotely
> > attestable as the standard?
> 
> 
> Local attestation is used by one TD on the same platform to prove to another TD
> in the same platform about its identity. It is mainly used in cases where a TD provides
> some special services required by other TDs. Since they are all in the same platform,
> there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
> to check the correctness of the TD.
> 
> I am not sure about actual local attestation users. May be Dan can share that info.
> 
> Regarding your question about using "remotely attestable as the standard", I think
> remote attestation can handle all local attestation use cases. But, does it make sense to
> force users to run a Quoting service if they don't need to communicate with 3rd party
> servers?

SEV-SNP seems to get by without a local attestation flow, if I am not
mistaken, so the question is why should the kernel support cross-vendor
divergence here? Remember, the kernel ends up being the "standardization
body of last resort", it does not need to onboard all the complexity it
can find.

> SGX also seems to have local attestation concept
> 
> https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation/inter-process-local-attestation

I am less concerned with concepts, and more concerned with use cases.
For example it could be the case that configfs-tsm needs to grow to
support local attestation for multiple vendors, but that should be due
to concrete use cases to be deployed, not theoretical observations.

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dan Williams]

Daniel P. Berrangé wrote:
> On Wed, Jan 31, 2024 at 12:44:46PM -0800, Kuppuswamy Sathyanarayanan wrote:
> > 
> > On 1/31/24 11:50 AM, Dan Williams wrote:
> > > Kuppuswamy Sathyanarayanan wrote:
> > >> + Dan Middleton
> > >>
> > >> Hi Boris,
> > >>
> > >> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> > >>> IOCTL based interface was the natural choice for interacting with the
> > >>> quote generation machine at a time when there wasn't anything better.
> > >>> Fortunately, now we have a vendor-agnostic, configfs-based one which
> > >>> obviates the need to have the IOCTL-based interface.
> > >>>
> > >>> Gate the relevant code behind a Kconfig option, clearly marking it as
> > >>> deprecated as well as introduce a runtime warning.
> > >>>
> > >>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> > >>> ---
> > >> In the following thread, Dan Middleton raised a point about this interface
> > >> being used for local attestation use cases.
> > >>
> > >> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
> > >>
> > >> Currently, the configfs-based ABI does not support the local attestation use cases.
> > > What are local attestation use cases, and what happens if Linux does not
> > > provide a local attestation interface and standardizes on remotely
> > > attestable as the standard?
> > 
> > 
> > Local attestation is used by one TD on the same platform to prove to another TD
> > in the same platform about its identity. It is mainly used in cases where a TD provides
> > some special services required by other TDs. Since they are all in the same platform,
> > there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
> > to check the correctness of the TD.
> 
> As an example of where this might be needed, consider supporting a vTPM in
> TDX. The TPM impl would likely be run in a separate service TD, and need to
> be locally attested by the primary TD, to establish trust in the vTPM.

Service TDs are in active deployment? How does that work? A tenant pays
the fees to host 2 VMs? Is that more economical than just communicating
the remote verifier? Not trying to be argumentative just trying to get
to the root of the question "why Linux must care about local
attestation".

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Kuppuswamy Sathyanarayanan]

On 1/31/24 1:12 PM, Dan Williams wrote:
> Daniel P. Berrangé wrote:
>> On Wed, Jan 31, 2024 at 12:44:46PM -0800, Kuppuswamy Sathyanarayanan wrote:
>>> On 1/31/24 11:50 AM, Dan Williams wrote:
>>>> Kuppuswamy Sathyanarayanan wrote:
>>>>> + Dan Middleton
>>>>>
>>>>> Hi Boris,
>>>>>
>>>>> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
>>>>>> IOCTL based interface was the natural choice for interacting with the
>>>>>> quote generation machine at a time when there wasn't anything better.
>>>>>> Fortunately, now we have a vendor-agnostic, configfs-based one which
>>>>>> obviates the need to have the IOCTL-based interface.
>>>>>>
>>>>>> Gate the relevant code behind a Kconfig option, clearly marking it as
>>>>>> deprecated as well as introduce a runtime warning.
>>>>>>
>>>>>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
>>>>>> ---
>>>>> In the following thread, Dan Middleton raised a point about this interface
>>>>> being used for local attestation use cases.
>>>>>
>>>>> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
>>>>>
>>>>> Currently, the configfs-based ABI does not support the local attestation use cases.
>>>> What are local attestation use cases, and what happens if Linux does not
>>>> provide a local attestation interface and standardizes on remotely
>>>> attestable as the standard?
>>>
>>> Local attestation is used by one TD on the same platform to prove to another TD
>>> in the same platform about its identity. It is mainly used in cases where a TD provides
>>> some special services required by other TDs. Since they are all in the same platform,
>>> there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
>>> to check the correctness of the TD.
>> As an example of where this might be needed, consider supporting a vTPM in
>> TDX. The TPM impl would likely be run in a separate service TD, and need to
>> be locally attested by the primary TD, to establish trust in the vTPM.
> Service TDs are in active deployment? How does that work? A tenant pays
> the fees to host 2 VMs? Is that more economical than just communicating

For scalability or security reasons, CSPs can choose to host the VMM services
in a separate VM guest. Since the service VM guest generally extends the TCB
of the tenant VM guest to which it provides service to, it is considered secure. A
single service VM can provide service to multiple tenant VMs. Since service VM
implements host services, I don't think tenant has to pay for two VMs.

In TDX, we already use service TDs for  TD Migration. Related TVMCALLs are defined
in TDX 1.5 GHCI specification, section "TDG.VP.VMCALL <Service>"
(https://cdrdv2.intel.com/v1/dl/getContent/726792)

> the remote verifier? Not trying to be argumentative just trying to get
> to the root of the question "why Linux must care about local
> attestation".

I think the main use case is when a tenant VM wants to use services provided
by a service VM in the same platform.

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Haitao Huang]

On Wed, 31 Jan 2024 13:05:16 -0600, Dave Hansen <dave.hansen@intel.com>  
wrote:

> On 1/31/24 10:18, Nikolay Borisov wrote:
>>> There is no clear consensus from this changelog, nor the tags about  
>>> this
>>> approach.  It would be much appreciated if you could make this  
>>> changelog
>>> more freestanding and  make it clear that this approach is acceptable  
>>> to
>>> both the authors and users of the code you are modifying.
>>
>> So how about something along the lines of:
>>
>> IOCTL based interface was the natural choice for interacting with the
>> quote generation machine at a time when there wasn't anything better. In
>> its current form it's only usable for local attestation but that use
>> case is also going to be switched to the config-tsm interface. In
>> preparation for this introduce a Kconfig option which allows the user to
>> choose to disable the legacy code.
>
> That's an interesting theory.  Do the users and authors of the TDX code
> you're Kconfig'ing away agree with you?
>

As DanM pointed out [1], this ioctl() is not a duplicate of the current  
configfs-tsm ABI. And Local Attestation is a use case mentioned. Can we  
wait until there are two platforms requiring this interface and we have a  
clear idea what the configfs-tsm interface replacement of it is before  
deprecating? A Kconfig to deprecate without alternative implemented also  
does not make sense to me.

BR
Haitao

[1]https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dan Williams]

Haitao Huang wrote:
> On Wed, 31 Jan 2024 13:05:16 -0600, Dave Hansen <dave.hansen@intel.com>  
> wrote:
> 
> > On 1/31/24 10:18, Nikolay Borisov wrote:
> >>> There is no clear consensus from this changelog, nor the tags about  
> >>> this
> >>> approach.  It would be much appreciated if you could make this  
> >>> changelog
> >>> more freestanding and  make it clear that this approach is acceptable  
> >>> to
> >>> both the authors and users of the code you are modifying.
> >>
> >> So how about something along the lines of:
> >>
> >> IOCTL based interface was the natural choice for interacting with the
> >> quote generation machine at a time when there wasn't anything better. In
> >> its current form it's only usable for local attestation but that use
> >> case is also going to be switched to the config-tsm interface. In
> >> preparation for this introduce a Kconfig option which allows the user to
> >> choose to disable the legacy code.
> >
> > That's an interesting theory.  Do the users and authors of the TDX code
> > you're Kconfig'ing away agree with you?
> >
> 
> As DanM pointed out [1], this ioctl() is not a duplicate of the current  
> configfs-tsm ABI. And Local Attestation is a use case mentioned. Can we  
> wait until there are two platforms requiring this interface and we have a  
> clear idea what the configfs-tsm interface replacement of it is before  
> deprecating? A Kconfig to deprecate without alternative implemented also  
> does not make sense to me.

Exactly, that's why I asked for the migration path to be made clear in
the changelog for the deprecation patch.

As far as configfs-tsm is concerned it is just a blob transport, whether
the blob is a "quote" or a "report" does not rely matter, but what
matters is users, clearly identifying the blob formats that might be
returned, and limiting backwards incompatible blob format changes.

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Daniel P. Berrangé]

On Wed, Jan 31, 2024 at 01:12:45PM -0800, Dan Williams wrote:
> Daniel P. Berrangé wrote:
> > On Wed, Jan 31, 2024 at 12:44:46PM -0800, Kuppuswamy Sathyanarayanan wrote:
> > > 
> > > On 1/31/24 11:50 AM, Dan Williams wrote:
> > > > Kuppuswamy Sathyanarayanan wrote:
> > > >> + Dan Middleton
> > > >>
> > > >> Hi Boris,
> > > >>
> > > >> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> > > >>> IOCTL based interface was the natural choice for interacting with the
> > > >>> quote generation machine at a time when there wasn't anything better.
> > > >>> Fortunately, now we have a vendor-agnostic, configfs-based one which
> > > >>> obviates the need to have the IOCTL-based interface.
> > > >>>
> > > >>> Gate the relevant code behind a Kconfig option, clearly marking it as
> > > >>> deprecated as well as introduce a runtime warning.
> > > >>>
> > > >>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> > > >>> ---
> > > >> In the following thread, Dan Middleton raised a point about this interface
> > > >> being used for local attestation use cases.
> > > >>
> > > >> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
> > > >>
> > > >> Currently, the configfs-based ABI does not support the local attestation use cases.
> > > > What are local attestation use cases, and what happens if Linux does not
> > > > provide a local attestation interface and standardizes on remotely
> > > > attestable as the standard?
> > > 
> > > 
> > > Local attestation is used by one TD on the same platform to prove to another TD
> > > in the same platform about its identity. It is mainly used in cases where a TD provides
> > > some special services required by other TDs. Since they are all in the same platform,
> > > there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
> > > to check the correctness of the TD.
> > 
> > As an example of where this might be needed, consider supporting a vTPM in
> > TDX. The TPM impl would likely be run in a separate service TD, and need to
> > be locally attested by the primary TD, to establish trust in the vTPM.
> 
> Service TDs are in active deployment? How does that work? A tenant pays
> the fees to host 2 VMs? Is that more economical than just communicating
> the remote verifier? Not trying to be argumentative just trying to get
> to the root of the question "why Linux must care about local
> attestation".

Any VM you buy has host resource overhead beyond the VM's declared resources,
and whether you realize it or not, as a user you are paying for this extra
resource consumption.

With KVM today, vTPM will involve each VM having a separate swtpm process
running alongside QEMU in the host, and of course QEMU itself has resource
consumption which can be fairly significant.  A Cloud provider will have to
take account of the additional per-VM overheads when calculating their
potential host capacity for running VMs & thus setting their VM price. 

In a TDX scenario this separate swtpm turns into something that runs inside
a minimal TDVM instead. The RAM overhead may be larger than with swtpm, but
for a cloud provider its merely one more factor to take account of when
setting their price vs host capacity.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Mikko Ylinen]

On Wed, Jan 31, 2024 at 01:09:03PM -0800, Dan Williams wrote:
> Kuppuswamy Sathyanarayanan wrote:
> > 
> > On 1/31/24 11:50 AM, Dan Williams wrote:
> > > Kuppuswamy Sathyanarayanan wrote:
> > >> + Dan Middleton
> > >>
> > >> Hi Boris,
> > >>
> > >> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
> > >>> IOCTL based interface was the natural choice for interacting with the
> > >>> quote generation machine at a time when there wasn't anything better.
> > >>> Fortunately, now we have a vendor-agnostic, configfs-based one which
> > >>> obviates the need to have the IOCTL-based interface.
> > >>>
> > >>> Gate the relevant code behind a Kconfig option, clearly marking it as
> > >>> deprecated as well as introduce a runtime warning.
> > >>>
> > >>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
> > >>> ---
> > >> In the following thread, Dan Middleton raised a point about this interface
> > >> being used for local attestation use cases.
> > >>
> > >> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
> > >>
> > >> Currently, the configfs-based ABI does not support the local attestation use cases.
> > > What are local attestation use cases, and what happens if Linux does not
> > > provide a local attestation interface and standardizes on remotely
> > > attestable as the standard?
> > 
> > 
> > Local attestation is used by one TD on the same platform to prove to another TD
> > in the same platform about its identity. It is mainly used in cases where a TD provides
> > some special services required by other TDs. Since they are all in the same platform,
> > there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
> > to check the correctness of the TD.
> > 
> > I am not sure about actual local attestation users. May be Dan can share that info.
> > 
> > Regarding your question about using "remotely attestable as the standard", I think
> > remote attestation can handle all local attestation use cases. But, does it make sense to
> > force users to run a Quoting service if they don't need to communicate with 3rd party
> > servers?
> 
> SEV-SNP seems to get by without a local attestation flow, if I am not
> mistaken, so the question is why should the kernel support cross-vendor
> divergence here? Remember, the kernel ends up being the "standardization
> body of last resort", it does not need to onboard all the complexity it
> can find.
> 
> > SGX also seems to have local attestation concept
> > 
> > https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation/inter-process-local-attestation
> 
> I am less concerned with concepts, and more concerned with use cases.
> For example it could be the case that configfs-tsm needs to grow to
> support local attestation for multiple vendors, but that should be due
> to concrete use cases to be deployed, not theoretical observations.

Confidential Containers project started using the tdx_guest ioctl() to get
the TD report. This is used by the attestation-agent to check that the hash
of a policy file is correctly included in the TD report's MRCONFIGID field.

The report stays within the TD and there's no need take it to the host QGS
quoting service for signing. Right now we need to go to configs-tsm for
the quote and tdx_guest ioctl() for the TD report.

The corresponding SNP check in this use case is to get the HOSTDATA report
field by using 'get report' ioctl() (non-ext version is enough). With
configfs-tsm this is same as using just 'outblob' and ignoring 'auxblob',
AFAICS.

However, perhaps some generic report 'type' TSM report attribute would be
justified here to allow users select between TD report/quote and
report/ext_report generation?

-- Regards, Mikko

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dan Middleton]

On 2/8/24 7:42 AM, Mikko Ylinen wrote:
> On Wed, Jan 31, 2024 at 01:09:03PM -0800, Dan Williams wrote:
>> Kuppuswamy Sathyanarayanan wrote:
>>> On 1/31/24 11:50 AM, Dan Williams wrote:
>>>> Kuppuswamy Sathyanarayanan wrote:
>>>>> + Dan Middleton
>>>>>
>>>>> Hi Boris,
>>>>>
>>>>> On 1/24/24 1:38 AM, Nikolay Borisov wrote:
>>>>>> IOCTL based interface was the natural choice for interacting with the
>>>>>> quote generation machine at a time when there wasn't anything better.
>>>>>> Fortunately, now we have a vendor-agnostic, configfs-based one which
>>>>>> obviates the need to have the IOCTL-based interface.
>>>>>>
>>>>>> Gate the relevant code behind a Kconfig option, clearly marking it as
>>>>>> deprecated as well as introduce a runtime warning.
>>>>>>
>>>>>> Signed-off-by: Nikolay Borisov <nik.borisov@suse.com>
>>>>>> ---
>>>>> In the following thread, Dan Middleton raised a point about this interface
>>>>> being used for local attestation use cases.
>>>>>
>>>>> https://lore.kernel.org/all/ZbAaKAh-230Hj4BF@redhat.com/T/#m691dae9a7833a35552cafb597c838df9c2ed5f3a
>>>>>
>>>>> Currently, the configfs-based ABI does not support the local attestation use cases.
>>>> What are local attestation use cases, and what happens if Linux does not
>>>> provide a local attestation interface and standardizes on remotely
>>>> attestable as the standard?
>>>
>>> Local attestation is used by one TD on the same platform to prove to another TD
>>> in the same platform about its identity. It is mainly used in cases where a TD provides
>>> some special services required by other TDs. Since they are all in the same platform,
>>> there is no need for a 3rd party verifier or Quoting service. It can use the verifiable MAC
>>> to check the correctness of the TD.
>>>
>>> I am not sure about actual local attestation users. May be Dan can share that info.
>>>
>>> Regarding your question about using "remotely attestable as the standard", I think
>>> remote attestation can handle all local attestation use cases. But, does it make sense to
>>> force users to run a Quoting service if they don't need to communicate with 3rd party
>>> servers?
>> SEV-SNP seems to get by without a local attestation flow, if I am not
>> mistaken, so the question is why should the kernel support cross-vendor
>> divergence here? Remember, the kernel ends up being the "standardization
>> body of last resort", it does not need to onboard all the complexity it
>> can find.
>>
>>> SGX also seems to have local attestation concept
>>>
>>> https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation/inter-process-local-attestation
>> I am less concerned with concepts, and more concerned with use cases.
>> For example it could be the case that configfs-tsm needs to grow to
>> support local attestation for multiple vendors, but that should be due
>> to concrete use cases to be deployed, not theoretical observations.
> Confidential Containers project started using the tdx_guest ioctl() to get
> the TD report. This is used by the attestation-agent to check that the hash
> of a policy file is correctly included in the TD report's MRCONFIGID field.
>
> The report stays within the TD and there's no need take it to the host QGS
> quoting service for signing. Right now we need to go to configs-tsm for
> the quote and tdx_guest ioctl() for the TD report.
>
> The corresponding SNP check in this use case is to get the HOSTDATA report
> field by using 'get report' ioctl() (non-ext version is enough). With
> configfs-tsm this is same as using just 'outblob' and ignoring 'auxblob',
> AFAICS.
>
> However, perhaps some generic report 'type' TSM report attribute would be
> justified here to allow users select between TD report/quote and
> report/ext_report generation?
>
> -- Regards, Mikko
Sorry, I somehow missed the continuation of this thread.

I think there's a couple use cases mentioned here including
1. Service TDs like vTPM (there is code for this[1]. I can't speak to 
its adoption.)

2. Locally verifiable evidence as visible in CNCF CoCo (thanks Mikko).

I don't think it should be deprecated until / unless there is a
committed alternative like a configfs-tsm feature.
I don't know the kernel community's preference for a single vendor
configfs-tsm feature vs a single vendor ioctl.

I would suspect that other vendors will offer local attestations based
on local appearing in SGX and TDX, but that's speculation. If so their
APIs would better inform a new common configfs-tsm feature.
Maybe people with knowledge of AMD, Arm, and RISC-V disclosed plans can

comment.


[1] https://github.com/intel/vtpm-td/tree/main


Thanks,
Dan Middleton

Re: [PATCH] virt: tdx-guest: Deprecate legacy IOCTL-based interface for quote generation

[Dan Williams]

Dan Middleton wrote:
[..]
> I would suspect that other vendors will offer local attestations based
> on local appearing in SGX and TDX, but that's speculation. If so their
> APIs would better inform a new common configfs-tsm feature.
> Maybe people with knowledge of AMD, Arm, and RISC-V disclosed plans can
> comment.

FWIW, I am looking at resolution of this proposal [1] as providing the
configfs-tsm infrastructure to trigger the deprecation of the tdx-guest
report ioctl().  I.e. once configfs-tsm generically supports local
attestation flows then software has a migration path.

Comments from folks on this thread welcome over there [1].

[1]: http://lore.kernel.org/r/cover.1706307364.git.thomas.lendacky@amd.com