none
Kommunikation zwischen User- und Kernelmdoe RRS feed

  • Frage

  • Hi!

    Ich habe noch zwei Fragen zur Treiberprogrammierung:

    1. Kann man irgendwo eine umfassende Dokumentation finden, die die Kommunikation zwischen einem kernel-mode Treiber und einem user-mode Programm beschreibt?
    2. Ich nutzte in meinem Treiber die Funktion ZwQueryInformationProcess, davon abgesehen, dass diese mittlerweile veraltet ist, habe ich gelesen, dass Prozesse den Pfad der ausführbaren Datei, den man mit dieser Funktion abfragen kann, verändern können. Ich möchte den Pfad zur Identifizierung nutzten und bin somit daran interessiert, ob diese Informationen eindeutig oder beliebig sind.

     

    Ich hoffe Sie können mir weiterhelfen! Vielen Dank schon mal im Voraus!

    developer1800

    Freitag, 6. Januar 2012 21:59

Antworten

  • Wenn ich diesen thread richtig verstehe,
    original requester of the IO
    http://www.microsoft-questions.com/microsoft/Development-Device-Drivers/32416316/original-requester-of-the-io.aspx
    kannst du dir bei einem Treiber, wie diesem diskperf (falls es um einen Treiber mit ahnlicher Funktion und Position im Stack handelt?) nicht sicher sein, die ursprüngliche Quelle, also das user-mode-Programm festzustellen, was auch immer dann der Fall ist, wenn irgendwo noch ein Filter ueber dem Eigenen sitzt. 
    Falls wie dort erwähnt, z. B. der cache-manager eine I/O Operation aufgrund einer Anfrage eines user-mode Programms in einem eigenen worker-thread veranlasst, bekommst du nicht den user-mode Prozess sondern den Kernel mit deiner Abfrage zu sehen.
    (Zumindest in XP scheint IoGetRequestorProcess Tail.Overlay.Thread zu verwenden, so dass die Ergebnisse eigentlich gleich sein müssten.)
    Don Burn:
    "It depends on what you mean by original requestor in this context.  If you
    mean this I/O was the result of a user issuing a read to a file system
    (including cached I/O) the answer is basically you cannot with any
    assurance."
    "... but since the cache manager can initiate the operation based on a
    request from user mode, in that case you will get the kernel."

    Aber wie gesagt, meine eigene Erfahrung ist da begrenzt.
    Mit freundlichen Gruessen

    • Als Antwort markiert developer1800 Montag, 16. Januar 2012 16:12
    Montag, 16. Januar 2012 07:37

Alle Antworten

  • Hi!

    Meine erste Frage hat sich nach einer ausgedehnten Suche mit bing erledigt, ich habe jetzt folgendes Dokument gefunden:

    http://msdn.microsoft.com/en-us/windows/hardware/gg487414.aspx

    Bleibt nur noch die Frage, ob die Informationen, die man mit "ZwQueryInformationProcess" und "ProcessImageFileName" bekommen kann, immer dem Pfad der ausgeführten Datei dieses Prozesses entsprechen, oder beliebig sind.

    MfG

    developer1800

    Samstag, 7. Januar 2012 17:08
  • Wenn du schreibst, "Ich möchte den Pfad zur Identifizierung nutzten" meinst du damit, ob sich der Prozess der die I/O Operation angestossen hat, mit Sicherheit durch diese Funktionen identifizieren laesst?
    Dazu muss man sagen, dass der Prozess in der ein Thread (Routine) in einem Treiber ausgefuehrt wird, sicher nicht immer der urspruengliche ist (im Zweifel also kein NtCurrentProcess() als erstes Argument). Er kann ziemlich beliebig sein.
    Ich denke ein paar Anhaltspunkte, in welchem Context verschiedene Treiber-Routinen ausgeführt werden (arbitrary, nonarbitray) könntest du hier finden:
    Scheduling, Thread Context, and IRQL
    http://msdn.microsoft.com/en-us/windows/hardware/gg487402 
    Was deinen speziellen Fall angeht (ist das immer noch DiskPerf?), habe ich leider keine Erfahrung, aber vielleicht koennte
    original-requester-io
    http://www.winvistatips.com/original-requester-io-t194771.html
    oder
    http://www.tech-archive.net/Archive/Development/microsoft.public.development.device.drivers/2008-02/msg00131.html interessant sein. 

    Ansonsten:
    What's in a (Process) Name? Obtaining A Useful Name for the Executable Image in a Process
    http://www.osronline.com/article.cfm?article=472
    Process or Image Name
    http://www.osronline.com/showthread.cfm?link=204229

    (Kein Treiber Guru)
    Mit freundlichen Gruessen

    P.S. Fuer speziell Treiber-spezifische Fragen kann ich dir dieses Forum empfehlen
    Windows Hardware WDK and Driver Development
    http://social.msdn.microsoft.com/Forums/en-US/wdk/threads



    Samstag, 7. Januar 2012 20:45
  • So, bin leider erst heute wieder dazu gekommen, hier vorbeizuschauen!

    Vielen Dank für deine Antwort, die links haben mir weitergeholfen.

    Aber nocheinmal zu meinem Problem: Ich fange in meinem Treiber ein IRP in einer Dispatch routine ab und stelle dann den sendenden Prozess auf folgende Weise fest:

    PETHREAD thread;
    PEPROCESS process;
    
    thread = Irp->Tail.Overlay.Thread;
    process = IoThreadToProcess(thread);


    anschließend nutze ich ZwQueryInformationProcess, um den Pfad der ausführbaren Datei dieses Prozesses festzustellen.

    Ich möchte den Treiber nutzten, um nur Anfragen (IRPs) von bestimmten ausführbaren Dateien zuzulassen und bin von daher interessiert daran, ob ich mich auf diese Angaben verlassen kann.

    MfG

    developer1800

    Samstag, 14. Januar 2012 15:54
  • Wenn ich diesen thread richtig verstehe,
    original requester of the IO
    http://www.microsoft-questions.com/microsoft/Development-Device-Drivers/32416316/original-requester-of-the-io.aspx
    kannst du dir bei einem Treiber, wie diesem diskperf (falls es um einen Treiber mit ahnlicher Funktion und Position im Stack handelt?) nicht sicher sein, die ursprüngliche Quelle, also das user-mode-Programm festzustellen, was auch immer dann der Fall ist, wenn irgendwo noch ein Filter ueber dem Eigenen sitzt. 
    Falls wie dort erwähnt, z. B. der cache-manager eine I/O Operation aufgrund einer Anfrage eines user-mode Programms in einem eigenen worker-thread veranlasst, bekommst du nicht den user-mode Prozess sondern den Kernel mit deiner Abfrage zu sehen.
    (Zumindest in XP scheint IoGetRequestorProcess Tail.Overlay.Thread zu verwenden, so dass die Ergebnisse eigentlich gleich sein müssten.)
    Don Burn:
    "It depends on what you mean by original requestor in this context.  If you
    mean this I/O was the result of a user issuing a read to a file system
    (including cached I/O) the answer is basically you cannot with any
    assurance."
    "... but since the cache manager can initiate the operation based on a
    request from user mode, in that case you will get the kernel."

    Aber wie gesagt, meine eigene Erfahrung ist da begrenzt.
    Mit freundlichen Gruessen

    • Als Antwort markiert developer1800 Montag, 16. Januar 2012 16:12
    Montag, 16. Januar 2012 07:37
  • Vielen Dank für deine Antwort, jetzt habe ich eine Richtung, in die ich weiter arbeiten kann.

    developer1800

    Montag, 16. Januar 2012 16:12