linux-kernel - Re: One (possible) x86 get_user

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]

Message-ID: <4D473343.7080708@goop.org>
Date:	Mon, 31 Jan 2011 14:10:11 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Kaushik Barde <kbarde@...wei.com>
CC:	'Avi Kivity' <avi@...hat.com>, 'Jan Beulich' <JBeulich@...ell.com>,
	'Xiaowei Yang' <xiaowei.yang@...wei.com>,
	'Nick Piggin' <npiggin@...nel.dk>,
	'Peter Zijlstra' <a.p.zijlstra@...llo.nl>,
	fanhenglong@...wei.com, 'Kenneth Lee' <liguozhu@...wei.com>,
	'linqaingmin' <linqiangmin@...wei.com>, wangzhenguo@...wei.com,
	'Wu Fengguang' <fengguang.wu@...el.com>,
	xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
	'Marcelo Tosatti' <mtosatti@...hat.com>
Subject: Re: One (possible) x86 get_user_pages bug

On 01/31/2011 12:10 PM, Kaushik Barde wrote:
> << I'm not sure I follow you here.  The issue with TLB flush IPIs is that
> the hypervisor doesn't know the purpose of the IPI and ends up
> (potentially) waking up a sleeping VCPU just to flush its tlb - but
> since it was sleeping there were no stale TLB entries to flush.>>
>
> That's what I was trying understand, what is "Sleep" here? Is it ACPI sleep
> or some internal scheduling state? If vCPUs  are asynchronous to pCPU in
> terms of ACPI sleep state, then they need to synced-up. That's where entire
> ACPI modeling needs to be considered. That's where KVM may not see this
> issue. Maybe I am missing something here.

No, nothing to do with ACPI.  Multiple virtual CPUs (VCPUs) can be
multiplexed onto a single physical CPU (PCPU), in much the same way as
tasks are scheduled onto CPUs (identically, in KVM's case).  If a VCPU
is not currently running - either because it is simply descheduled, or
because it is blocked (what I slightly misleadingly called "sleeping"
above) in a hypercall, then it is not currently using any physical CPU
resources, including the TLBs.  In that case, there's no need to flush
that's VCPU's TLB entries, because there are none.

> << A "few hundred uSecs" is really very slow - that's nearly a
> millisecond.  It's worth spending some effort to avoid those kinds of
> delays.>>
>
> Actually, just checked IPIs are usually 1000-1500 cycles long (comparable to
> VMEXIT). My point is ideal solution should be where virtual platform
> behavior is closer to bare metal interrupts, memory, cpu state etc.. How to
> do it ? well that's what needs to be figured out :-)

The interesting number is not the raw cost of an IPI, but the overall
cost of the remote TLB flush.

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