Linux - chinng-lab AI実験室

chinng-lab AI実験室

Linux

A collection of 9 posts

eBPF入門――Linuxカーネルを安全に拡張する技術がクラウドの監視・セキュリティ・オブザーバビリティをどう変えるのか

はじめに Kubernetes上でマイクロサービスを運用していると、PodのIPアドレスが頻繁に入れ替わる環境では、iptablesベースのネットワーク制御のルール数が増大して更新コストが問題になったり、プロセス単位で動くエージェント型の監視の網羅性に限界が生じたりするケースがあります。「どのコンテナがどのファイルを開いたのか」「どのサービス間でレイテンシが発生しているのか」を、なるべく低いオーバーヘッドで知りたい——そんな課題に対して、いまクラウドインフラの根幹で使われているのが eBPF（extended Berkeley Packet Filter）です。 eBPFとは一言でいえば、Linuxカーネル内で安全にサンドボックス化されたプログラムを実行できる技術です。カーネルのソースコードを変更したりカーネルモジュールをロードしたりすることなく、カーネルそのものを「プログラマブル」にできます（ebpf.io公式）。よく使われる比喩は、「eBPFはLinuxカーネルに対して、JavaScriptがブラウザにもたらしたのと同じ変化をもたらす」というもの。静的な存在だったカーネルが

ZFS入門——Copy-on-Write・スナップショット・RAID-Zがホームサーバーのストレージをどう変えるのか

はじめに——RAID5 + ext4 からの問い自宅にNASや仮想化基盤を構築してきた技術者の多くは、「mdadmやハードウェアRAIDでRAID5を組み、その上にext4やXFSを置く」という構成に馴染みがあるでしょう。磁気ディスクが1台壊れてもパリティで復旧できる——この安心感が、長年ホームサーバーの定番構成でした。しかし、この構成には死角があります。RAID5が守れるのは「ディスクの物理的な故障」だけだという点です。もっと静かな敵、サイレントコラプション（ビットロット）はどうでしょうか。磁気ディスクは経年で、エラーや警告なしにビットが書き換わることがあります。従来のRAIDコントローラやext4は「書き込みが成功した＝データが正しい」と仮定してしまうため、破損したデータを正しいデータとして読み返し、最悪の場合、その破損をパリティ経由で他のディスクにまで複製してしまうのです。バックアップから戻そうにも、壊れた時点のファイルが「正常」として保存されていた、という事態も起こり得ます。この問いに対する1つの答えがZFSです。Sun Microsystemsで2001年に開発が

eBPF入門——カーネルを書き換えずにLinuxの仕組みを変える技術はどう動くのか

はじめに——カーネルを変えるにはなぜ難しいのか？「Linuxの仕組みそのものを変えたい」と思ったら、どうすればいいでしょうか。たとえば、特定のシステムコールを監視したい、カーネルのネットワーク処理に独自の処理を組み込みたい——そんなとき、カーネル内部に新しい処理を追加する代表的な方法は事実上2つでした（ebpf.io）。 1つ目はカーネルソースの変更です。カーネルはシステム全体を制御する特権的な存在であるがゆえに安定性・セキュリティ要件が厳しく、変更はコミュニティの合意を経てメインラインにマージされ、各ディストリビューションへ普及するまで長い時間がかかります。 2つ目はカーネルモジュールの自作です。こちらは即座に反映できますが、セキュリティ境界のない状態でカーネル空間にコードをロードするため、バグひとつでカーネルごとクラッシュする危険を伴い、カーネル更新のたびに破損リスクと隣り合わせになります（ebpf.io）。「待つか、危険を冒すか」。カーネル内部に新しい処理を加える方法としては、この2択に_flock_してきました。そして、第3の選択肢として登場したのが eBPF（ex

AI・テクノロジー

RISC-Vベクトル拡張で私のホームサーバーはどう変わる？——RVV 1.0対応チップが開く省電力セルフホスティングの現実解

はじめに電気代の高騰が続くなか、ホームサーバーの運用費を見直している方は少なくないでしょう。24時間365日動かすサーバーでは、数ワットの差が年間の電気代に確実に響きます。かといってx86ミニPCは柔軟性が高いぶん消費電力が気になり、ラズパイに代表されるArmボードは成熟しているものの「第三の選択肢」を求める声も聞こえます。そんな中、注目したいのがオープンなISA（命令セットアーキテクチャ）であるRISC-Vの動きです。とくに2026年時点では、ベクトル拡張「RVV 1.0」に対応したチップがついに実際に買える段階に入りました。SpacemiT K1搭載のBanana Pi BPI-F3など、ラズパイと同等の価格帯で入手できるシングルボードコンピュータが登場しています（価格はメモリ構成・販売店・為替で変動するため、購入時に公式販売ページで確認してください）。K1は8コアでCPU内に2.0 TOPSのAI演算力を統合し、単コア性能もCortex-A55の約1.3倍と公称されます。さらにエコシステム側も変わりつつあります。Ubuntu 25.10では要求ISAプロファイルがRV

