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] [day] [month] [year] [list]
Date: Thu, 27 Jun 2024 00:15:57 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "Gao, Chao" <chao.gao@...el.com>,
	"Yuan, Hang" <hang.yuan@...el.com>, "Huang, Kai" <kai.huang@...el.com>,
	"Chen, Bo2" <chen.bo@...el.com>, "sagis@...gle.com" <sagis@...gle.com>,
	"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>, "Aktas, Erdem"
	<erdemaktas@...gle.com>, "Chatre, Reinette" <reinette.chatre@...el.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>
Subject: Re: [PATCH v19 110/130] KVM: TDX: Handle TDX PV MMIO hypercall

On Wed, 2024-06-26 at 15:29 +0800, Binbin Wu wrote:
> 
> 
> On 6/26/2024 10:09 AM, Binbin Wu wrote:
> > 
> > 
> > On 6/26/2024 5:09 AM, Edgecombe, Rick P wrote:
> > > On Tue, 2024-06-25 at 14:54 +0800, Binbin Wu wrote:
> > > > > +               gpa = vcpu->mmio_fragments[0].gpa;
> > > > > +               size = vcpu->mmio_fragments[0].len;
> > > > Since MMIO cross page boundary is not allowed according to the input
> > > > checks from TDVMCALL, these mmio_fragments[] is not needed.
> > > > Just use vcpu->run->mmio.phys_addr and vcpu->run->mmio.len?
> > > Can we add a comment or something to that check, on why KVM doesn't 
> > > handle it?
> > > Is it documented somewhere in the TDX ABI that it is not expected to be
> > > supported?
> > TDX GHCI doesn't have such restriction.
> > 
> > According to the reply from Isaku in the below link, I think current 
> > restriction is due to software implementation for simplicity.
> > https://lore.kernel.org/kvm/20240419173423.GD3596705@ls.amr.corp.intel.com/ 
> > 
> > +       /* Disallow MMIO crossing page boundary for simplicity. */
> > +       if (((gpa + size - 1) ^ gpa) & PAGE_MASK)
> >                 goto error;
> > 
> > According to 
> > https://lore.kernel.org/all/165550567214.4207.3700499203810719676.tip-bot2@tip-bot2/
> > ,
> > for Linux as TDX guest, it rejects EPT violation #VEs that split pages 
> > based on the reason "MMIO accesses are supposed to be naturally 
> > aligned and therefore never cross page boundaries" to handle the 
> > load_unaligned_zeropad() case.
> > 
> > I am not sure "MMIO accesses are supposed to be naturally aligned" is 
> > true for all other OS as TDX guest, though.
> > 
> > Any suggestion?

It doesn't seem likely a guest will rely on such MMIO to cause an error, so
should be safe to wait until its needed. Let's leave a comment that it is not
expected to be needed by guests, so just return an error for simplicity.

> > 
> > 
> Had some discussion with Gao, Chao.
> 
> For TDX PV MMIO hypercall, it has got the GPA already.
> I.e, we don't need to worry about case of "contiguous in virtual memory, 
> but not be contiguous in physical memory".

Right, the guest should have to split it into two calls I guess. If the MMIO is
physically contiguous anyway though, a guest could try still to make a request
that spans two page. (assuming there is not some other HW restriction for that
kind of access)

> 
> Also, the size of the PV MMIO access is limited to 1, 2, 4, 8 bytes. No 
> need to be split.
> 
> So, for TDX, there is no need to use vcpu->mmio_fragments[] even if the 
> MMIO access crosses page boundary.
> The check for "Disallow MMIO crossing page boundary" can be removed and 
> no extra fragments handling needed.
> 
> 
Ok, thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