SecureZeroMemory vermisst

[himitsu]

Bin ich nur blind, oder warum kann ich diese Prozedur nicht finden?

Delphi-Quellcode:

Procedure SecureZeroMemory(Destination: Pointer; Length: LongInt); StdCall;
  External '???' Name 'RtlSecureZeroMemory';

da soll sie ja angeblich sein (vermutlich ntdll.dll, oder eventuell auch kernel32.dll / user32.dll),
aber nichts ... nirgends ... im gesamten WinXP nicht

http://msdn.microsoft.com/library/de...zeromemory.asp

[Olli]

http://www.osronline.com/DDKx/kmarch/k109_4nci.htm
http://jedi-apilib.sourceforge.net/native

[himitsu]

Die OSR-Seite kannte ich schon ... dat is ja eine der weingen Seiten, die Goole liefert, allerdings wäre diese wohl besser http://www.osronline.com/DDKx/kmarch/k109_3bqq.htm , denn ich suche nicht das "normale" ZeroMemory, sondern eben das "Sichere" und genau dieses ist nicht zufinden.
Selbst in den JEDI's ist es nicht drin, bis auf so'nen TODO Eintrag.

[Frickeldrecktuxer_TM]

Zitat von himitsu:

Die OSR-Seite kannte ich schon ... dat is ja eine der weingen Seiten, die Goole liefert, allerdings wäre diese wohl besser http://www.osronline.com/DDKx/kmarch/k109_3bqq.htm

Wenn du sie kanntest, warum hast du sie dann nicht gelesen?

Zitat:

This routine is available on Windows Server 2003 and later. (Because the routine is declared inline, the body of the routine can be included in earlier versions of the operating system.)

Steht so auch im MSDN.

http://www.gcdev.com/ntddk.h:

Zitat:

Code:

FORCEINLINE
PVOID
RtlSecureZeroMemory(
    IN PVOID ptr, 
    IN SIZE_T cnt
    ) 
{
    volatile char *vptr = (volatile char *)ptr;
    while (cnt) {
        *vptr = 0;
        vptr++;
        cnt--;
    }
    return ptr;
}

Frag mich nicht, ob das der Original-Header von Microsoft ist (laut Copyright ist er es) oder warum eine Gamecube-Seite Header aus dem DDK veröffentlicht, aber so schwierig ist es auch nicht, die Funktion selber in Delphi zu implementieren, schließlich macht sie auch nicht mehr als ZeroMemory()

[himitsu]

Gut, dann wa ich wohl irgendwie blid

aber wie bekomm ich jetzt das

FORCEINLINE und volatile nach Delphi?

Code:

FORCEINLINE
PVOID
RtlSecureZeroMemory(
    IN PVOID ptr, 
    IN SIZE_T cnt
    ) 
{
    [b]volatile[/b] char *vptr = ([b]volatile[/b] char *)ptr;
    while (cnt) {
        *vptr = 0;
        vptr++;
        cnt--;
    }
    return ptr;
}

Der Rest ist leicht ... beziehungsweise ich hab da auch 'ne ASM-Version

[edit]
OK, FORCEINLINE ist wohl sows wie INLINE in Delphi, also erstmal egal.

[Frickeldrecktuxer_TM]

Zitat von himitsu:

FORCEINLINE

Gar nicht. Inlining ist beim DCC meines Wissens nach nach wie vor nur eine Empfehlung.

Zitat von himitsu:

volatile

Optimierung des Compilers lokal ausschalten. WIMRE {$O-} und {$o+}. Ansonsten den Compiler sonstwie dazu überreden, die Variable nicht wegzuoptimieren. Da Optimierung immer implementationsabhängig ist, musst du schauen, wie du deinen Compiler dazu überreden kannst, die Variable nicht wegzuoptimieren. Die nächste Version des gleichen Compilers kann sich da schon wieder vollkommen anders verhalten, wenn sie will.
Zweite Alternative: Soweit ich weiß kann der Delphi-Linker auch C-Objects einbinden. Wie das genau geht, weiß ich nicht, aber du könntest die Funktion in C schreiben, in eine lib kompilieren und sie irgendwie dem DCC unterjubeln.

[himitsu]