eBPF入門——カーネルを再起動なしで拡張する仕組みと、今日から始めるオブザーバビリティ実践ガイド

はじめに結論から言うと、eBPFとはLinuxカーネルを再起動せずに、しかも安全に拡張できる技術です。カーネルのソースコードを改変することも、壊れやすいカーネルモジュールをロードすることもなく、独自のプログラムをカーネル空間で動かせます。かつてパケットフィルタとして生まれたBPF（Berkeley Packet Filter）が進化した「extended BPF」は、今やオブザーバビリティ、セキュリティ、ネットワーキングを支えるLinuxの基盤技術へと成長しています。なぜ今、eBPFなのか eBPFはすでに「研究段階の新技術」ではありません。広く採用が進んでいます。 * クラウドベンダーでの採用: AWSのEKS標準CNIやGuardDutyのランタイム監視、Azureの「Azure CNI Powered by Cilium」、GKEなど、3大クラウドのオブザーバビリティ・ネットワーキング基盤に組み込まれています。 * 商用オブザーバビリティ製品での標準利用: New Relicをはじめ、DatadogやGrafanaといった主要プラットフォームがeBPFベースの機

NASを再起動したらLXCが起動しなくなった——NFSv3のstale file handleと「見かけ上の正常性」という罠

NASを再起動しただけでコンテナが起動不能になった。エラーコードは116。findmntにはマウントが表示され、pvesm statusもactiveを返す。それでもlsは「Stale file handle」を返す。NFSv3のステートレス性が生む見かけ上の正常性と、その復旧手順、さらに復旧作業が引き起こした二次障害までを記録する。

LinuxカーネルはなぜRustを受け入れ始めたのか——Rust for Linuxの現在地とドライバ開発の変化

はじめに——カーネル開発に起きている静かな転換「LinuxカーネルにRustコードが入る」と初めて報じられたのは2022年のことです。Linux 6.1で初めてRustサポートがメインラインにマージされて以来、3年あまり。この間、Rust for Linuxプロジェクトは地味ながら着実に前進し、いまやNVIDIAのGPUドライバやAndroidのBinderドライバといった「実際に動くコード」がメインラインに存在する段階まで来ています。しかし一方で、カーネルのRust対応には未解決の課題も残されています。カーネルはまだRustの安定版機能だけでビルドできず、コンパイラ側との綱引きが続いています。2026年には最小Rustバージョンが1.78.0から1.85.0へと大きく引き上げられ、その背後では「Debian Stableに追従する」という新しいポリシーが採用されました。この記事では、Rust for Linuxの現在地を次の観点から整理します。 * なぜカーネルにRustが必要とされたのか（技術的動機） * メインラインに入ったRustコードの実採用状況 * Ru

中国、政府版Windowsを前倒し撤去——国産Linux移行が問う「デジタル主権」

Bloombergの報道によれば、中国国家安全部が一部の政府関連組織に「Windows 10 China Government Edition」の撤去を指示し、廃止時期を2027年2月から2026年後半へ前倒しした。移行先は麒麟や統信UOSといった国産Linux。フランスも250万台の政府PCをLinuxへ移すと宣言しており、OS選択は「性能」ではなく「主権」の問題へ変わりつつある。

eBPFが変えるLinuxカーネルの常識——雲の上のコンテナ基盤を支える「プログラマブルカーネル」入門

はじめに——「カーネルを変えずにカーネルを変える」とは？ eBPFという発想 Linuxカーネルに手を入れたい——。システムを深く観測したい、パケット処理を高速化したい、不審なプロセスを即座に止めたい。そんな要求は、クラウドネイティブ基盤を運用するSREやプラットフォームエンジニアなら日常的に直面します。ところが伝統的な解決策はどれも痛みを伴うものでした。カーネルにパッチを当てて再コンパイルする？メンテナの承認を待つのに数年かかることもあります。カーネルモジュールをロードする？完全なカーネル権限で動くため、バグひとつでカーネルパニック＝ホスト全体のダウンにつながります。このジレンマに答えたのがeBPF（extended Berkeley Packet Filter）です。カーネルを再コンパイルせず、危険なカーネルモジュールも使わずに、Verifierで検証された小さなプログラムをカーネル内で実行する——「カーネルを変えずにカーネルを変える」という発想です（Zenn、ebpf.io）。起源は1992年の古典的BPF（cBPF）ですが、2014年にAlexei Starovoit