能否将OpenSSL移植到Linux驱动？嵌入式Linux加密方案咨询

Hey there, let's tackle this problem step by step—your goal of implementing SAE encryption in a kernel-space driver without relying on user-space OpenSSL makes total sense for a stripped-down embedded system, and I've got some practical alternatives to share.

First, let's get a key point out of the way: you cannot directly call libcrypt.so from a Linux kernel driver. libcrypt.so is a user-space shared library, built against user-space headers, dependent on user-space memory management and system calls. Kernel-space runs in a completely isolated address space with its own execution context—trying to link or invoke user-space library functions from the kernel will crash your system immediately, no exceptions.

Now, here are the viable paths forward:

1. Use the Linux Kernel Crypto Subsystem (Recommended) #

The Linux kernel has a built-in crypto framework that's designed explicitly for kernel-space encryption needs. It supports most of the primitives required for SAE (like SHA-256, elliptic curve operations, AES, etc.)—you just need to leverage its APIs instead of trying to port user-space libraries.

• First, verify kernel configuration: Check if your kernel has the necessary crypto modules enabled. For SAE, you'll typically need:
  • CONFIG_CRYPTO_SHA256 (for hash operations)
  • CONFIG_CRYPTO_EC (elliptic curve support)
  • CONFIG_CRYPTO_ECDH (key exchange)
  • Any additional cipher modules your specific SAE implementation requires
• Implement SAE using kernel crypto APIs: You'll use functions like crypto_alloc_hash for hashing, crypto_ecdh_set_secret for elliptic curve key exchange, and related kernel crypto utilities to build out the SAE handshake logic directly in your driver.
• Why this is best: It's native to the kernel, avoids user-space dependencies, offers good performance, and is maintained as part of the Linux kernel project—so it's stable for embedded use.

2. Offload SAE Logic to User-Space (Simpler Implementation) #

If you'd rather avoid diving into kernel crypto APIs, you can keep the SAE encryption logic in a lightweight user-space process, then communicate between your driver and this process using kernel-user communication mechanisms:

• Communication methods: Use netlink sockets, ioctl calls, or a character device node to pass data between the driver and user-space. The user-space process can then invoke libcrypt.so or a minimal OpenSSL build to handle SAE operations, sending the result back to the driver.
• Tradeoffs: This adds a user-space component, but it's far easier to implement than porting OpenSSL to the kernel. For a stripped-down system, you can compile a minimal user-space binary linked only against the necessary parts of libcrypt.so to keep the footprint small.

3. Integrate a Lightweight Kernel-Space Encryption Library #

If the kernel crypto subsystem lacks a specific primitive you need for SAE, look for small, open-source encryption libraries designed to be embedded directly into kernel code. Many embedded-focused projects offer standalone implementations of SAE or its required primitives (like ECC, SHA) that can be compiled into your driver without relying on external user-space libraries.

• Tips: Search for projects targeting embedded Linux or IoT devices—they often prioritize minimalism and kernel compatibility. Just make sure the library's license is compatible with your project's requirements.

Final Recommendation #

Start with the kernel crypto subsystem first—it's the most robust and efficient solution for kernel-space encryption. If your kernel already supports the necessary algorithms, this will save you a ton of time compared to other workarounds. If not, the user-space offload approach is the next easiest path to get SAE working without fighting OpenSSL kernel porting.

内容的提问来源于stack exchange，提问作者Michael