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]
Message-ID: <332547a2332121313bf6d00c9eaf71136b48696b.camel@intel.com>
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?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