linux-kernel - Re: [PATCH] Linux Kernel Markers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 Sep 2006 14:45:25 +0100
From:	Richard J Moore <richardj_moore@...ibm.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Andrew Morton <akpm@...l.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Christoph Hellwig <hch@...radead.org>,
	Jes Sorensen <jes@....com>, Paul Mundt <lethal@...ux-sh.org>,
	linux-kernel <linux-kernel@...r.kernel.org>, ltt-dev@...fik.org,
	Martin Bligh <mbligh@...gle.com>,
	Michel Dagenais <michel.dagenais@...ymtl.ca>,
	Ingo Molnar <mingo@...e.hu>, prasanna@...ibm.com,
	systemtap@...rces.redhat.com, Thomas Gleixner <tglx@...utronix.de>,
	William Cohen <wcohen@...hat.com>,
	Tom Zanussi <zanussi@...ibm.com>
Subject: Re: [PATCH] Linux Kernel Markers

Alan Cox <alan@...rguk.ukuu.org.uk> wrote on 20/09/2006 11:32:07:

> Ar Mer, 2006-09-20 am 09:18 +0100, ysgrifennodd Richard J Moore:
> > > Are you referring to Intel erratum "unsynchronized cross-modifying
code"
> > > - where it refers to the practice of modifying code on one processor
> > > where another has prefetched the unmodified version of the code.
>
> > In the special case of replacing an opcode with int3 that erratum
doesn't
> > apply. I know that's not in the manuals but it has been confirmed by
the
> > Intel microarchitecture group. And it's not reasonable to it to be any
> > other way.
>
> Ok thats cool to know and I wish they'd documented it. Is the same true
> for AMD ?
>
> Alan
>

Not sure probably - I can ask.

Intel explained it to me thus:

When the i-fetch has been done and the micro-ops are in the trace cache
then there's no longer a direct correlation between the original machine
instruction boundaries and the micro ops. This is due to optimization. For
example (artificial one for illustrative purposes):

mov eax,ebx
mov memory,eax
mov eax,1

(using intel notation not ATT - force of habit)

In the trace cache there would be no micro ops to update eax with ebx.

Altering the "mov eax,ebx" to "mov ecx,ebx" on the fly invalidates the
optimized trace cache, hence the onlhy recourse is a GPF.
If the modification doens't invalidate the trace cache then no GPF. The
question is: "can we predict th circumstances when the trace cache has not
been invalidated", and the answer in general is no since the
microarchtecture is not public. But one can guess that modifying the single
byte opcode with in interrupting instruction  - int3 - doesn't cause an
inconsistency that can't be handled. And that's what Intel confirmed. Go
ahead and store int3 without the need to synchronise (i.e. force the trace
cache to be flushed).

My guess is that AMD behaves exactly the same way. But I'll check.

Richard

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