[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a0f64809-d85f-e67f-4938-760db1946b68@linux.intel.com>
Date: Sat, 16 Oct 2021 20:49:34 -0700
From: Sathyanarayanan Kuppuswamy
<sathyanarayanan.kuppuswamy@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, Paolo Bonzini <pbonzini@...hat.com>,
David Hildenbrand <david@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Juergen Gross <jgross@...e.com>, Deep Shah <sdeep@...are.com>,
VMware Inc <pv-drivers@...are.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>
Cc: Peter H Anvin <hpa@...or.com>, Tony Luck <tony.luck@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
Andi Kleen <ak@...ux.intel.com>,
Kirill Shutemov <kirill.shutemov@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>,
Kuppuswamy Sathyanarayanan <knsathya@...nel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v10 06/11] x86/traps: Add #VE support for TDX guest
On 10/16/21 8:18 PM, Dave Hansen wrote:
> On 10/16/21 7:45 PM, Sathyanarayanan Kuppuswamy wrote:
>>>> +bool tdx_get_ve_info(struct ve_info *ve)
>>>> +{
>>>> + struct tdx_module_output out;
>>>> + u64 ret;
>>>> +
>>>> + if (!ve)
>>>> + return false;
>>> This should be WARN_ON_ONCE() if at all.
>> This is an input validation. Since we need to de-reference "ve" in
>> the following code, we want to validate it to avoid NULL pointer
>> exception. As per current usage of this function, "ve" will not be
>> NULL. But we have added this check as a extra precaution against
>> future use cases.
> Input validation, eh?
>
> It's one thing if this argument comes from userspace, or is even open
> for modules to call. You *might* have an argument that it should be
> checked in case something in the kernel goes insane.
>
> But, there's a single call site. It looks like this:
As per current use cases (exc_virtualization_exception() &
tdx_early_handle_ve()), it will never happen. As I have mentioned,
it was added as a precaution against the future use case or any
misuse of this function in kernel. We did not have this check
initially. But was added later due to review suggestion.
But I am fine with removing it if it is required.
>
>> +DEFINE_IDTENTRY(exc_virtualization_exception)
>> +{
>> + struct ve_info ve;
> ...
>> + ret = tdx_get_ve_info(&ve);
> Could you please explain, given the existing kernel code, how !ve could
> ever possibly happen? Or, how tdx_get_ve_info() might conceivably ever
> be called from another path which is not extremely well controlled?
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Powered by blists - more mailing lists