linux-kernel - Re: [Lguest] [PATCH 3/16] read/write_crX, clts and wbinvd for 64-bit paravirt

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:	Thu, 01 Nov 2007 09:55:13 -0700
From:	Zachary Amsden <zach@...are.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Keir Fraser <Keir.Fraser@...cam.ac.uk>, lguest@...abs.org,
	kvm-devel@...ts.sourceforge.net, mingo@...e.hu, ak@...e.de,
	linux-kernel@...r.kernel.org, anthony@...emonkey.ws,
	tglx@...utronix.de, Glauber de Oliveira Costa <gcosta@...hat.com>,
	virtualization@...ts.linux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [Lguest] [PATCH 3/16] read/write_crX, clts and wbinvd for
	64-bit paravirt

On Thu, 2007-11-01 at 10:41 -0700, Jeremy Fitzhardinge wrote:
> Keir Fraser wrote:
> > volatile prevents the asm from being 'moved significantly', according to the
> > gcc manual. I take that to mean that reordering is not allowed.
> >   

I understood it as reordering was permitted, but no re-ordering across
another volatile load, store, or asm was permitted.  And of course, as
long as input and output constraints are written properly, the
re-ordering should not be vulnerable to pathological movement causing
the code to malfunction.

It seems that CPU state side effects which can't be expressed in C need
special care - FPU is certainly one example.

Also, memory clobber on a volatile asm should stop invalid movement
across TLB flushes and other problems areas.  Even memory fences should
have memory clobber in order to stop movement of loads and stores across
the fence by the compiler.

Zach

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