Crypto Subsystem of Linux Kernel - Asynchronous Request Handling Mechanism

由於在 crypto subsystem 中預期多個 crypto request 可以同時向同一個 crypto engine 發出請求 ,因此 crypto engine driver 必須實作對應機制,使其有能力能應付此情況。此外,結合在前一節有提到 crypto subsystem 的 asynchronous crypto API 流程,較常見的實作方式就是 crypto queue 搭配 worker,額外開一個 kernel thread 來與 crypto engine 進行溝通,並讓 crypto request 按照 FIFO 順序處理,而本文主要針對此設計方式,說明整個運作流程和細節。

Overview

條件

  1. 假設 hardware crypto engine 一次只能處理一個 request,將 request 根據需求設置好 register 之後,啟動 crypto engine 進行運算,運算完結果後才能換下一個 request。
  2. 當運算出結果後,crypto engine 會舉起 status interrupt,通知外部已運算完成。
  3. 多個 Request 有可能同時對 hardware crypto engine 發出請求。
  4. 一個完整的 crypto request 流程包含三個 API call: Init → Update → Final, Final 結果回傳後,則此 crypto request 將會被釋放,不再使用。

想法

  1. 建立一個全域的 crypto request list,將進來的 request 依序排到 list 當中。
  2. 建立一個 worker (kernel thread) 和對應的 work queue 來與 hardware crypto engine 進行溝通。worker 的任務除了從 crypto request list 中取出 request 來處理之外,也可能會包含 crypto engine 的初始化和資源釋放等工作。
  3. 註冊 interrupt handler,當 status interrupt 舉起時,呼叫 user 自定義的 completion callback function 來完成最後的流程。如果當前是執行最後的 final API call 且 request 有自定義的 resource 需要被釋放,則會在呼叫完 callback function 後執行。

實作

Linux kernel version: v5.17.3

Crypto Subsystem of Linux Kernel - Asynchronous & Synchronous

在 crypto subsystem 中,crypto API 分成 asynchronous (異步) 和 synchronous (同步) 兩種機制。

最早版本的 crypto API 其實只有 synchronous crypto API,但隨著要處理的資料量增加,運算和資料傳輸時間也可能大幅拉長,此時 synchronous crypto API 有可能讓處理流程陷入較長時間的等待,因此後來引入了 asynchronous crypto API,供使用者依據自己的使用場景來選擇適合的機制。

而 asynchronous 與 synchronous crypto API 在命名設計上有所區別,asynchronous 會在前綴多加一個 a 字,反之 synchronous 則是 s 字,以 hash 為例:

Crypto Subsystem of Linux Kernel - Overview

介紹由應用層所發出的 crypto(cryptography) request,透過 system call 將 request 傳送到 Linux kernel 端,並經由 crypto subsystem 將 request 轉發給硬體算法引擎 (hardware crypto engine) 的流程。

Overview

Crypto subsystem 是 Linux 系統中負責處理 crypto request 的子系統,除了包含流程控制機制之外,另一個重要特色就是提供演算法實作的抽象層,讓各家廠商能夠依據需求去客製化實作方式。其中一個常見例子就是廠商在硬體架構中加入用以加速特定演算法運算效率的硬體算法引擎,並且透過 crypto subsystem 將驅動硬體算法引擎的流程整合進 Linux 系統中,供其他 kernel module 或是應用層使用。

以下以 openSSL library 如何將 crypto request 傳送到 kernel crypto subsystem 為例子:

TH02 sensor device driver

馬上就要過年了,最近在整理物品的時候,突然找到一年前為了玩板子而亂買的 Grove sensor,回想當時雖然對於韌體很感興趣,不過由於工作關係,因此把大部分進修時間都花在 Web 議題,沒能完成 sensor 韌體,留下一個遺憾。而既然這次被我找出來,近期工作又是都以 FPGA 板子居多,對於相關概念已有基本認知,覺得是時候把它實作出來,了結一年前給自己的課題。

硬體

  • Grove Temperature&Humidity Sensor (High-Accuracy & Mini)
  • Raspberry Pi 3 Model B (Linux kernel 5.4.x)

技術

  • I2C linux driver
  • linux Industrial I/O subsystem
  • device tree

由於買的 sensor 有支援 I2C bus protocol,因此這次實作的 driver 就會基於 I2C driver 架構上實作。搭配 iio (Industrial I/O) subsystem 來讓 user space 能夠透過 file system 來讀取溫度和濕度。