[C] Riavvio computer con KeDelayExecutionThread

[ingtabby]

PF_FORWARD_ACTION FilterFunction(IN unsigned char *PacketHeader,
IN unsigned char *Packet,
IN unsigned int PacketLength,
IN unsigned int RecvInterfaceIndex,
IN unsigned int SendInterfaceIndex,
IN IPAddr RecvLinkNextHop,
IN IPAddr SendLinkNextHop)
{


char index;
NTSTATUS state;
IPHeader* iph;
ULONG indirizzo;
UDPHeader* udph;
FilterList *t;
LARGE_INTEGER li;
li.QuadPart = 1000000;
t = First;
iph = (IPHeader*)PacketHeader;
state=KeDelayExecutionThread(KernelMode, FALSE, &li);

[oregon]

La chiamata alla funzione non sembra essere sbagliata ma in certi casi (all'interno di una DPC, ad esempio) non è consentito chiamarla.

Per capire meglio bisognerebbe esaminare da zero tutto il progetto ...

[unomichisiada]

Originariamente inviato da oregon
Non sono d'accordo.

Non si impara "solo" sbagliando ma studiando.

Questo non implica l'impossibilità di sbagliare (da cui "anche" si impara) ma limita al minimo (alle situazioni veramente complesse) il manifestarsi di errori.

Hai interpretato male il mio "solo" o mi sono espresso male io, del resto ne abbiamo parlato in un'altra discussione in cui abbiamo partecipato entrambi ed io sostengo esattamente come te che la pratica DEVE essere affiancata e per certi versi preceduta dalla teoria.Quello che intendo dire è che non bisogna aver paura di cimentarsi anche in progetti difficili a patto ovviamente che ci si documenti opportunamente.Inoltre devi tener conto che ingtabby mi ha speigato la situazione ed ha per così dire rischiato per cause di forza maggiore,non sempre si ha il tempo di documentarsi adeguatamnte in situazioni del genere,io quindi appoggio pienamente la sua scelta di tentare comunque anche se è rischioso.Io stesso mi sono trovato in questa situazione (cioè non avevo conoscenze di programamzione a così basso livello e tutt'ora non posso certo dirmi esperto) mi sono buttato (perchè non avveo altra scelta) ed ho comunque portato termine il progetto.

[unomichisiada]

Originariamente inviato da oregon
La chiamata alla funzione non sembra essere sbagliata ma in certi casi (all'interno di una DPC, ad esempio) non è consentito chiamarla.

Per capire meglio bisognerebbe esaminare da zero tutto il progetto ...

Infatti! Quello che mi preoccupa è proprio questo.Lo scopo del suo progetto (me lo ha spiegato bene in separata sede) è sostanzailmente quello di ritardare, sulla base di alcuni parametri, determinati pacchetti IP e credo che per farlo stia cercando di usare quella che è in pratica l'equivalente della sleep in kernelmode, per ritardare il ritorno del valore PF_DROP o PF_PASS nella filterfunction di un driver che implementa un Hoook Filter. Ora c'è la seria possibilità che questa operazione non sia permessa il che vanificherebbe il suo intero approccio al progetto. In realtà io l'ho anche avvertito della possibilità di questa evenienza prima di cominciare ma lui ha voluto rischiare proprio perchè costretto. Spero solo di aver torto...

[ingtabby]

speriamo proprio di no! mi informo meglio su come usare la funzione ke..delay( ) se avete qualche sito dove posso trovare qualcosa siete i benvenuti! altrimenti provero a cercare altri metodi per ritardare in kernel..sperando che ci siano.. cmq vi ringrazio ancora...unomichisiada ha centrato la mia situazione...

[ingtabby]

ho cercato su msdn altre funzioni che facciano la stessa cosa...a me ne serve una che in qualche modo faccia passare tot millisecondi che do come input...
ho visto la KeStallExecutionProcess ma vuole intervalli inferiori ai 50 microsecondi...
poi ci sono i Counters, KeQuerySystemTime mi da in unita 100 microsecondi il system time, quindi un idea (un po' grezza) sarebbe quella di un ciclo while che esce solo quando passa un tot di millisecondi che dico io..sarebbe anche fattibile, solo che l'aggiornamento dell ora avviene solo circa ogni 10 millisecondi, quindo potrei ritardare solo per multipli di 10 millisecondi (se proprio nn c'è altro potrei anche accettare tale limitazione).
adesso cerco di capire come funzionano i timer con la KeSetTimer che mi sembra la piu fattibile (sempre che non dia lo stesso problema)
avete consigli?

[ingtabby]

ho provato a usare:

PKTIMER* timer = (PKTIMER*) ExAllocatePool(NonPagedPool, sizeof(PKTIMER));
LARGE_INTEGER li;
li.QuadPart = 1000000;
KeInitializeTimer(*timer);
KeSetTimer(*timer, li,NULL);
KeWaitForSingleObject(&timer,Executive,KernelMode, FALSE,
NULL);

e questa mi da il solito errore IRQL NOT LESS OR EQUAL
però con codice 0000000A

La cosa curiosa però è che un altra funzione del filtro (la setfilterfunction)
chiama anche lei la KeWaitForSingleObject(&event,Executive,KernelMode, FALSE,
NULL) senza fare errori! (ho controllato con una flag)
quindi in teoria potrei usarla anche io..o non è cosi scontato? forse i miei intervalli di tempo sono troppo elevati?

[unomichisiada]

Mi dispiace ma io non sono in grado di aiutarti ulteriormente su questo problema in quanto come ho già detto le mie conoscenze di programmazione kernel mode sono abbstanza limitate.Oregon sembra decisamente più ferrato da questo punto di vista,spero che lui ti possa aiutare.

[oregon]

Originariamente inviato da ingtabby
ho provato a usare:

PKTIMER* timer = (PKTIMER*) ExAllocatePool(NonPagedPool, sizeof(PKTIMER));
LARGE_INTEGER li;
li.QuadPart = 1000000;
KeInitializeTimer(*timer);
KeSetTimer(*timer, li,NULL);
KeWaitForSingleObject(&timer,Executive,KernelMode, FALSE,
NULL);

e questa mi da il solito errore IRQL NOT LESS OR EQUAL
però con codice 0000000A

La cosa curiosa però è che un altra funzione del filtro (la setfilterfunction)
chiama anche lei la KeWaitForSingleObject(&event,Executive,KernelMode, FALSE,
NULL) senza fare errori! (ho controllato con una flag)
quindi in teoria potrei usarla anche io..o non è cosi scontato? forse i miei intervalli di tempo sono troppo elevati?

Il problema dello sviluppo di un driver e' che non si puo' andare per "spezzoni" di codice, ma bisogna avere - sempre - un quadro unitario di quello che si sta scrivendo.

Ad esempio, sarebbe fondamentale sapere che tipo di driver si sta scrivendo e in quale funzione e' implementato il codice che stiamo leggendo.

Questo a prescindere dal fatto che il codice e' completamente sbagliato, dato che

1) l'oggetto inizializzato e' un puntatore a un puntatore ad un oggetto KTIMER; deve essere invece un puntatore semplice all'oggetto e quindi

PKTIMER timer = (PKTIMER)ExAllocatePool(NonPagedPool, sizeof(KTIMER));

2) le funzioni KeInitializeTimer, KeSetTimer, KeWaitForSingleObject accettano un puntatore all'oggetto KTIMER, ovvero un PKTIMER, cio' che e' dichiarato al punto 1), quindi

KeInitializeTimer(timer);
KeSetTimer(timer, li, NULL);
KeWaitForSingleObject(timer, Executive, KernelMode, FALSE, NULL);

3) il parametro li, se positivo, è inteso come assoluto. Se invece deve essere inteso come periodo di tempo *relativo* allora deve essere negativo. Quindi

li.QuadPart = -1000000;

Ovviamente tutto cio' puo' non risolvere i problemi, semplicemente perche' - lo ripeto - per progetti del genere, i problemi possono essere tantissimi e in tante parte del codice (addirittura del progetto, perche' potrebbe non essere possibile tutto cio' che si desidera fare ...)

[ingtabby]

capisco...ho fatto le modifiche ma da sempre lo stesso errore B8...penso tu abbia capito quello che voglio realizzare..hai qualche consiglio su strade alternative?voglio solo ritardare i pacchetti in entrata e in uscita di un server (verso una specifica porta e con ritardo dipendente dall ip)
Quello che sto implementando è un filter hook driver, partendo da uno scheletro di un filtro funzionante, pensavo non ci fossero problemi ad aggiungere in kernel un funzione che ritardasse e basta...
il codice che hai visto è all'interno della funzione filterfunction( ), praticamente il cuore del filtro: viene chiamata al passaggio di ogni pacchetto e decide se il pacchetto viene passato oppure bloccato.