linux-kernel - Re: [PATCH 2/4] KVM: nSVM: propagate the NPF EXITINFO to the 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:	Tue, 2 Sep 2014 19:01:30 +0200
From:	Joerg Roedel <jroedel@...e.de>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org, agraf@...e.de,
	valentine.sinitsyn@...il.com, jan.kiszka@...mens.com,
	gleb@...udius-systems.com, avi@...udius-systems.com
Subject: Re: [PATCH 2/4] KVM: nSVM: propagate the NPF EXITINFO to the guest

On Tue, Sep 02, 2014 at 06:46:06PM +0200, Paolo Bonzini wrote:
> Il 02/09/2014 18:33, Joerg Roedel ha scritto:
> > Comment is true, but doesn't make the check below obsolete, no?
> 
> No, it doesn't.  I'll rewrite it as
> 
> 	/*
> 	 * This cannot happen unless the guest is playing TOCTTOU games,
> 	 * because we would have gotten a nested page fault on table_gfn
> 	 * instead.  If this happens, the exit qualification / exit info
> 	 * field will incorrectly have "guest page access" as the
> 	 * nested page fault's cause, instead of "guest page structure
> 	 * access".
> 	 */

Sounds good.

> > Its been a while since I looked into this, but is an injected NPF exit
> > always the result of a real NPF exit?
> 
> I think so, but that's why I CCed you. :)
> 
> > How about an io-port emulated on
> > L1 but passed through to L2 by the nested hypervisor. On emulation of
> > INS or OUTS, KVM would need to read/write to an L2 address space,
> 
> It would need to read/write to *L1* (that's where the VMCB's IOIO map
> lies), which could result into a regular page fault injected into L1.

Hmm, INS and OUTS read/write to a virtual memory location, right? So if
we have an io-port intercepted by bare-metal KVM but not by the L1
hypervisor, and the L2 guest accesses this io-port, bare-metal KVM would
get an IOIO exit it has to emulate itself (it can't inject an IOIO exit
to L1 anyway, since L1 does not intercept the io-port).

During emulation the bare-metal KVM would read/write at an L2 virtual
address, because that is the context the instruction is executed in.
And while resolving this L2 virtual address, an NPF fault could be
detected that needs to be injected into the L1 hypervisor, right?



	Joerg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/