What is the correct way to build static library (.lib) for kernel mode driver in 2019 ?

I am planning to use sodium in my kernel callout driver.

I use the pre-built .lib of sodium, but I get link warning:
libsodium64.lib(core.obj) : warning LNK4257: linking object not compiled with /KERNEL ; image may not run

Well, it’s not out of box for windows driver.

Then I compiled it myself with /KERNEL option. But get warning: warning D9002: Ignore unknown option “/kernel-”.

So I think maybe problem arise from the project TargetType: Static Library (.lib).

I try to change it to DriverLibrary.

But get a lot of warning C4273 inconsistent DLL linkage.

If I’m not wrong with the above idea, how to build a Driver Library correctly ?

On Apr 25, 2019, at 11:32 PM, iFengHuang wrote:
>
> I am planning to use sodium in my kernel callout driver.
> I use the pre-built .lib of sodium, but I get link warning:
> libsodium64.lib(core.obj) : warning LNK4257: linking object not compiled with /KERNEL ; image may not run
> Well, it’s not out of box for windows driver.
> Then I compiled it myself with /KERNEL option. But get warning: warning D9002: Ignore unknown option “/kernel-”.

Does the error really have a trailing dash, like you posted? If so, then you made a typo.

> So I think maybe problem arise from the project TargetType: Static Library (.lib).

No, static libraries are quite common when building kernel drivers, but you must be absolutely sure that the library doesn’t use any user-mode services. Do you know that for sure?

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

@Tim_Roberts said:
On Apr 25, 2019, at 11:32 PM, iFengHuang wrote:

Does the error really have a trailing dash, like you posted? If so, then you made a typo.

See this kernel-create-kernel-mode-binary

On Apr 25, 2019, at 11:48 PM, iFengHuang wrote:
>
> See this kernel-create-kernel-mode-binary

Yes, but if you are going to use it in the kernel, then you want /kernel, not /kernel-.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Because the Cryptography API: Next Generation there is no built-in AEAD APIs, So I’m going to try sodium.

Sodium claims to be cross-platform and portable. But Im not sure it doesn’t use any user-mode services.

Sodium is a new, easy-to-use software library for encryption, decryption, signatures, password hashing and more.

It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further.

Its goal is to provide all of the core operations needed to build higher-level cryptographic tools.

Sodium supports a variety of compilers and operating systems, including Windows (with MingW or Visual Studio, x86 and x64), iOS, Android, as well as Javascript and Webassembly.

@Tim_Roberts said:
On Apr 25, 2019, at 11:48 PM, iFengHuang wrote:

See this kernel-create-kernel-mode-binary

Yes, but if you are going to use it in the kernel, then you want /kernel, not /kernel-.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

But “sodium” is a pure C language implementation library, did I misunderstand it?

/kernel-
The code in the current project is compiled and linked without using the C++ language rules that are specific to code that will run in kernel mode.

On Apr 25, 2019, at 11:55 PM, iFengHuang wrote:
>
> Because the Cryptography API: Next Generation there is no built-in AEAD APIs, So I’m going to try sodium.
>
> Sodium claims to be cross-platform and portable.

“Cross-platform” and “portable” do not necessarily imply kernel-friendly. The fopen function is cross-platform and portable, but is not available to kernel code.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

@Tim_Roberts said:
On Apr 25, 2019, at 11:55 PM, iFengHuang wrote:

Because the Cryptography API: Next Generation there is no built-in AEAD APIs, So I’m going to try sodium.

Sodium claims to be cross-platform and portable.

“Cross-platform” and “portable” do not necessarily imply kernel-friendly. The fopen function is cross-platform and portable, but is not available to kernel code.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Please read this

So I think it maybe port to kernel not too hard.

@iFengHuang said:
Because the Cryptography API: Next Generation there is no built-in AEAD APIs, So I’m going to try sodium.

BCrypt provides GCM block chaining mode which is authenticated encryption that supports additional authenticated data. Is that not what you are looking for?

_Ron

But "sodium" is a pure C language implementation library, did I misunderstand it?

Yes and no. More on it below…

Sodium claims to be cross-platform and portable

Whenever you see the terms like "pure C language " and “cross-platform and portable”, you can be almost 100% sure that you are dealing with the code that depends upon the standard C library (although there may be some exceptions like, for example Open vSwitch).

Just for the fun of doing it I clicked on the link, and opened the very first random file. Here it is

https://github.com/jedisct1/libsodium/blob/master/src/libsodium/crypto_core/salsa/ref/core_salsa_ref.c

Look at the very first two included headers - they happen to be stdint.h and stdlib.h that userland C library exports. Therefore, it is, indeed, “cross-platform and portable” in a sense that you can use on any OS that supports the standard C library. However, once this library happens to be the userland one, it also automatically implies that it cannot be used in a kernel, which is true of any OS…

I am planning to use sodium in my kernel callout driver.

Well, with some certain amount of extra work you may, probably, use it in the kernel as well. What you have to do here is to provide your own KM implementation of the C library routines that your target library depends upon, and/or use #ifdefs to skip userland-specific parts.

It just depends on whether the whole thing is worth an effort…

Anton Bassov

Sodium is a cross platform library in a “standard” sense, meaning it should compile and work nicely in usermode environment (where absolute most people is using it). There is a quite small amount of platform-specific code, e.g. memory allocations and pseudorandom number generation.

It should not be too hard to fix the platform-dependent code to run in Windows kernel. I did it for one of our projects some years ago and it is doing its job well. Main things you need to fix are:

  • replace malloc and free with corresponding ExXxxPoolWithTag,
  • use a random number generator available in kernelmode (ege. one exposed by CNG),
  • beware of SIMD-optimized variants for some encryption schemes. AFAIK kernel does not save XMM registers on context switch. If the performance is not a priority to you, it is quite easy to avoid using these implementations – just update the initialization code responsible for detecting processor features not to see the SSE/AVX extensions (this can be probably achieved also by undefining some preprocessor macros),
  • the initialization code contains some locking, so you need to take care of that too (executive resources should do the trick).

Good luck with the porting :-).