mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chao Gao <chao.gao@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
	"kas@kernel.org" <kas@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"yilun.xu@linux.intel.com" <yilun.xu@linux.intel.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"tglx@kernel.org" <tglx@kernel.org>
Subject: Re: [RFC PATCH v2 10/10] x86/virt/tdx: Verify structure member sizes against metadata field IDs
Date: Thu, 24 Sep 2026 15:20:35 +0800	[thread overview]
Message-ID: <arTPQwQunIwfHfN1@intel.com> (raw)
In-Reply-To: <afe70eaadc0906ec17e6b5522881ae09e9f45579.camel@intel.com>

On Thu, Sep 24, 2026 at 06:47:19AM +0800, Edgecombe, Rick P wrote:
>On Fri, 2026-09-18 at 06:29 -0700, Chao Gao wrote:
>> A metadata field ID encodes the size of a single element. TDX_SYSINFO_MAP()
>> instead derives the copy size from the destination member, and nothing
>> verifies that the two sizes agree.
>> 
>> A wrongly typed member is a kernel bug: declaring a u32 for an 8-byte
>> metadata field would silently store only its low 4 bytes.
>> 
>> Add macros to extract the element size encoded in a field ID and verify it
>> against the destination member size at build time.
>
>The two things we could do are extract the field code and check it, or add it
>into the field automatically from the struct size. In the later case the field
>id's would be specified without the size bits already filled in. But since the
>metadata docs have the field code already embedded when they are listed in the
>docs, that is the most natural and easy thing to add to the field id code. It
>makes it easy to search the docs too. So the checking design gives us some extra
>safety, make it easier to add the code and search the docs.

I'll explain in the changelog why we extract the size from the field ID
and check it, rather than building the field ID from the member size.

>
>I think probably you need to explain a bit more about what and why the fieldid
>size bits exist, but I agree with the design.

Sure. I will add:

  TDH.SYS.RD returns every field's value as a u64, but metadata fields
  aren't all 64 bits wide. A field ID encodes the size of one field
  (bits 33:32), so the ID alone gives the field's width.

As for why the size bits exist at all, from the TDX module source it
looks like the module itself uses them: it stores array fields packed
in memory and uses the size to locate each element (offset = index * size).
The kernel doesn't need them except for the size check in this patch.

>
>> +/*
>> + * Sub-field definitions of TDX global metadata field IDs.
>> + *
>> + * See "Metadata Field Identifier" in the Intel TDX Module ABI
>> + * Specification.
>> + *
>> + *  - Bit 33:32: ELEMENT_SIZE_CODE -- log2 of a single metadata
>> + *                                    element's size in bytes
>> + */
>> +#define TDX_MD_FIELD_ELE_SIZE_CODE(field_id)	\
>> +	(((field_id) & GENMASK_ULL(33, 32)) >> 32)
>> +
>> +#define TDX_MD_FIELD_ELE_SIZE(field_id)	\
>> +	(1 << TDX_MD_FIELD_ELE_SIZE_CODE(field_id))
>> +
>
>I'd think these could be squashed together since only TDX_MD_FIELD_ELE_SIZE gets
>used anywhere else.

Sure. Will do.

  reply	other threads:[~2026-09-24  7:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 13:29 [RFC PATCH v2 00/10] TDX: Stop auto-generating the global metadata code Chao Gao
2026-09-18 13:29 ` [RFC PATCH v2 01/10] x86/virt/tdx: Add a helper to read a table of metadata fields Chao Gao
2026-09-23 22:20   ` Edgecombe, Rick P
2026-09-24  5:36     ` Chao Gao
2026-09-24  6:13   ` Binbin Wu
2026-09-18 13:29 ` [RFC PATCH v2 02/10] x86/virt/tdx: Convert the version metadata reader Chao Gao
2026-09-23 22:26   ` Edgecombe, Rick P
2026-09-24  5:50     ` Chao Gao
2026-09-24  6:40   ` Binbin Wu
2026-09-18 13:29 ` [RFC PATCH v2 03/10] x86/virt/tdx: Convert the features " Chao Gao
2026-09-18 13:29 ` [RFC PATCH v2 04/10] x86/virt/tdx: Convert the tdmr " Chao Gao
2026-09-18 13:29 ` [RFC PATCH v2 05/10] x86/virt/tdx: Convert the td_ctrl " Chao Gao
2026-09-18 13:29 ` [RFC PATCH v2 06/10] x86/virt/tdx: Convert the handoff " Chao Gao
2026-09-18 13:29 ` [RFC PATCH v2 07/10] x86/virt/tdx: Convert the td_conf " Chao Gao
2026-09-18 13:29 ` [RFC PATCH v2 08/10] x86/virt/tdx: Remove tdx_global_metadata.c Chao Gao
2026-09-23 22:53   ` Edgecombe, Rick P
2026-09-18 13:29 ` [RFC PATCH v2 09/10] x86/virt/tdx: Use early returns in get_tdx_sys_info() Chao Gao
2026-09-23 22:52   ` Edgecombe, Rick P
2026-09-24  7:28     ` Chao Gao
2026-09-18 13:29 ` [RFC PATCH v2 10/10] x86/virt/tdx: Verify structure member sizes against metadata field IDs Chao Gao
2026-09-23 22:47   ` Edgecombe, Rick P
2026-09-24  7:20     ` Chao Gao [this message]
2026-09-23  0:47 ` [RFC PATCH v2 00/10] TDX: Stop auto-generating the global metadata code Edgecombe, Rick P
2026-09-23  8:23   ` Chao Gao
2026-09-23  5:44 ` Tony Lindgren
2026-09-23  8:19   ` Chao Gao
2026-09-23  8:37     ` Tony Lindgren

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=arTPQwQunIwfHfN1@intel.com \
    --to=chao.gao@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=yilun.xu@linux.intel.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

all inboxes | Powered by JetHome®