linux-kernel - Re: [PATCH 4/4] kvm: Implement PEBS virtualization

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: <20140624164514.GA25220@amt.cnet>
Date:	Tue, 24 Jun 2014 13:45:14 -0300
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Avi Kivity <avi.kivity@...il.com>, peterz@...radead.org,
	gleb@...nel.org, pbonzini@...hat.com, eranian@...gle.com,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 4/4] kvm: Implement PEBS virtualization

On Sun, Jun 22, 2014 at 09:02:25PM +0200, Andi Kleen wrote:
> > First, it's not sufficient to pin the debug store area, you also
> > have to pin the guest page tables that are used to map the debug
> > store.  But even if you do that, as soon as the guest fork()s, it
> > will create a new pgd which the host will be free to swap out.  The
> > processor can then attempt a PEBS store to an unmapped address which
> > will fail, even though the guest is configured correctly.
> 
> That's a good point. You're right of course.
> 
> The only way I can think around it would be to intercept CR3 writes
> while PEBS is active and always pin all the table pages leading 
> to the PEBS buffer. That's slow, but should be only needed
> while PEBS is running.
> 
> -Andi

Suppose that can be done separately from the pinned spte patchset.
And it requires accounting into mlock limits as well, as noted.

One set of pagetables per pinned virtual address leading down to the
last translations is sufficient per-vcpu.


--
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/