Kernel Module Packages

出典: openSUSE

このページはまだ翻訳されていません。こちらから 英語版のページ が参照できます。 カーネルモジュールパッケージ (KMPs) は、カーネルのアップデートが生じた場合、誰もがそれぞれのカーネルモジュールを安全に取り扱える形でパッケージング作業を行うための仕組みです。

kABI の安定性

ロードされたカーネルモジュールは、Linux カーネルの一部としてカーネルの全てのデータ構造にアクセスします。当然このことから、カーネルモジュールは正確なカーネル設定、正確なコンパイル指定、そして最も重要である正確なソースコードで厳密にコンパイルされている必要があります。通常、コンパイル時にエクスポート指定したシンボルだけがアクセスされますが、現実として、近頃の2.6カーネルにおいてはエクスポートされるカーネルのシンボル数が6000以上になります。

カーネル内部インターフェース (kABI) は非常に移り気で頻繁に変更されるという事実から、カーネルのアップデートはいくつかのインターフェースを全く容易に変更できる能力を持つ必要があります。この能力により、古いバージョンのためにコンパイルされたカーネルモジュールを破棄することができます。幸いこれはシンボルのバージョン記述によって検出することができるので、カーネルに古いバージョンのモジュールをロードすることや不正データが発生することを未然に防止することになります。

カーネルモジュールの歴史

このカーネルとカーネルモジュールとの間の密接な関係は、SUSE/Novell を含むディストリビューターがこの2つを一緒にコンパイルし、RPM 形式の一括カーネルバイナリとして提供していたという経緯にさかのぼります。全てのカーネルモジュール(ほとんどはドライバーの類ですが)はカーネル内に取り込むことが要求されたので、カーネルのセキュリティーアップデートのたびにユーザーによって再コンパイルする必要がありました。

このカーネルモジュールの扱い方によるアプローチでは、次のような制約がありました。

• ツリーにカーネルモジュールを受け入れようとする意欲にも関わらず、サードパーティーが作成したカーネルモジュールを含んだカーネルアップデートを行う場合、正しく扱う方法が提供されない。最悪の場合、明らかにユーザーエクスペリエンスの上では最も好ましくない、カーネルアップデート後にシステムがブートできないという状況を引き起こす。
• カーネルモジュールは常に提供されるとは限らない。法的規制の存在により、ソースコードの品質や移植性、テストの実現性(テストを行うためのハードウェア資源不足、人手や知識不足のため)が損なわれてしまう。
• 時にはカーネルモジュールの作成がディストリビューションのリリースまでに間に合わないために、カーネルモジュールやドライバー(または新しいバージョンのカーネルモジュール)を後から提供するという提供側の一方的な都合の良いやり方によって先送りにされてしまう。

カーネルモジュールパッケージの登場

そのアイデアは、カーネルモジュールをディストリビューターが提供する PRM 形式のカーネルバイナリの一部としてではない形で、安全に統合することにあります。誰もが正しい知識さえあれば、特定のカーネルのバージョンに適合し、正しく動作するカーネルモジュールを作成することができます。これを解決するための難しい問題は、カーネルのセキュリティーアップデートの際に提供されているカーネルモジュールの機能性が保たれるようにメンテナンスすることです。This is achieved by reusing the module if possible and by requiring a recompiled modules if needed.

To address this, the following steps are taken on a kernel update:

• detect third party kernel modules
• for every module, check whether it still works with the new kernel (by looking at all the needed symbols and their versions)
  • if it still works, make sure it can and will be reused by the new kernel
  • if it is not compatible with the new kernel anymore
    • try to download a new kernel module RPM
    • if this is not available display an error message (and by default abort the update)

This is all that the user gets to see -- once kernel module packages are installed, updates will automatically be downloaded and installed if needed.

But to make this happen, the distributor and the module provider need to do a bit of work:

To make sure new kernel modules get recompiled and provided on a server, the distributor can offer to have people register their modules; the module creators then can be notified on kABI changes that affect them. This is optional, but saves time as these notifications usually can be done prior to a kernel release. Later, this should also be possible to do within the build service provided by openSUSE.

