Loading article…
フリーソフトウェアやオープンソースソフトウェアの文脈では、バイナリ実行ファイルとしてのみ利用可能なプロプライエタリソフトウェアは、ブロブまたはバイナリブロブと呼ばれます。この用語は通常、オープンソースオペレーティングシステムのカーネルにロードされるデバイスドライバモジュールを指し、システムファームウェアイメージ、マイクロコードアップデート、ユーザーランドプログラムなど、カーネル外で実行されるコードにも適用されることがあります。[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]ブロブという用語は、最初にデータベース管理システムで、単一のエンティティとして格納されるバイナリデータの集合を説明するために使用されました。
コンピュータハードウェアベンダーが製品の完全な技術文書を提供すると、オペレーティングシステム開発者はオペレーティングシステムカーネルに含めるハードウェアデバイスドライバを作成できます。しかし、 Nvidiaなどの一部のベンダーは、一部の製品について完全な文書を提供せず、代わりにバイナリのみのドライバを提供しています。この慣行は、高速グラフィックスドライバ、無線ネットワークデバイス、ハードウェアRAID コントローラで最も一般的です。[ 7 ] 特に注目すべきは、非無線ネットワークインターフェイスコントローラのクローズドソースドライバは非常にまれで、ほとんどの場合、標準ユーティリティ ( ifconfigなど) を使用してすぐに構成できます。OpenBSDのTheo de Raadt は、これを単一のFreeBSD開発者による作業によるものとしています。[ 8 ] [ 9 ]
FSF が承認したプロジェクトの中には、フリーなオペレーティングシステムを提供することを目指し、ハードウェアのドキュメントやデバイスドライバおよび適用可能なファームウェアのソースコードが利用できない場合は、すべてのバイナリブロブを削除するものがあります。このようなプロジェクトには、 FSFLAのLinux-libreカーネルパッケージ、Parabola、Devuan、Trisquel、LibreCMCなどがあります。[ 10 ]しかし、オープンソースプロジェクトの大多数は、バイナリのみのデバイスドライバ (ブロブ) とバイナリのみのファームウェア (ブロブとはみなされない[ 11 ] )を区別し、特定のプロプライエタリファームウェアをカーネルの一部として自由に配布できるようにしています。また、一部のコア貢献者の反対にもかかわらず、外部で配布されるプロプライエタリデバイスドライバの使用もサポートし、そのようなプロプライエタリドライバとユーザースペースコンポーネントがシステムと連携するための内部互換性インターフェイスを提供しています。[ 12 ] [ 13 ]この方針に従っているプロジェクトには、 Linux カーネル自体、NetBSD、FreeBSD、DragonFly BSD、およびほとんどのLinux ディストリビューションなどがあります。[ 14 ] これらのプロジェクトの中には、独自のファームウェアを使用せずにシステムを構築するオプションを提供しているものもあり、そのためオンデマンドのソースレスマイクロコードは除外されます。[ 15 ]
OpenBSDプロジェクトは、バイナリ デバイス ドライバをソース ツリーに受け入れないだけでなく、公式にはサードパーティのプロプライエタリ デバイス ドライバ コンポーネントをプラットフォーム上でサポートしないという注目すべきポリシーを持っています。[ 16 ] : 38...検出不可能または修復不可能なセキュリティ上の欠陥の可能性だけでなく、ソフトウェアのオープン性と自由への侵害も理由として挙げています。[ 17 ] フリーソフトウェア財団(FSF) はバイナリ ブロブに対して積極的にキャンペーンを行っています。[ 18 ] FSF はまた、OpenBSD のポリシーは紛らわしい表現であると考えています。BSD コミュニティでは「ブロブ」は非フリー ドライバとみなされるもののみを指し、プロプライエタリ ファームウェアやソースなしのマイクロ コードには適用されないからです。[ 19 ] : BSD Debianプロジェクトは、Linux カーネルからフリー および非フリーのバイナリ ファームウェアの両方を含め、 Debian ソーシャル コントラクトに従って非フリー パッケージを明確にマークして分離しました。 [ 20 ] Debian 6.0 以降、これらのブロブは削除されました。[ 19 ]： Debian
OpenBSD のプロジェクト リーダーであるTheo de Raadt氏は、マイクロコード ファームウェアのみの配布権を要求する方針を擁護している。「配布されれば、少なくともデバイスは動作する」。代替案は、彼の小規模プロジェクトのメンバーが多くのチップセットのアセンブリ言語でフリー ファームウェアを自らコーディングすることになることを示唆し、「これ以上タスクを増やさないでくれ」と懇願している。それにもかかわらず、彼はファームウェアなしで動作するチップセットを好み、市場投入は遅いが成熟しているというアジア設計を高く評価している。[ 17 ]
Linuxカーネル開発コミュニティでは、 Linus Torvaldsがバイナリのみのモジュールの問題について強い発言をしており、「バイナリのみのモジュールで自分の手を縛ることなど考えもしない」と主張し、さらに「バイナリのみのモジュールを使うのは、彼ら自身の問題だと知ってほしい」と述べている。[ 21 ] 2008年には、176人のLinuxカーネル開発者がLinuxカーネルモジュールに関する声明に署名し、「署名したLinuxカーネル開発者は、クローズドソースのLinuxカーネルモジュールやドライバは有害で望ましくないと考えている…我々は、それらがLinuxユーザー、企業、そしてより広範なLinuxエコシステムに有害であることを繰り返し発見してきた」と述べている。[ 22 ] LinuxカーネルのメンテナーであるGreg Kroah-Hartmanは、 GNU General Public LicenseライセンスのLinuxカーネルに対してクローズドソースのモジュールを再配布することは違法であると述べている。[ 23 ]
しかし、Linuxカーネルには、さまざまなデバイスドライバが必要とするクローズドソースのファームウェアが含まれています。[ 24 ] [ 19 ]ソースのないマイクロコードを含むすべてのバイナリブロブを削除しようとするLinuxカーネルのバージョンであるLinux-libreのメンテナーであるAlexandre Olivaは、2011年に次のように書いています。「Linuxは、1991年以来公開してきたLinuxディストリビューションでTorvalds氏が初めて非フリーソフトウェアを受け入れた1996年以来、フリーソフトウェアではありません。この数年間で、このカーネルは14倍に成長しましたが、Linuxドライバが必要とする非フリーファームウェアの量は、驚くべきことに83倍に増加しました。」[ 25 ]
Androidオペレーティングシステムを搭載したモバイルデバイス用のドライバのほとんどはバイナリ形式で提供され、特定のバージョンのLinuxカーネルにリンクされています。そのため、カーネルバージョンのアップグレードは非常に困難です。リバースエンジニアリング、独自仕様のデバイスドライバをフリーソフトウェアとして再実装すること、ラッパーの作成とデバッグ、バイナリパッチ適用、あるいはこれらの手順の組み合わせが必要になる場合があり、結果として旧型デバイスは最新のAndroidバージョンを入手できないことになります。
実行可能なバイナリブロブが問題となる理由はいくつかあります。[ 11 ]
まず、ドライバの正確な動作は把握できず、ソースコードの監査によってバグを検出することもできません。バグは、システムが予期せぬ動作を始めたときに、綿密な調査によって初めて診断されることがよくあります。このような未検出のバグは、ユーザーやシステムをセキュリティ上の危険に静かにさらす可能性もあります。したがって、ドライバの目的適合性を確認することはできず、たとえバグが見つかったとしても、それを簡単に修正する方法はありません。
第二に、ソースコードが公開されていないため、ドライバはユーザーによる容易な改良ができず、当初サポートされていなかったアーキテクチャへの移植も、ハードウェアのわずかなバリエーションに対応するように適応させることも、APIやアーキテクチャが変更された新しいカーネルで動作するように更新することもできません。
第三に、このソフトウェアを使用すると、ユーザーはベンダーや第三者がバックドア、スパイウェア、悪意のあるコードをデータに仕込まないことを信頼せざるを得なくなります。また、ハードウェアベンダーは特定のオペレーティングシステムのサポートを中止したり、いつでもドライバのメンテナンスを放棄したり、あるいは会社が倒産した場合にドライバのサポートを完全に停止したりする可能性があります。
最後に、バイナリブロブは、フリーソフトウェアの理念を信じ、プロプライエタリソフトウェアを拒否するコミュニティと、純粋に技術的な理由からオープンソースを望ましいと考えるコミュニティとの間に境界線を引くものと見なすことができる。後者は、バイナリブロブが「動作する限り」強い反対意見を持たないことが多い。このような分断、そしてLinuxへのプロプライエタリコンポーネントの受け入れの増加は、メーカーがバイナリのドキュメント提供をますます拒否する傾向にコミュニティが抵抗する力を弱めていると見なされている。
ラッパーとは、あるオペレーティングシステムが、別のオペレーティングシステム用に作成されたバイナリ形式の独自デバイスドライバを使用できるようにするソフトウェアです。ラッパーの例としては、 Linux用のNDISwrapperや、FreeBSDおよびNetBSD用のProject Evil などがあります。これらのラッパーは、 MicrosoftのNDIS APIを実装することで、これらのオペレーティングシステムがMicrosoft Windows用に作成されたネットワークドライバを使用できるようにします。
もう 1 つの例は、外部ユーティリティを使用してハードウェアを保守できるように互換性レイヤーを提供することです。例としては、FreeBSDの一部のRAID コントローラドライバがあり、システム管理者はFreeBSD で Linux 互換性レイヤーを有効にし、ハードウェアを監視および保守するためにハードウェア メーカーから直接 Linux 固有のバイナリ ブロブを独自に入手する必要があります。[ 12 ] [ 13 ] [ 26 ] 2005 年頃、このような状況により、OpenBSD はRAID監視の代替ソリューションとしてbio(4)、bioctl、およびsensor ドライブの概念を作成し普及させました。 [ 27 ] [ 16 ]これらの概念は、その後NetBSDにも取り入れられました。
ファームウェアは、ハードウェアに付属するオンボードコントローラに必要なソフトウェアであり、一般的にバイナリブロブとはみなされません。 [ 28 ] [ 19 ] : BSD [ 11 ] : ...多くのデバイスでは、ファームウェアは不揮発性のオンボードフラッシュメモリに格納されますが、コスト削減とバグ修正の容易化のため、一部のデバイスにはスタティックRAMのみが含まれており、電源投入のたびにホストオペレーティングシステムがファームウェア/マイクロコードをアップロードする必要があります。このようにファームウェアはオペレーティングシステムドライバに存在しますが、単にデバイスにコピーされるだけでCPUによって実行されないため、ファームウェアが常にデバイス内に格納されていたとしてもDMA攻撃で既に可能なことと比較して、追加のセキュリティ上の欠陥に関する懸念はなくなります。OpenBSDプロジェクトはバイナリファームウェア/マイクロコードイメージを受け入れ、ライセンスが許可すればこれらのイメージを再配布します。[ 28 ] [ 29 ]ベンダーが自由かつ無条件の再配布を許可しない場合、これらのイメージを取得するためのマシン命令がポートツリーで提供されることがあります（これにより、初期インストール時に一部の制約のあるワイヤレス デバイス（例: Intel Wireless）が使用できなくなります）。[ 30 ] Microsoft Windows の実装では、マイクロ コード バイナリは、分離されたマイクロ コード ファイルではなく、SYS / DLL / VXD デバイス ドライバに直接埋め込まれることがあります。
Microsoft EdgeやGoogle Chromeなど、オープンソースプロジェクトをベースにした多くのプロプライエタリソフトウェアには、ハードウェアアクセラレーション用のプロプライエタリラッパーライブラリ（DLL / SO）が含まれています。[ 31 ]ラッパーライブラリはドライバではなく、特定のハードウェアデバイス（AMD、Intel、NVIDIA、Qualcommなど）でハードウェアアクセラレーションを呼び出すアプリケーションに関連しています。
ブートローダーとして機能し、従来のリアルモードアプリケーションをサポートするBIOSは、多くのIBM互換コンピュータの重要なコンポーネントです。1990年代後半、従来のBIOSをモジュール型ドライバモデルを備えた最新のインターフェースに移行することを目的として、EFI（Extensible Firmware Interface）の開発が始まりました。EFIはクローズドソースであり、最終的には多くの業界をリードするハードウェアメーカーによってUEFI（Unified Extensible Firmware Interface）として採用されました。EDK（EFI Development Kit）は、EFIファームウェア開発プロジェクトを支援するために開発されました。[ 32 ]
また、1990年代後半には、従来のBIOSに代わるオープンソースの代替品をゼロから作成するためにcorebootプロジェクトが開始されました。 [ 32 ] coreboot開発者コミュニティはStefan Reinauerを中心に組織され、コミット権限を持つファームウェア開発者によって率いられています。[ 33 ]クローズドソースのバイナリファームウェアがx86アーキテクチャの中核を成していたにもかかわらず、corebootはユーザーに基本的なハードウェアサポートを提供するために必要な少数のプロプライエタリバイナリのみを組み込んでいます。[ 34 ] BIOSとUEFIに完全に代わるオープンソースの代替品はlibrebootであり、これはフリーソフトウェア財団（FSF）によって推進されました。[ 35 ]
は、ソースコードのないベンダーコンパイル済みのバイナリドライバです。
頑固なベンダーはごく少数しか閉鎖的のままです。/ イーサネット 95% 文書化済み 99% 動作中 / オープンドキュメンテーションは主に一人の人物の努力によるものです：ビル・ポール
カーネルが COMPAT_LINUX オプションでコンパイルされている場合、または aac_linux.ko および linux.ko モジュールがロードされている場合...
カーネルが COMPAT_LINUX オプションでコンパイルされている場合、または aacraid_linux.ko および linux.ko モジュールがロードされている場合...
バイナリ専用のドライバ Linux RAID管理ツール