Windows Kernel Mode compatibility for CyaSSL

Hi!

We’re considering adding Windows Kernel compatibility to CyaSSL. This means that our embedded ssl library would run in Kernel mode and use either TDI or WinSocK Kernel.

We’re not sure at this point whether we should use TDI or WinSocK Kernel. Any suggestions?

The advantages of this project may include performance enhancement for device driver implementers that want SSL security. Frankly speaking, we’re not sure if there will be other advantages and would love feedback on the general usefulness of this idea. Do Kernel developers want an SSL library? Please comment!

Thanks!

LS

Well if you want newer OS’es you have to use WinSock Kernel.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@yassl.com [mailto:xxxxx@yassl.com]
Posted At: Monday, June 07, 2010 6:20 PM
Posted To: ntdev
Conversation: Windows Kernel Mode compatibility for CyaSSL
Subject: Windows Kernel Mode compatibility for CyaSSL

Hi!

We’re considering adding Windows Kernel compatibility to CyaSSL. This
means
that our embedded ssl library would run in Kernel mode and use either
TDI or
WinSocK Kernel.

We’re not sure at this point whether we should use TDI or WinSocK
Kernel. Any
suggestions?

The advantages of this project may include performance enhancement for
device
driver implementers that want SSL security. Frankly speaking, we’re
not sure
if there will be other advantages and would love feedback on the
general
usefulness of this idea. Do Kernel developers want an SSL library?
Please
comment!

Thanks!

LS

__________ Information from ESET Smart Security, version of virus
signature
database 5180 (20100607) __________

The message was checked by ESET Smart Security.

http://www.eset.com

> We’re not sure at this point whether we should use TDI or WinSocK Kernel. Any suggestions?

TDI on pre-Vista and WSK on Vista+.

The APIs are nearly the same :slight_smile: just a minor “wrapping” difference that, in TDI, you open the device object by name, and in WSK, you get the provider dispatch table and call the method there.

Also in TDI, you fill the IRP using TdiXxx macro, set the completion routine, then do IoCallDriver. In WSK, you do not fill the IRP at all (except IIRC the completion routine) - just allocate it, and pass it to the method call.

Listen backlog is also different.

SO_SNDBUF and SO_RCVBUF are not in any of these 2 APIs, so are lingering closes.

I suspect that, if you will look at listening paths in TDI and WSK (most complex difference), you will probably design your own set of macros/inlines/functions to encapsulate the TDI/WSK difference.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com