Alternatively, the distributor can also offer to recompile the modules itself -- Novell does do so for some extra modules it provides this way -- and Novell Partner Engineering (formerly: Developer Services) offers it as a service for partners -- contact P. Oswald to get more information if this is interesting for your company.

In case of kABI changes, a mere recompilation of the module against the right kernel sources does do the job -- it is Novell's policy not to require code changes (read do kAPI changes) in security updates. This even applies to SLES service packs, though exceptions are not completely impossible there. But as even this simple recompilation can create a bit of work, Novell does watch changes closely nowadays and tries hard to avoid kABI changes for security/maintenance updates for SLES and SUSE Linux. However, SLES service packs will typically change a good part of the kABI -- and openSUSE factory kernels are expected to have kABI changes very often, as the upstream development is tracked there.

Kernel Module Package format

There are two different mechanisms used to check compatibility of the module with the kernel, depending on the version of SUSE Linux. For SLES9SP3/NLD9SP3/OESv1SP2 and SUSE Linux 10.0 (these versions subsequently referred to as Code9), there's a separate tool called kernel-update-tool that does the work. It gets invoked on kernel updates and does all the checks and downloads. For SLES10/SLED10/OESv2 and SUSE Linux 10.1 and later (subsequently referred to as Code10), the solution has been integrated with the normal system installation, configuration and update tools. Consequently, the dependencies on kernel symbols have been mapped to RPM dependencies that the dependency resolver will then try to fulfill using the available installation/update sources and this way automatically download needed modules or detect missing dependencies.

The kernel module packages are normal RPMs that contain the kernel modules (.ko files) and a bit of metadata. For the third party kernel modules to be identified, updates to be found, etc., the kernel module packages need to conform to packaging conventions. Packaging conventions are documented separately for the older Code9 solution and for newer one for Code10.

The solution to provide downloadable updates is also slightly different. Whereas the Code9 requires the RPM to arranged in a specific directory structure on a http (or ftp) server, the Code10 solution requires the format of a YaST installation source -- we recommend using the yum format.

Like any other RPM, the kernel module packages should have a GnuPG signature. The updater will check it and complain if the package is not signed, signed by an unknown party or is corrupted. On initial installation, the install documentation or install script should thus recommend to import the GnuPG signature key of the module package provider into the RPM keyring to mark that RPM package provider as trusted.

Initial Module Installation

The above deals with how third party kernel modules can survive kernel updates without creating trouble for the user. But how can additional modules be found initially?

• The module packages can be part of a product. Vendors may include the RPMs on driver CDs or whatever the normal software distribution channel is. For Code10, a tiny script that registers an update source and offers to import the GnuPG package signature key into the RPM keyring are recommended.
• The module packages can be offered for download. RPMs can just be downloaded (Code9) or the download location can just be entered as installation and update source during installation time (or later) in the installer/updater (Code10).
  • The user can find the download sites by searching the vendor's site, reading documentation from the vendor or from others, following hints from openSUSE, search engines, etc.
  • To save search work, a better automated mechanism that saves the searching work for the end user using a software/driver portal where software providers could register additional installation/update sources which are offered by YaST optionally at installation time is in preparation. Offering packages as function of the detected hardware is also part of the design.

The packaging format specification also takes care that modules that have been created for a different kernel version, but are compatible with the one that's installed on the system will get used for the installed kernel.

Support and Certification

Support and Certification are only relevant for the Enterprise products (SLES, NLD/SLED, OES). Support in this context refers to the ability of customers to open support calls and get guaranteed individual attention (including engineering efforts) to the problem they are reporting.

A kernel module has access to the kernel address space and can easily put the stability and reliability of the operating system at risk. Modules unknown to Novell have the status "unsupported" and upon loading them will generate a warning message to the syslog and "taint" the kernel. If a user has such an unsupported kernel module loaded, Novell can not do very much to help with kernel problems. Instead the problem should be reproduced without such a module loaded to be debuggable.

However, it is possible for a module provider to get the module in the "eXternally supported" status; for this it's necessary that he works closely with Novell. The appropriate support channel interfaces need to be in place to allow Novell support and the module provider to work jointly on a customer issue. The kernel module package needs to be built according to the rules specified above -- best by having it built by Novell's build service (Novell Partner Engineering). Modules built this way can also be tested and certified and thus become part of certified systems.