linux-kernel - Re: [PATCH v10 06/11] x86/traps: Add #VE support for TDX guest

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 16 Oct 2021 20:18:34 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Sathyanarayanan Kuppuswamy 
        <sathyanarayanan.kuppuswamy@...ux.intel.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 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:

> +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?