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

[Sathyanarayanan Kuppuswamy]

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