linux-kernel - Re: [PATCH v2 2/4] KVM: introduce "xinterface" API for external interaction with guests

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:	Wed, 07 Oct 2009 08:48:25 -0400
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Gregory Haskins <ghaskins@...ell.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH v2 2/4] KVM: introduce "xinterface" API for external	interaction
 with guests

Avi Kivity wrote:
> On 10/06/2009 09:40 PM, Gregory Haskins wrote:
>> Thinking about this some more over lunch, I think we (Avi and I) might
>> both be wrong (and David is right).  Avi is right that we don't need
>> rmb() or barrier() for the reasons already stated, but I think David is
>> right that we need an smp_mb() to ensure the cpu doesn't do the
>> reordering.  Otherwise a different cpu could invalidate the memory if it
>> reuses the freed memory in the meantime, iiuc.  IOW: its not a compiler
>> issue but a cpu issue.
>>
>> Or am I still confused?
>>
>>    
> 
> The sequence of operations is:
> 
>     v = p->v;
>     f();
>     // rmb() ?
>     g(v);
> 
> You are worried that the compiler

No

> or cpu will fetch p->v after f() has executed?

Yes.

> The compiler may not, since it can't tell whether f() might
> change p->v.

Right, you were correct to say my barrier() suggestion was wrong.

> If f() can cause another agent to write to p (by freeing
> it to a global list, for example), then it is its responsibility to
> issue the smp_rmb(), otherwise no calculation that took place before f()
> and accessed p is safe.
> 

IOW: David is right.  You need a cpu-barrier one way or the other.  We
can either allow ->release() to imply one (and probably document it that
way, like we did for slow-work), or we can be explicit.  I chose to be
explicit since it is kind of self-documenting, and there is no need to
be worried about performance since the release is slow-path.

OTOH: If you feel strongly about it, we can take it out, knowing that
most anything the properly invalidates the memory will likely include an
implicit barrier of some kind.

Kind Regards,
-Greg



Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)