linux-kernel - Re: [kvm-devel] [PATCH] KVM: Avoid using vmx instruction directly

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: <200611091737.48801.arnd@arndb.de>
Date:	Thu, 9 Nov 2006 17:37:48 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Avi Kivity <avi@...ranet.com>
Cc:	kvm-devel@...ts.sourceforge.net, akpm@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [kvm-devel] [PATCH] KVM: Avoid using vmx instruction directly

On Thursday 09 November 2006 15:52, Avi Kivity wrote:
> Wouldn't that make inline assembly useless?  Suppose the contents is 
> itself a pointer.  What about the pointed-to contents?
> 
> e.g.
> 
>     int x = 3;
>     int *y = &x;
>     int z;
> 
>     asm ("mov %1, %%rax; movl (%%rax), %0" : "=r"(z) : "g"(y) : "rax");
>     assert(z == 3);

Same here, you need to tell gcc what is really accessed, like 

asm ("mov %1, %%rax; movl (%%rax), %0" : "=r"(z) : "g"(y), "m"(*y) : "rax");

I know that the s390 kernel developers have hit that problem
frequently with inline assemblies. It may be that it's harder
to hit on x86, because there are fewer registers available and
data therefore tends to spill to the stack.

> > Or gcc
> > might move the assignment of phys_addr to after the inline assembly.
> >   
> "asm volatile" prevents that (and I'm not 100% sure it's necessary).

Yes, I think that's right. The 'volatile' should not be necessary though,
if you get the inputs right.

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