Asoooooo
hatte das im MSDN so verstanden, daß Windows dazu veranlasst wird es nicht zu optimieren, also z.B. den Speicher nich in irgend 'ner Cache zu lassen, sondern den Speicherbereich wirklich zu überschreiben ... na dann isses ja "sinnlos" dieses nach Delphi zu holen, weil wenn man ZeroMemory als DelphiFunktion aufruft, dann wird diese Funktion ja vom Compiler nicht wegoptimiert -.-''

Da such ich jetzt seit letzter Woche danach und dann sowas ... blödes C++

In Delphi gibt's ja kein INLINE mehr, also wird die Funktion nicht integriert und deren Inhalt kann demnach nicht wegoptimiert werden.

[Olli]

Zitat von himitsu:

Selbst in den JEDI's ist es nicht drin, bis auf so'nen TODO Eintrag.

Tja, könnte es vielleicht eine Bedeutung gehabt haben, daß ich dir genau diese Seite verlinkt habe? Ja! Ich wollte dir nämlich zeigen, daß es sich um ein Makro oder eine Inline-Funktion handeln muß. Um die riesige HTML-Seite nicht direkt zu verlinken, habe ich dir nur den Einstieg zu ihr geliefert. Wenn du in der dortigen Liste RtlSecureZeroMemory suchst, wirst du es nämlich garnicht finden, was wie bei einigen anderen "Funktionen" darauf hinweist, daß sie nicht in den entsprechenden DLLs sondern direkt (z.B. über Makros) implementiert sind.

[Frickeldrecktuxer_TM]

Zitat von himitsu:

hatte das im MSDN so verstanden, daß Windows dazu veranlasst wird es nicht zu optimieren, also z.B. den Speicher nich in irgend 'ner Cache zu lassen, sondern den Speicherbereich wirklich zu überschreiben ...

Nö, wie denn? Windows kann in deinem Code nicht optimieren. Und wenn dein Code eine I/O-Operation ausführt, wird garantiert, daß diese auch stattfindet, es sei denn die entsprechende Operation gibt einen entsprechenden Fehler zurück. Aber grundsätzlich gilt: Wenn eine Operation fehlerfrei abläuft, ist sie auch fehlerfrei abgelaufen.
ZeroMemory() und SecureZeroMemory() sind aber inline-Funktionen, das heißt ein C-Compiler würde den Code direkt aus dem Header einfügen und danach den Optimizer drüberlaufen lassen. Unter umständen sieht er dann, daß Variablen Werte zu gewiesen werden, die später nicht mehr benutzt werden und könnte dadurch ein ZeroMemory() komplett wegoptimieren. Durch die volatile-Anweisung in SecureZeroMemory() wird einem C-Compiler nun gesagt, daß die verwendete Variable "flüchtig" ist, also sich willkürlich auch mal ändern kann, auch wenn der Compiler das vom restlichen Code nicht unbedingt als richtig empfindet. Für den Optimizer bedeutet das dann, daß er die Variable nicht anfassen darf, weil ihr Verhalten vom Programmierer als unvorhersehbar gekennzeichnet ist, also kann auch der Optimizer nicht vorhersehen, wie sich die Variable verhalten wird. Das ist der ganze Trick hinter SecureZeroMemory(). Caches haben damit nichts zu tun. Wenn der Speicherbereich im Cache des Prozessors ist, muss er im RAM und im Cache geändert werden (Write-Through) oder wird nur im Cache geändert und bei Gelegenheit auch im RAM (Write-Back). Die Architektur stellt dabei bereits sicher, daß nicht zwei verschiedene Informationen benutzt werden (z.B. der DMA-Controller, der aus dem RAM liest, während die Seite zuvor im Prozessor-Cache geschrieben wurde). Interessant sit das auch bei Mehrprozessorsystemen.

Zitat von himitsu:

In Delphi gibt's ja kein INLINE mehr, also wird die Funktion nicht integriert und deren Inhalt kann demnach nicht wegoptimiert werden.

Ich dachte Delphi2006 hat das inline-Schlüsselwort wieder eingeführt?

[Dax]

Zitat von Frickeldrecktuxer_TM:

Ich dachte Delphi2006 hat das inline-Schlüsselwort wieder eingeführt?

Das hat Delphi 2005 schon getan