Page 2 of 2

Re: Device Drivers' Interface considerations

Posted: Wed Dec 19, 2007 9:20 am
by Solar
A formality first:
XCHG wrote:The FunctionAddresses member will have its size in bytes equal to NumberofFunctionsSupported * sizeof(FunctionAddresses).
Please don't use color markup. People use different styles on this forum, and on the quite popular "mtDark2" theme, blue is exceptionally unreadable.

As for your concept:
XCHG wrote:The driver should not be allowed to ask for anything from the kernel, not at least initially.
I like the idea of a well-defined kernel - driver interface, and actually thought up a comparable scheme myself for Pro-POS. However, it is usually not practical to handle device drivers as potential malware - if you distrust even hardware drivers, your options of response should a driver turn out to be malware are severely limited, and you put a dent in your style and your performance that way.

Either a driver is part of the kernel (i.e., trusted and running in kernel space), or it's a (microkernel-style) server process, which should be very much alike to a "normal" application process, i.e. not that special in start-up.

Re: Device Drivers' Interface considerations

Posted: Fri Dec 21, 2007 10:09 am
by XCHG
Solar wrote:Please don't use color markup. People use different styles on this forum, and on the quite popular "mtDark2" theme, blue is exceptionally unreadable.
Oh Okay.
Solar wrote:I like the idea of a well-defined kernel - driver interface, and actually thought up a comparable scheme myself for Pro-POS. However, it is usually not practical to handle device drivers as potential malware - if you distrust even hardware drivers, your options of response should a driver turn out to be malware are severely limited, and you put a dent in your style and your performance that way.
I believe you are right. I understand that Device Drivers are known to be run at DPL0 and they become somehow a part of the kernel. What I really have to do here is to try to provide a secure way of communication between device drivers and the kernel to reduce the possibility of ambiguousness in device drivers. I think maybe a well-defined protocol between the kernel and the device drivers could help.

Has anybody here defined a protocol between his/her device drivers and the kernel? If yes, I'd appreciate it if you could share it with us (maybe a small bit of the protocol?).

Posted: Fri Dec 21, 2007 10:59 am
by Dex
DexOS as a well defind driver interface, but i have not posted info here, because as DexOS is single tasking and runs in ring0, it would be little use to you.

Posted: Fri Dec 28, 2007 7:57 am
by XCHG
Okay I guess now I have a better understanding of how this interface should be implemented.

Thanks everybody.