Unikernelは難しかった。キーワードは「だった」
Unikernels were hard. key word: were
Unikernelの再評価が進む中、Geoffrey Huntleyが自身の経験を語る。2015年当時はTCPスタックやストレージの欠如で困難だったが、今やAIがモデル重みにその知識を持ち、ライブラリの移植も容易になった。OSは設計上の負債であり、Unikernelは攻撃面を大幅に削減する。彼はOCamlでOrleansを移植した「Spaceleans」を1週間で構築し、Unikernelが難しくないことを証明した。
Unikernelは難しかった。キーワードは「だった」。今はAIがある。
HNでの議論
19- vsgherzi
この話題では以前にも言いましたが。デバッグ能力はどうなんでしょう？アプリケーションのオーバーフローが今やネットワークスタックの一部を破壊してしまいます。
Oxideのエピソードでデータラインを読み取る話が少し出ていましたが、それは実用的ではないと思います。
攻撃対象領域の削減はクールですが、システムの可視性とライブネスを犠牲にしてまでとは思いません。
- lasiotus
Unikernelはスペクトルの小さい側にあり、Linuxは大きい側にあり、その中間にはたくさんの余地があります…
- eyberg
攻撃対象領域の削減は確かにプラスですが、unikernelを実行する最大のセキュリティ上の利点にはほど遠いです。
だからこそ「攻撃対象領域の削減」についてあまり話すのが好きではなかったのです。なぜなら人々は必然的に行数やコードに目を向けますが、削減は良いとしても、最大の問題が本当は何かを伝えられていないからです。
脆弱性の悪用はデータ侵害の最大の侵入経路であり、OSコマンドインジェクションは昨年のCISA Kevで最大のCWEです。
昨年のDBIRでは、システム侵入が64回ほど繰り返されていました。
オペレーティングシステム自体が文字通り問題なのです。なぜなら本質的に多くの異なるプログラムを実行するように作られているのに対し、unikernelは1つしか実行しないからです。