タグ: ソフトウェア開発

何もかもがひどいものだ。ほとんどのソフトウェアは、たとえそれがクリティカルなシステムソフトウェアだとしても、まるでダクトテープとプチプチとヘアピンで梱包されたスイスチーズの如く安全性の低いものだ。例えば先週の怖ろしくも興味深い投稿記事「How to Crash Systemd in One Tweet」（Systemdを簡単にクラッシュさせる方法）を見てみると良い。しかしそれはsystemdだけの問題ではなく、Linuxだけの問題でもなく、ソフトウェアだけの問題でもない；業界全体に問題があるのだ。私たちが自分自身に間違って教え込んできたきたのだ。他にやりようはない、と。

それでは、そのAndrew Ayerによる面白い投稿をもう少し詳しく見てみよう、なぜならこれはより大きな問題の見事な例となっているからだ。まったく「Yay non-determinism!（非決定性バンザイ！）」だ。

もしあなたが筋金入りのギーク（技術オタク）なら、自分で投稿全体を読んだほうがいいだろう；もしそうではない場合には…簡単に説明すれば以下のようなことだ、systemdはほとんどのLinuxディストリビューションの不可欠なコンポーネントであり、その大切な役目の1つとして、システムを起動するために使用されている。Ayerはそれをクラッシュさせるためのとても簡単な方法をみつけて、それに哲学的な考察を行った。ということである。

このバグによってすぐに喚起される疑問は、一体どういった品質保証プロセスが、このような単純なバグを2年以上に渡って見逃していたのだろうかというものである。[…]systemdの問題はこの1つのバグよりも遥かに深いものだ。systemdは、設計に欠陥があるのだ。バグのないソフトウェアを書くことは非常に困難なことだ[…]良いプログラマはバグのないソフトウェアを書くことの難しさを知っているし、バグの可能性を最小にするか、少なくともその影響を低減させる方向へソフトウェアを設計することの重要性を理解している。systemdの開発者たちは、こうしたことを理解していない。不必要な複雑性を膨大に詰め込むことを決定し[…]メモリ安全ではない言語で記述した。

私が思うに、最後の点がキーとなる大きなポイントである。何もかもがひどいものだ、なぜなら私たちが今でも使っている基本的なツールは、使われる際に、必然的にひどいものを作り出してしまうような欠陥を抱えているのだ。こうした適用は、systemdのような低レベルのコンポーネントから、最近大規模なDDoS攻撃の奴隷として使われたカメラや他のIoTデバイスの事例 ‐

知覚をもった無数の電球と冷蔵庫が主要なインフラを破壊するために統合されるなんて、まるサイバーパンク小説そのものだ

– そして1億5000万ドルが失われたイーサリアム上のDAOの大惨事（実際にはその後の対応で経済的損失は防がれたが技術的、倫理的に大きな禍根が残された）のような高レベルのSF的抽象世界に至るまで、広く行われている。あまりにも長い間、ほとんどすべてのソフトウェアがバグを持ち安全ではないことに慣らされてきて、私たちはこれがソフトウェアの自然な姿だと思うようになっているのだ。しかし、この学習性無力感（長期にわたってストレスの回避困難な環境に置かれたために、その状況から逃れようとする努力すら行わなくなること）は正しくない。すべてがひどいものである必要はないのだ。

原理的には、コードは形式検証（formal verification）を用いて正しいことを証明することができる 。これはとても困難で、時間もかかり、常に実践するには現実的ではないものである；しかし、長期間に渡って何百万という機械を制御するクリティカルなソフトウェアの話をしているときには、または数百万ドルもの投資を行おうとしている際には、少なくとも考慮すべきものである。

これよりは苦労と厳密さが少なめで、ひいてはより有望なものの1つはlangsec構想だ：

言語-理論的アプローチ（LANGSEC）が関心を寄せているのは、ネットワークスタックや、その他のソフトウェアスタックの全ての階層における、入力の取扱いに対するアドホックなプログラミングが引き起こす、インターネットの非安全性の広がりである。LANGSECは、信頼できない入力を取り扱うソフトウェアを、信頼できるものにするための唯一の道は、すべての正しい或いは期待される入力を形式言語として取扱い、それぞれの入力処理ルーチンを、その形式言語への認識装置であるように取り扱うことだ、と想定している。

…このようなやりかたは着実に現実世界に近付いている。そしてフランスのセキュリティ会社Prevotyのような仲介者に依頼すれば時期尚早ということもない。

前述したように、プログラミング言語自身が大きな問題だ。膨大な経験が明らかにしたのは、プログラマたちにメモリ安全でない言語を使って安全なコードを書くことを期待するのは、現実的ではないということだ（私の昨年の記事「 Death to C（Cに死を）」が書かれたのはそれが理由だ）。しかし希望はある！破滅の予言をしたあと、Andrew Ayerはこのように注意を促している「しかし、私には改善の兆しが見えている。GoとRustはこれまでCで書かれていたようなシステムソフトウェアを書くための注目すべき安全な言語だ」。

最善は善の敵である（最初から最善であることに拘ると、次善にすらたどり着けない）。私たちは現在の不名誉な状態から一足跳びに名誉ある状態に行くことはできない。しかし産業としては、少なくとも進むべき道を設定しよう。まず最初に、より良い言語でシステムコードを書くことへ向かおう ‐ これはセキュリティとスピードを改善する筈だ。 そして、ミッションクリティカルなコードの形式仕様記述と検証に向かおう。

そしてレガシーコードとレガシーシステムに捕らわれているときには、もちろん今でもそれが大部分の時間を占めているのだが、それを徐々にでも良くして行くことを学ぶために、プログラミングの原則と基礎に注目し、最大限の努力をしよう。（例えば、JavaやC#のプログラマたちは、私の昔の同級生によって書かれた素晴らしい書籍であるPractice your JavaとPractice Your C#を読むことを検討した方が良い）。「ひどい状態」を避けられない事態だと受け入れてはならない。たとえそれが「現在の」状態だとしても。よりよい状態を目指して努力しよう。

もちろん、業界の多くが伝統的なプログラミングから離れて、様々なフレーバーのAIに向かって移行しようとしているのを見ながら、私はこれを書いている。私たちはどのように「畳み込みニューラルネットワーク」をきちんと定義すれば良いのだろうか？そこへ流し込む現実世界のデータに対して、どのようLANGSECを適用すれば良いのだろうか？これらのことを、どのように量子コンピューティングに適用するのだろうか？（もしそんな疑問を抱くのは時期尚早だと思うなら、私の友人のChristineによる、極めてクールな5ビット量子コンピューターシミュレーターをチェックしてみると良い。 Github上でオープンソースとして公開中だ）。

ああ、いや、私は最後のいくつかの疑問に対する答を持っているわけではない。しかし少なくとも問いかけることから始めよう！そしてその間に、従来のプログラミングの修正を最終的に始めることができるように、できることは何でも試みよう。それは非現実的な夢ではない。それは実際に可能なのだ。そして、もしそれを受け入れたなら、すべてが良なって行くことが可能だろう（私はそうなると信じている）。

訳注：本記事の原タイトルは「Learned helplessness and the languages of DAO」というものである。「学習性無力感とDAOの言語」という直訳になるが、「学習性無力感」の方は文中に説明がある。「DAOの言語」の方は古いSFである「The languages of Pao」（アイキャッチ画像の書籍）のタイトルをもじって、最近のソフトウェアバグに起因する有名な事案の「イーサリアムのDAO」と関連付けている。

[ 原文へ ]
（翻訳：Sako）