linux-kernel - Re: [PATCH v3 07/12] x86/tdx: Make TDX_HYPERCALL asm similar to TDX_MODULE

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:   Thu, 3 Aug 2023 11:56:40 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
CC:     "Hansen, Dave" <dave.hansen@...el.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "n.borisov.lkml@...il.com" <n.borisov.lkml@...il.com>
Subject: Re: [PATCH v3 07/12] x86/tdx: Make TDX_HYPERCALL asm similar to
 TDX_MODULE_CALL

On Thu, 2023-08-03 at 14:45 +0300, kirill.shutemov@...ux.intel.com wrote:
> On Thu, Jul 27, 2023 at 11:05:35PM +0000, Huang, Kai wrote:
> > On Thu, 2023-07-27 at 20:10 +0300, kirill.shutemov@...ux.intel.com wrote:
> > > On Wed, Jul 26, 2023 at 11:25:09PM +1200, Kai Huang wrote:
> > > > 
> > > > Remove the __tdx_hypercall_ret() as __tdx_hypercall() already does so.
> > > 
> > > Hm. So we now update struct on all VMCALLs. Is it a good idea? 
> > > 
> > 
> > Do you mean we "unconditionally save output registers to  the structure", right?
> > 
> > > We give
> > > more control to VMM where it is not needed. 
> > > 
> > 
> > I don't quite follow this.  Can you elaborate?
> > 
> > Do you worry about VMM being malicious and putting malicious values to the
> > registers?
> 
> Yes. Caller of the hypercall may expect that the register is in-only and
> re-use the field for other stuff. And it would work until VMM decide
> otherwise.

I would argue from this way: in TDX_HYPERCALL the guest has shared all registers
to the VMM, thus the caller of hypercall cannot assume those registers is in-
only.

> 
> > > I would rather keep the struct
> > > read-only where possible.
> > > 
> > 
> > We can achieve this if there's a clean way to do, but I don't see that.
> 
> Keep _ret() and non-_ret() versions?

The problem is the assembly needs to always turn on the "\ret" so that the R10
(used as VP.VMCALL leaf return code) can be saved to the structure.  Otherwise
we are not able to return VP.VMCALL leaf return code.

Can you elaborate how to do?