linux-kernel - Re: [PATCH v11 11/20] x86/virt/tdx: Fill out TDMRs to cover all TDX memory regions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ddbcadf36016bb60a695f54b28f5c9e9af53a07f.camel@intel.com>
Date:   Thu, 8 Jun 2023 10:48:59 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "Luck, Tony" <tony.luck@...el.com>,
        "david@...hat.com" <david@...hat.com>,
        "bagasdotme@...il.com" <bagasdotme@...il.com>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "Chatre, Reinette" <reinette.chatre@...el.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "Shahar, Sagi" <sagis@...gle.com>,
        "imammedo@...hat.com" <imammedo@...hat.com>,
        "Gao, Chao" <chao.gao@...el.com>,
        "Brown, Len" <len.brown@...el.com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [PATCH v11 11/20] x86/virt/tdx: Fill out TDMRs to cover all TDX
 memory regions

On Wed, 2023-06-07 at 09:05 -0700, Dave Hansen wrote:
> On 6/4/23 07:27, Kai Huang wrote:
> > +	/*
> > +	 * Loop over TDX memory regions and fill out TDMRs to cover them.
> > +	 * To keep it simple, always try to use one TDMR to cover one
> > +	 * memory region.
> > +	 *
> > +	 * In practice TDX1.0 supports 64 TDMRs, which is big enough to
> > +	 * cover all memory regions in reality if the admin doesn't use
> > +	 * 'memmap' to create a bunch of discrete memory regions.  When
> > +	 * there's a real problem, enhancement can be done to merge TDMRs
> > +	 * to reduce the final number of TDMRs.
> > +	 */
> 
> Rather than focus in on one specific command-line parameter, let's just say:
> 
> 	In practice TDX supports at least 64 TDMRs.  A 2-socket system
> 	typically only consumes <NUMBER> of those.  This code is dumb
> 	and simple and may use more TMDRs than is strictly required.

Thanks will do.  Will take a look at machine to get the <NUMBER>.

> 
> Let's also put a pr_warn() in here if we exceed, say 1/2 or maybe 3/4 of
> the 64.  We'll hopefully start to get reports somewhat in advance if
> systems get close to the limit.

May I ask why this is useful?  TDX module can only be initialized once, so if
not considering module runtime update case, the kernel can only get two results
for once: 

1) Succeed to initialize: consumed TDMRs doesn't exceed maximum TDMRs
2) Fail to initialize: consumed TDMRs exceeds maximum TDMRs

What's the value of pr_warn() user when consumed TDMRs exceeds some threshold?

Anyway, if you want it, how does below code look?

 static int fill_out_tdmrs(struct list_head *tmb_list,
                          struct tdmr_info_list *tdmr_list)
 {
+       int consumed_tdmrs_threshold, tdmr_idx = 0;
        struct tdx_memblock *tmb;
-       int tdmr_idx = 0;
 
        /*
         * Loop over TDX memory regions and fill out TDMRs to cover them.
         * To keep it simple, always try to use one TDMR to cover one
         * memory region.
         *
-        * In practice TDX1.0 supports 64 TDMRs, which is big enough to
-        * cover all memory regions in reality if the admin doesn't use
-        * 'memmap' to create a bunch of discrete memory regions.  When
-        * there's a real problem, enhancement can be done to merge TDMRs
-        * to reduce the final number of TDMRs.
+        * In practice TDX supports at least 64 TDMRs.  A 2-socket system
+        * typically only consumes <NUMBER> of those.  This code is dumb
+        * and simple and may use more TMDRs than is strictly required.
+        *
+        * Also set a threshold of consumed TDMRs, and pr_warn() to warn
+        * the user the system is getting close to the limit of supported
+        * number of TDMRs if the number of consumed TDMRs exceeds the
+        * threshold.
         */
+       consumed_tdmrs_threshold = tdmr_list->max_tdmrs * 3 / 4;
        list_for_each_entry(tmb, tmb_list, list) {
                struct tdmr_info *tdmr = tdmr_entry(tdmr_list, tdmr_idx);
                u64 start, end;
@@ -463,6 +467,10 @@ static int fill_out_tdmrs(struct list_head *tmb_list,
                                return -ENOSPC;
                        }
 
+                       if (tdmr_idx == consumed_tdmrs_threshold)
+                               pr_warn("consumed TDMRs reaching limit: %d used
(out of %d)\n",
+                                               tdmr_idx, tdmr_list->max_tdmrs);
+
                        tdmr = tdmr_entry(tdmr_list, tdmr_idx);
                }