From: Isaku Yamahata <isaku.yamahata@gmail.com>
To: Kai Huang <kai.huang@intel.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
dave.hansen@intel.com, seanjc@google.com, pbonzini@redhat.com,
kirill.shutemov@linux.intel.com,
sathyanarayanan.kuppuswamy@linux.intel.com, peterz@infradead.org,
tony.luck@intel.com, ak@linux.intel.com,
dan.j.williams@intel.com, isaku.yamahata@intel.com,
isaku.yamahata@gmail.com
Subject: Re: [PATCH v2 09/21] x86/virt/tdx: Get information about TDX module and convertible memory
Date: Thu, 24 Mar 2022 10:43:01 -0700 [thread overview]
Message-ID: <20220324174301.GA1212881@ls.amr.corp.intel.com> (raw)
In-Reply-To: <98c1010509aa412e7f05b12187cacf40451d5246.1647167475.git.kai.huang@intel.com>
On Sun, Mar 13, 2022 at 11:49:49PM +1300,
Kai Huang <kai.huang@intel.com> wrote:
> TDX provides increased levels of memory confidentiality and integrity.
> This requires special hardware support for features like memory
> encryption and storage of memory integrity checksums. Not all memory
> satisfies these requirements.
>
> As a result, TDX introduced the concept of a "Convertible Memory Region"
> (CMR). During boot, the firmware builds a list of all of the memory
> ranges which can provide the TDX security guarantees. The list of these
> ranges, along with TDX module information, is available to the kernel by
> querying the TDX module via TDH.SYS.INFO SEAMCALL.
>
> Host kernel can choose whether or not to use all convertible memory
> regions as TDX memory. Before TDX module is ready to create any TD
> guests, all TDX memory regions that host kernel intends to use must be
> configured to the TDX module, using specific data structures defined by
> TDX architecture. Constructing those structures requires information of
> both TDX module and the Convertible Memory Regions. Call TDH.SYS.INFO
> to get this information as preparation to construct those structures.
>
> Signed-off-by: Kai Huang <kai.huang@intel.com>
> ---
> arch/x86/virt/vmx/tdx.c | 127 ++++++++++++++++++++++++++++++++++++++++
> arch/x86/virt/vmx/tdx.h | 61 +++++++++++++++++++
> 2 files changed, 188 insertions(+)
>
> diff --git a/arch/x86/virt/vmx/tdx.c b/arch/x86/virt/vmx/tdx.c
> index 4b0c285d844b..eb585bc5edda 100644
> --- a/arch/x86/virt/vmx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx.c
> @@ -80,6 +80,11 @@ static DEFINE_MUTEX(tdx_module_lock);
>
> static struct p_seamldr_info p_seamldr_info;
>
> +/* Base address of CMR array needs to be 512 bytes aligned. */
> +static struct cmr_info tdx_cmr_array[MAX_CMRS] __aligned(CMR_INFO_ARRAY_ALIGNMENT);
> +static int tdx_cmr_num;
> +static struct tdsysinfo_struct tdx_sysinfo;
> +
> static bool __seamrr_enabled(void)
> {
> return (seamrr_mask & SEAMRR_ENABLED_BITS) == SEAMRR_ENABLED_BITS;
> @@ -468,6 +473,123 @@ static int tdx_module_init_cpus(void)
> return seamcall_on_each_cpu(&sc);
> }
>
> +static inline bool cmr_valid(struct cmr_info *cmr)
> +{
> + return !!cmr->size;
> +}
> +
> +static void print_cmrs(struct cmr_info *cmr_array, int cmr_num,
> + const char *name)
> +{
> + int i;
> +
> + for (i = 0; i < cmr_num; i++) {
> + struct cmr_info *cmr = &cmr_array[i];
> +
> + pr_info("%s : [0x%llx, 0x%llx)\n", name,
> + cmr->base, cmr->base + cmr->size);
> + }
> +}
> +
> +static int sanitize_cmrs(struct cmr_info *cmr_array, int cmr_num)
> +{
> + int i, j;
> +
> + /*
> + * Intel TDX module spec, 20.7.3 CMR_INFO:
> + *
> + * TDH.SYS.INFO leaf function returns a MAX_CMRS (32) entry
> + * array of CMR_INFO entries. The CMRs are sorted from the
> + * lowest base address to the highest base address, and they
> + * are non-overlapping.
> + *
> + * This implies that BIOS may generate invalid empty entries
> + * if total CMRs are less than 32. Skip them manually.
> + */
> + for (i = 0; i < cmr_num; i++) {
> + struct cmr_info *cmr = &cmr_array[i];
> + struct cmr_info *prev_cmr = NULL;
> +
> + /* Skip further invalid CMRs */
> + if (!cmr_valid(cmr))
> + break;
> +
> + if (i > 0)
> + prev_cmr = &cmr_array[i - 1];
> +
> + /*
> + * It is a TDX firmware bug if CMRs are not
> + * in address ascending order.
> + */
> + if (prev_cmr && ((prev_cmr->base + prev_cmr->size) >
> + cmr->base)) {
> + pr_err("Firmware bug: CMRs not in address ascending order.\n");
> + return -EFAULT;
> + }
> + }
> +
> + /*
> + * Also a sane BIOS should never generate invalid CMR(s) between
> + * two valid CMRs. Sanity check this and simply return error in
> + * this case.
> + */
> + for (j = i; j < cmr_num; j++)
> + if (cmr_valid(&cmr_array[j])) {
> + pr_err("Firmware bug: invalid CMR(s) among valid CMRs.\n");
> + return -EFAULT;
> + }
This check doesn't make sense because above i-for loop has break.
> +
> + /*
> + * Trim all tail invalid empty CMRs. BIOS should generate at
> + * least one valid CMR, otherwise it's a TDX firmware bug.
> + */
> + tdx_cmr_num = i;
> + if (!tdx_cmr_num) {
> + pr_err("Firmware bug: No valid CMR.\n");
> + return -EFAULT;
> + }
Something strange.
Probably we'd like to check it by decrementing.
for (i = cmr_num; i >= 0; i--)
if (!cmr_valid()) // if last invalid cmr
tdx_cmr_num
// more check. overlapping
--
Isaku Yamahata <isaku.yamahata@gmail.com>
next prev parent reply other threads:[~2022-03-24 17:43 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-13 10:49 [PATCH v2 00/21] TDX host kernel support Kai Huang
2022-03-13 10:49 ` [PATCH v2 01/21] x86/virt/tdx: Detect SEAM Kai Huang
2022-03-23 3:21 ` Tian, Kevin
2022-03-28 3:55 ` Kai Huang
2022-03-28 8:10 ` Tian, Kevin
2022-03-29 17:52 ` Isaku Yamahata
2022-03-29 23:28 ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 02/21] x86/virt/tdx: Detect TDX private KeyIDs Kai Huang
2022-03-13 10:49 ` [PATCH v2 03/21] x86/virt/tdx: Implement the SEAMCALL base function Kai Huang
2022-03-23 3:35 ` Tian, Kevin
2022-03-28 1:41 ` Kai Huang
2022-03-28 8:16 ` Tian, Kevin
2022-03-28 9:10 ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 04/21] x86/virt/tdx: Add skeleton for detecting and initializing TDX on demand Kai Huang
2022-03-23 6:49 ` Tian, Kevin
2022-03-28 1:57 ` Kai Huang
2022-03-28 8:26 ` Tian, Kevin
2022-03-28 9:24 ` Kai Huang
2022-03-28 11:47 ` Tian, Kevin
2022-03-28 22:55 ` Kai Huang
2022-03-29 2:36 ` Tian, Kevin
2022-03-29 3:10 ` Kai Huang
2022-03-29 3:17 ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 05/21] x86/virt/tdx: Detect P-SEAMLDR and TDX module Kai Huang
2022-03-13 10:49 ` [PATCH v2 06/21] x86/virt/tdx: Shut down TDX module in case of error Kai Huang
2022-03-13 10:49 ` [PATCH v2 07/21] x86/virt/tdx: Do TDX module global initialization Kai Huang
2022-03-13 10:49 ` [PATCH v2 08/21] x86/virt/tdx: Do logical-cpu scope TDX module initialization Kai Huang
2022-03-13 10:49 ` [PATCH v2 09/21] x86/virt/tdx: Get information about TDX module and convertible memory Kai Huang
2022-03-24 17:43 ` Isaku Yamahata [this message]
2022-03-28 1:30 ` Kai Huang
2022-03-28 20:22 ` Isaku Yamahata
2022-03-28 20:30 ` Dave Hansen
2022-03-28 23:40 ` Kai Huang
2022-03-28 23:44 ` Dave Hansen
2022-03-29 0:04 ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 10/21] x86/virt/tdx: Add placeholder to coveret all system RAM as TDX memory Kai Huang
2022-03-13 10:49 ` [PATCH v2 11/21] x86/virt/tdx: Choose to use " Kai Huang
2022-03-13 10:49 ` [PATCH v2 12/21] x86/virt/tdx: Create TDMRs to cover all system RAM Kai Huang
2022-03-13 10:49 ` [PATCH v2 13/21] x86/virt/tdx: Allocate and set up PAMTs for TDMRs Kai Huang
2022-03-24 18:06 ` Isaku Yamahata
2022-03-28 1:16 ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 14/21] x86/virt/tdx: Set up reserved areas for all TDMRs Kai Huang
2022-03-13 10:49 ` [PATCH v2 15/21] x86/virt/tdx: Reserve TDX module global KeyID Kai Huang
2022-03-13 10:49 ` [PATCH v2 16/21] x86/virt/tdx: Configure TDX module with TDMRs and " Kai Huang
2022-03-13 10:49 ` [PATCH v2 17/21] x86/virt/tdx: Configure global KeyID on all packages Kai Huang
2022-03-24 18:18 ` isaku.yamahata
2022-03-28 1:19 ` Kai Huang
2022-03-13 10:49 ` [PATCH v2 18/21] x86/virt/tdx: Initialize all TDMRs Kai Huang
2022-03-13 10:49 ` [PATCH v2 19/21] x86: Flush cache of TDX private memory during kexec() Kai Huang
2022-03-13 10:50 ` [PATCH v2 20/21] x86/virt/tdx: Add kernel command line to opt-in TDX host support Kai Huang
2022-03-13 10:50 ` [PATCH v2 21/21] Documentation/x86: Add documentation for " Kai Huang
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=20220324174301.GA1212881@ls.amr.corp.intel.com \
--to=isaku.yamahata@gmail.com \
--cc=ak@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tony.luck@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;
as well as URLs for NNTP newsgroup(s).