Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ded3e60e-035f-1feb-bb7d-43af0064c544@intel.com>
Date:   Thu, 3 Nov 2022 08:05:14 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH v6 12/21] x86/virt/tdx: Add placeholder to construct TDMRs
 to cover all TDX memory regions
Content-Language: en-US
To:     Andi Kleen <ak@linux.intel.com>, Kai Huang <kai.huang@intel.com>,
        linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc:     linux-mm@kvack.org, seanjc@google.com, pbonzini@redhat.com,
        dan.j.williams@intel.com, rafael.j.wysocki@intel.com,
        kirill.shutemov@linux.intel.com, reinette.chatre@intel.com,
        len.brown@intel.com, tony.luck@intel.com, peterz@infradead.org,
        isaku.yamahata@intel.com, chao.gao@intel.com,
        sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com,
        sagis@google.com, imammedo@redhat.com
References: <cover.1666824663.git.kai.huang@intel.com>
 <fe0e1a1133166ca4008840cd1a5959fa70632f07.1666824663.git.kai.huang@intel.com>
 <f6d0b10a-94be-ff33-9742-058469078380@linux.intel.com>
From:   Dave Hansen <dave.hansen@intel.com>
In-Reply-To: <f6d0b10a-94be-ff33-9742-058469078380@linux.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 10/27/22 08:31, Andi Kleen wrote:
> 
>> +/* Calculate the actual TDMR_INFO size */
>> +static inline int cal_tdmr_size(void)
>> +{
>> +    int tdmr_sz;
>> +
>> +    /*
>> +     * The actual size of TDMR_INFO depends on the maximum number
>> +     * of reserved areas.
>> +     */
>> +    tdmr_sz = sizeof(struct tdmr_info);
>> +    tdmr_sz += sizeof(struct tdmr_reserved_area) *
>> +           tdx_sysinfo.max_reserved_per_tdmr;
> 
> would seem safer to have a overflow check here.

tdmr_reserved_area is 16 bytes.  To overflow a signed int, tdmr_sz would
need to be for an allocation >2GB.  alloc_pages_exact() tops out at
supplying 4MB allocations.

So, sure, this breaks at max_reserved_per_tdmr>2^27, but it actually
breaks *EARLIER* at max_reserved_per_tdmr>2^18 because the page
allocator is borked.

Plus, max_reserved_per_tdmr is barely in double digits today.  It's a
*LOOOOOOOOONG* way from either of those limits.  If you want to add a
warning here, then go for it and enforce a sane value on
max_reserved_per_tdmr.

But, the overflow is *LITERALLY* an order of magnitude more obscure than
overwhelming the page allocator.  Let's not clutter up the code with
silly checks like that.