Sviluppo del driver C #?

Prima di saltare a capofitto in C # …

Ho sempre pensato che C, o forse C ++, fosse la soluzione migliore per lo sviluppo di driver su Windows. Non mi piace l’idea di sviluppare un driver su una macchina .NET.

Ma .NET sembra essere il modo in cui MS si sta dirigendo verso lo sviluppo di applicazioni, e quindi ora mi chiedo:

  • Le persone stanno usando C # per sviluppare i driver?
  • Devi fare un sacco di hook API, o C # ha le funzionalità per interfacciarsi con il kernel senza un sacco di hackery?
  • Qualcuno può parlare dell’affidabilità e della sicurezza di eseguire un programma C # più vicino a Ring 0 di quanto non sia normalmente?

Voglio che i miei dispositivi siano utilizzabili in C # e, se il driver dev in C # è maturo, è ovviamente la strada da percorrere, ma non voglio spendere molto se non è raccomandato.

  • Quali sono alcune buone risorse per iniziare, ad esempio, lo sviluppo di un semplice driver di porta seriale virtuale?

-Adamo

Non è ansible creare driver di periferica in modalità kernel in C # poiché il runtime non può essere caricato in modo sicuro in ring0 e funzionare come previsto.

Inoltre, C # non crea binari adatti per il caricamento come driver di dispositivo, in particolare per quanto riguarda i punti di ingresso che i driver devono esporre. La dipendenza dal runtime per saltare e analizzare e JIT il binario durante il caricamento vieta l’accesso diretto al sottosistema del driver per caricare il file binario.

È in corso il lavoro, tuttavia, per portare alcuni driver di dispositivo in modalità utente, è ansible vedere un’intervista qui con Peter Wieland del team UDMF (User Mode Driver Framework).

I driver in modalità utente sarebbero molto più adatti per il lavoro gestito, ma dovrai un po ‘google per scoprire se C # e .NET saranno supportati direttamente. Tutto quello che so è che i driver a livello di kernel non sono fattibili solo in C #.

Tuttavia, è ansible probabilmente creare un driver C / C ++ e un servizio C # (o simili) e far dialogare il driver con il codice gestito, se si deve scrivere molto codice in C #.

Questo ti aiuterà in un modo: Windows Driver Kit

Non è la risposta diretta alla tua domanda, ma se sei interessato potresti guardare al progetto Singularity .

Qualcuno può parlare dell’affidabilità e della sicurezza di eseguire un programma C # più vicino a Ring 0 di quanto non sia normalmente?

C # viene eseguito in .NET Virtual Machine, non è ansible spostarlo più vicino a Ring 0 rispetto alla VM e la VM viene eseguita nello spazio utente.

Microsoft ha una serie di progetti di ricerca nell’area di avere un sistema operativo con codice gestito, in altre parole uccidere con l’API Win32.

Vedi l’articolo di Mary Jo Foley: Rebuilding a Legacy

Scrivere i driver di dispositivo in .net non ha senso per le versioni correnti di Windows.


Si dice che la SM stia investendo molti soldi per portare Singularity al livello successivo. Cerca Midori . Ma questo è il 2015+

Se sei disposto a provare un framework proprietario, il toolkit WinDriver di Jungo supporta lo sviluppo del driver in modalità utente (anche nel codice gestito) per dispositivi USB, PCI e PCI-E.

Se lo ricordo correttamente, il Progetto Dokan è un driver del file system in modalità utente, che consente anche l’esecuzione del codice .NET da parte di un driver di sistema: https://github.com/dokan-dev/dokan-dotnet .

Quindi, potresti sviluppare un C # “driver” (un’applicazione in modalità utente), che viene quindi chiamata / invocata da un driver in modalità kernel C ++. Il driver del kernel potrebbe semplicemente passare tutto senza manipolare i dati e agire come un semplice wrapper.
Inutile dire che è molto pericoloso e molto probabilmente finirai con un BSOD (l’ho provato).


Lievemente correlato:

Il Cosmos Project è un sistema operativo open-source, sviluppato in C # e funzionante
“(kernel) drivers” e applicazioni a livello utente scritte completamente in C # / F # / VB.NET / …

Sebbene questi siano tecnicamente driver a livello di kernel, il sistema operativo non è più Windows ma è il tuo, quindi suppongo che questa non sia una risposta corretta ……