「Trusting Trust」攻撃に対抗する

シュナイアーさんによるblogエントリ（ https://www.schneier.com/blog/archives/2006/01/countering_trus.html ）は、もう10年も前ですので、その世界では特に新しい話題というわけではないようですが、私が知ったのは今年のはじめのことでしたので*1、この機会に紹介する文章を書いてみたいと思います。

Unixを作ったケン・トンプソンさんがチューリング賞を受賞された際の講演「信用を信用することができるだろうか」（ Reflections on Trusting Trust ）は、その暴露的な部分（UNIXのloginコマンドにバックドアがあった、とする）の真偽はさておき、もしコンパイラのバイナリが「信用できない」ものだったら、という場合における、潜在的な脅威の可能性を否定することの難しさの指摘でした。*2

以下で述べる話題は、直接的な「コンパイラのバイナリを精読する」といった手段と比べると、大幅に省力的で、また、そのような可能性に対してある種の「相対的」安全性という考え方を示すものにもなっています。

詳細は、デイヴィッド・ホイーラーさん*3のD論 Fully Countering Trusting Trust through Diverse Double-Compiling（ http://www.dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html ）となっていて、だいぶ大部ですが（私も全部は追いきれていません）、基本的なアイディアのスケッチは、けっこう以前からUSENETで議論されていたという程度には、簡単なものです。

まず基本的な問題について確認

トンプソンさんの講演の詳細を知っている方は、この節は飛ばして問題ありません。

しばしば、オープンソースのプロダクトは、たくさんの目でソースコードがチェックされているのだから安心だ、と主張されます。その当否はともかくとして、その大前提に、コンパイラは絶対に信用できるものだ、という仮定があります。

しかし、本当にコンパイラは信用できるのでしょうか？　噂では、性能比較に使われるベンチマークプログラムはその目的上、共通のものが広く公開されているので、そのパターンを検出して特別な最適化を掛ける、というチートが仕込まれていたコンパイラがあった、といいます。もしそれが単なる最適化ではなく、対象にバックドアを仕込むようなものだったら？

コンパイラだってオープンソースのコンパイラなんだから大丈夫！　でもそのコンパイラをコンパイルするコンパイラに何か仕込まれていたら？　理屈では、一種の自己再生プログラム（いわゆるクワイン）のテクニックを利用して、ソースコードには何の痕跡も残さずに、コンパイラのバイナリから、それによってコンパイルされた、次の世代のコンパイラのバイナリへ、と、悪意を持ったコード片を「感染」させ続けることが可能です（プログラムのテクニック自体としては、一種のパズルのようなものとして知られていたものではあるものの、そのようにセキュリティに対する深刻な脅威として、可能性があると（広く注目されるような場で）示したのが、トンプソンさんのチューリング賞講演でした）*4*5。

すぐに思いつく対抗法

コンパイラのバイナリを精読してチェックする（ブラックボックスチェック）、あるいはソースコードとの対応が取れているかチェックする（ホワイトボックスチェック）というあたりが、まず思い浮かぶでしょう。それができればそれに越したことはありませんが、たとえばGCCなど、実際に使われているコンパイラはそれなりに大きく、大変な作業です。プログラムでできないか、と考えるかもしれません。いい着目点ではありますが、やはりそのプログラムは信頼できるのか、ということになります。

あるいは、コンパイラではなくインタプリタを使おう、と思うかもしれません。しかし、そのインタプリタをコンパイルするコンパイラが、ということになります。問題の場所は移動しますが、必要な作業はそんなに変わらない、ということになります。

ここで、GCCの昔話を

今では多くのUnixライク環境で、バイナリパッケージによるインストールは当たり前のものとなりました。何らかのプログラミング言語の処理系を「野良ビルド」するにあたり、いわゆるセルフホスティングであったり、そうでなくても自分自身のビルドに自分自身が必要であっても、まずバイナリパッケージを使って簡単に必要な環境を作ることができます。

昔は、なんでも野良ビルドが当然であり、わざわざ「野良」などと付けるようになったのもある時代以降ではなかったか、というような記憶があります。そして、難しさの点で大物*6のひとつが「プロプライエタリなUNIX環境へのGCCの導入」でした。

普通のやりかたとしては、GCCのバイナリを、同じ環境を使っている他のユーザからGNUの助け合いの精神にもとづきコピーしてもらってくれば良いわけですが、全く同じ環境というのもなかなか無かったりするわけで、いわゆる「言語処理系のブートストラップ」の一種のような作業で「最初のGCCのバイナリ」を得ることになります。

今でもGCCのビルドの説明には、ステージという表現が使われていますが、この時代には次のような意味がありました。

stage1で得られるのはGCCによるコンパイル結果ではありませんから、バイナリ的にも違ったものなはずです（一種のキメラ的存在と言えるかもしれない）。一方、stage2とstage3は、どちらもGCCによるコンパイル結果ですから、結果は一致するはずです（理論的には一種の「不動点」）。結果が一致しても、必ずしも問題が無いとは言い切れませんが、結果が一致しなければ高い確率で問題が存在するはずです。

ここで注目すべきなのは、このプロセスは「何らかの既存のGCCバイナリ」に依存していない、という点です。これを利用したのが Diverse Double-Compiling による、Trusting Trust 攻撃への対抗だ、ということになります。

図法の導入

伝統的な「T図式」（ T diagram ）というものもありますが、ここでの議論には少し向いてない面があるので、次のような図法を使います（ Fully Countering Trusting Trust through Diverse Double-Compiling の、§4.1 にある図）。

中央の四角がコンパイルプロセスを表現していて、上からの矢印がそのコンパイルに使用するコンパイラのバイナリ、左からの矢印がコンパイル対象のソースコード、右からの矢印がコンパイルオプションなどの「ソースコード以外」のコンパイル結果に影響を与える要素（以下では省略します）、下に出ている矢印がコンパイル結果であるバイナリ生成物、という感じになります。

この図法で、前節で話題にした、プロプラUNIX環境へのGCCの導入をあらわすと、次のようになります。

Diverse Double-Compiling

提案手法では、次の図のような手続きで、調査対象のコンパイラの2種類のバイナリを作ります。

右側は、自分自身をコンパイルできる（セルフホスティングな）コンパイラの、通常のコンパイル手続きです。対称性のために2回コンパイルしていますが、原理を示す上では1回でかまいません（2回とも、同じ結果が得られているはずです。説明のため、ここではGCCとします）。

左側は、GCCの導入において「プロプライエタリUNIX付属のcc」であった部分を「何らかの信頼できるコンパイラ」に変えたもの、という感じになります。最初のコンパイラが信頼できるコンパイラですから、stage1のコンパイラはソースコードときちんと対応しているはずです。ですからstage2のコンパイラは、（ソースコードがGCCだとすれば）最初の「信頼できるコンパイラ」と「GCCのソースコード」を信じられる限りにおいて、信じられるはず、ということになります。

そして、この信じられるコンパイラは、右のほうのプロセスで作られたコンパイラと、バイナリ的に一致するはずです。もし一致しなければ、何らかのおかしな仕掛けが仕込まれている可能性がある、ということになります（もちろん、これまで触れてきませんでしたが、コンパイルされた時刻を埋め込む、などといった特異な要因が無ければ*7*8）。

ここで大事なことは、GCCのような大きなCコンパイラのバイナリコードをチェックする、というような大変な仕事ではなく、「信頼できて、GCCをとにかくコンパイルできれば良い（コンパイルが遅くても、最適化が全く無くても）コンパイラを用意すること」と「2つのファイルの単なるバイナリ比較」という、（比較すればそれなりに）単純な仕事で、問題点の検出が可能になった、ということです。

相対的な信頼性

またこの手法は、LLVM clangでGCC（ここではコンパイラコレクションの意）のCコンパイラをビルドする、あるいはGCCのCコンパイラでLLVM clangをビルドする、といったようなプロセスで、「絶対に信頼できるCコンパイラ」が無くても、ある程度相対的には信頼できると確認できる、ということも示しています。

まとめ

現実的には考えにくいとはいえ、その危険性から脅威と考えられる「Trusting Trust」攻撃に対して、（世界的なセキュリティ界隈では以前から知られていたもののようですが）有効な対抗手段があることを紹介しました。

世界にコンパイラの実装が1種類ではまずく、少なくとも2つ以上、できればもっと多数あるべき、という「多様性の善」を示すものにもなっているように思います。また、セルフホスティングができると、自分の非標準なオレオレ拡張を、自分自身の実装に使いたくなるんじゃないか、という気がしますが、それをやってしまうとこのような検証ができなくなる、ということもわかります*9。あと、極小Cコンパイラとして8ccという実装がありますが（ https://github.com/rui314/8cc ）GCCをコンパイルできれば、もしかして「最初の信頼できるコンパイラ」として有用だったりしないでしょうか？　（これについては全く私は手を付けてません）

*1:追記1: どうも10年前に、こちら http://www.radiumsoftware.com/0603.html#060329 の最後の段落で、話題自体は読んでいたようです。

*2:（2018年8月追記）また、講演録を読むと最後のほうで、クラッカー（特に、今で言ういわゆる「スクリプトキディ」）について、きつい語が並んでいますが、それも背景の説明が必要なようです。受賞は1983年で、その当時は、本格的なパーソナルコンピュータが広まる前である一方、映画『ウォー・ゲーム』が公開された年でもあり、フィクションとないまぜの「コンピュータを操る少年」像がしばしば「神童」的に扱われ、マスコミを賑わしていた、というような背景があります。また、いわゆる「ハッカーはクラッカーじゃない」問題の源流の一つでもあり、講演後に（以下出典未確認）CACM誌でRMSと論争になった、という話もあります。

*3:BW変換のWであるデイヴィッド・ホイーラーさんとは特に無関係のようです。

*4:講演録では、トンプソンさんが知ったネタ元は、Multicsのセキュリティに関する空軍の文書とありますが、その後確認されたところによれば Karger, P.A., and Schell, R.R. Multics Security Evaluation: Vulnerability Analysis. ESD-TR-74-193, Vol II, June 1974, p 52. という文献だとネットの情報にはあります。

*5:余談ですが、Multicsは高水準言語をOSの記述に使おうとしたという点でも先進的でした（言語はPL/I）。日本でその影響を受けて開発されたHITAC 5020 TSSも、PL/IWというPL/IのサブセットをPL/IWで書いて、人力コンパイルでブートストラップしたと伝えられていますから、この記事とも少々関係があります。

*6:現代と違って、昔はC言語処理系の標準準拠もいろいろ怪しかったりすると、けっこう一筋縄ではなかったりした。

*7:あるいは、近年のセキュリティ技術という観点からは、アドレスを決め打ちするような攻撃に対抗するべくランダム化を掛ける手法がありますが、そういうのとも相性が悪いでしょう。

*8:追記2(参): Debianプロジェクトなどによる、ReproducibleBuilds（日本語解説）として、バイナリ再現性の重視について推進するプロジェクトがあります。

*9:追記3: これも http://www.radiumsoftware.com/0603.html#060329 で指摘されているのを、どこかで覚えていたようです。

POSIXとのつきあいかた

コンピュータ関係の技術的なものや技術的でないもの（標準規格とかいったようなものの半分は技術仕様ですが、もう半分は業界政治で出来ていると言えるでしょう）との「つきあいかた」にはいろいろあります。

私のこれまでの経験などから、POSIXとのつきあいかた、といったようなことについて、いくつかの事例を示してみたいと思います。

Bashismとのたたかい

まぁ、Bashismとの戦いという点では、おまえらPOSIXを守ってくれ、と言いたい側ではあります。日常生活しているシェルはbashであるとはいえ、shebang が #! /bin/sh となっているのにFreeBSDの /bin/sh （ash系）で盛大にコケるようなものが生態系として定着してしまうのはなんだかんだ言って脅威なわけで、過去にいくつかのプロダクトに向けてチケットを投げたりパッチを書いたこともあります。Bashismではないですがseqコマンドの代替をシェル関数として実装したりだとか。

とは言え、自分自身、FreeBSDの環境で動いてしまうものについては見逃しているだろうことも多く（シェル（シェルスクリプト）の構文では、微妙な所でashではエラーにならないが、bash含め一般にはエラーになる例、というのを引っ掛けていたこともある）、一応それなりにチェックしたい時には、FreeBSDのベースシステムの実装、GNUの実装、Plan9由来の実装（portsにいくつかある）、Heirloom Project（heirloomとは遺産のこと）がメンテしている伝統的Unix由来の実装（これもportsから入れられる）、それぐらいを確認手段にしています。

GNU AWK

と、言ったそばから逆のことを言うようですが、AWKの ** 演算子は非標準として有名ですけども、AWKは言語仕様上、言語処理系側で拡張されてないとなんだかんだで色々なことができませんから、必要であればGNU AWK依存だと割り切って書く、ということも必要でしょう。今の所自分がAWKで書いたプログラムにはありませんが、gawkを使いたくなりそうな点というとまずは多言語対応とかそのあたりでしょうか。

GNU Coding Standards

GNU/Linuxシステムでよく使われているcoreutilsのユーティリティには、POSIXLY_CORRECTという環境変数を設定することによって、（おそらく各ツールの製作者がrationalと考えたものである）通常の挙動から、POSIXにより厳格に従った挙動に挙動を変更するものがあります。

あるいはもっと一般に、GNU Coding Standards （ https://www.gnu.org/prep/standards/standards.html ）の中には多くの場所で、POSIXへの言及があります（重複を除いてざっと二十数箇所ぐらい）。これはある意味で「GNUプロジェクトという立場からの『POSIXとのつきあいかた』」と言えるでしょう。

（以下余談。その「POSIX」という名前をsuggestしたのはリチャード・ストールマンさんだ、という話があります*1。また、GNUのコーディング規則は、すごく古いもの http://think-gnu-distribution.appspot.com/html/tga04.html#h.2 も比較して読むと、時代の変遷や「GNUのコアな所」が見えて面白い）

paxコマンド

アーカイブユーティリティのpaxコマンド（ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html ）は、POSIXの性格を示すコマンドの一つだと思います。tarとcpioという乱立に乱立を重ねた状態にあったアーカイブユーティリティについて標準化するにあたり、既存のものを標準化するのは諦め、さらにもう一つの（願わくば、混乱の収拾に至る道となってほしい）種を播いた、と言えるでしょうか。その種は、混乱の収拾に向けて、育っていると言えるでしょうか。paxコマンド、使ってますか？　ちなみに私は使って（使えて）いません。

dateコマンドのオプションの無さ

標準Cライブラリ（libc）にはいくつかの便利な関数がありますが、それをちょっと使いたい、といった時に、Cのコードを書いて試すのは少々ではありますが、手間です（Cインタプリタ、たとえばCINT*2などを使うことで少しは手間を減らせるかもしれませんが）。

そういった時、類似した機能が使えるコマンド、というのは結構便利です。たとえばちょっとした整数値の十六進表記を確認したい時には、

$ printf '%x\n' 12345
3039

といった感じです。

多機能なlibcの関数のひとつに、strftime（ http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html ）があります。そして、普通にドキュメントを読んだだけではいったいなんのことやらよくわからない、「 %G と %V 」「 %W と %u 」「 %U と %w 」という、あまりメジャーでないフォーマット文字列があります*3。

以前、dateコマンドの機能を使ってあれこれと実例を試して確認したことがあるのですが（ http://ksmakoto.hatenadiary.com/entry/2014/10/12/132048 ）、実はこのような実験に必要な、任意の時刻を指定してその時刻の文字列表示を得るためのdateコマンドの機能は、POSIXでは全く決められていません（ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html を見ればわかる通り -u オプションと、フォーマット文字列を指定する、という引数しか標準にはない）。後から指摘されたのですが、特に何かうまい代替手段も無さそうだったので、記事には注意書きを追加したのみです。

これはPOSIXを追求しなかった例、という話でした。

bcコマンドの曖昧なエラー対処

本題とは無関係ですが、私はMacr055*4というテキストマクロプロセッサを作っています。M4という標準的な（POSIXにもあります http://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html ）マクロプロセッサではevalという組込みマクロで四則演算などの算術式の計算ができるので、同様の機能を実装したのですが、自分で実装するのは面倒だったので、外部のbcコマンドを利用することにしました。

算術式の計算は、ベンチマークに利用するのに便利ですから、あまり重いのも嫌です。そんなわけでbcには、標準入力から入力を得て逐次その結果を標準出力に吐くモードがありますから、それを利用しました。

処理対象が数式なのですから、ゼロ除算のような意味的エラーは別としても、構文エラーに対してはエラーを検出したいものです。そして、bcがそのようなエラーを検出した時、そのメッセージが標準出力に出力されるのか、標準エラー出力に出力されるのか、実装によってまちまちになっています。手元で確認したところでは、FreeBSDのベースシステムに入っているbcはstdoutに、GNU bc（ https://www.gnu.org/software/bc/ ）はstderrに吐いてきます。

これは困った、ということでPOSIXで確認（ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/bc.html ）したところ、この点に関して明示が意図的に存在しないような（としか思えない）書き方になっている、ということを見つけました。

上から順番に関係しそうなものを見てゆきます。まず STDOUT の節には、「正常の場合の出力」のことのみが書いてあります。次の STDERR の節では「shall be used only for diagnostic messages」とあります。ここで「diagnostic messages」とあるのは何か、ということになりそうです。

その後は、bcが処理できる言語の仕様が書かれた EXTENDED DESCRIPTION の節が長く続いた後、最後にわずかにエラーに触れた記述があります。

CONSEQUENCES OF ERRORS の節の1つ目の段落で、引数で指定された名前のファイルにアクセスできなければ「diagnostic message」をstderrに吐け、とあるので、前述の STDERR の節で出力されるとされているのは、こちらのエラーのみということになりそうです。

次の段落の記述が問題の、入力中のエラーについて触れている所ですが、「インタラクティブな起動中は should print an error message」とのみあります。それをstderrに吐くべきかstdoutに吐くべきか、を示すような情報はどこにもありませんし、「should」ですから、絶対にそうしなければならないわけではない、ということでもあります。また EXIT STATUS についても、0 になるのは「All input files were processed successfully.」とあって、標準入力からの入力についてはやはりボカしているような感じがあります。

unexpandコマンドに-tオプションを付けると-aを付けたような挙動が強制抱き合わせになる変な仕様

タブは行頭にだけ使い、expandコマンドとunexpandコマンドで展開したり戻したりすれば、タブ幅の変換は普通はちゃんとできるはずです...が、実際には4タブだと解釈してハードタブ化しようと unexpand -t 4 とすると、なぜか -a オプションを付けていなくても、付けられているかのように動作しろ、と POSIX にはあります（ http://pubs.opengroup.org/onlinepubs/9699919799/utilities/unexpand.html ）。POSIX内で回避する手段は無さそうだったので、GNU版を使って非標準のオプション --first-only で回避しました（この項、思い出したので追記）。

まとめ

そういったわけで、他には、カーネルとのAPIに関してはLKML周辺の人々をウォッチしていれば、やはり時々、「POSIXとのつきあいかた」が見られるような話題を見ることができるでしょう。POSIXは、明確な参照実装が存在したりするような「仕様」とは、違うタイプの「標準」ではないか、と私は捉えています、というのが本稿の結論めいたもの、となるでしょうか。日本語と英語がうまく対応しないのですが、「標準」「規格」「仕様」、「standard」「specification」、それぞれ微妙にニュアンスが違いますし、現実に存在しているものは、たとえば似たように「標準」と銘打っていても、それぞれ違った位置づけだったりするものです。

*1: https://www.opengroup.org/austin/papers/posix_faq.html の「Q0」に対する回答を参照

*2: http://www.hanno.jp/gotom/Cint.html

*3:Rubyの（英語版）rdocが結構詳しくて参考になります http://ruby-doc.org/core-2.3.3/Time.html#method-i-strftime

*4: https://github.com/metanest/macr055

numo-lapack というブロジェクトを作りました（始めました）

numo-lapack というブロジェクトを作りました（始めました）。

Numo::Linalg（ https://github.com/ruby-numo/linalg ）からのフォークをベースに、column-major ←→ row-major 相互の変換をライブラリ側では行わないなど、LAPACKを直接使うのに近い方向性で、早い時期に、多くのLAPACKの関数を利用できる、動く実装を完成させることを目標とする予定です。
現状で、名前等の変更の他、linalgに実装されていた既存メソッドについて新方針で再実装したコードがありますが完全にドラフト版ですので、もし試す方は注意してください（LAPACKの、入力を壊すような関数を使っている場合は、入力のNArrayが壊れる、など）。それと、もしかしたらlinalgと同時にrequireするとどこかが壊れるかもしれません。

2016年11月21日追記

Ruby Associationのほうからアナウンスが出ましたので追記ですが、

こちらのアナウンスにありますように、当プロジェクトは「2016年度Ruby Association開発助成」に応募し、採択されました。約半年弱ですが、ご期待に応える結果を目指します。岸本へのコンタクトは各種可能ですが、多分最も反応が早いのは、SciRuby-JP の Slack からのメッセージになると思います。

同名だが（違う場所にあって）異なるダイナミックリンク（共有）ライブラリの問題（適切な解決法を求む）

FreeBSDにおいて、プログラムの起動時に次のようなエラーで起動に失敗することがあります。

/lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found

（GCC に gcc-4.8 を使っている場合）

原因は、libgcc_s.so.1 として /usr/local/lib/gcc48/libgfortran.so.3 が本来期待している /usr/local/lib/gcc48/libgcc_s.so.1 ではなく、/lib/libgcc_s.so.1 をロードしてしまっていることにあります。

実行ファイルが libgfortran のみに依存していれば、libgfortran.so.3 に埋め込まれている依存性によって正しいライブラリが読み込まれます。

（参考）

$ ldd /usr/local/lib/gcc48/libgfortran.so.3
/usr/local/lib/gcc48/libgfortran.so.3:
	libquadmath.so.0 => /usr/local/lib/gcc48/libquadmath.so.0 (0x801717000)
	libm.so.5 => /lib/libm.so.5 (0x801952000)
	libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x801b7b000)
	libc.so.7 => /lib/libc.so.7 (0x800821000)

しかし、実行ファイル自身が libgcc_s に依存している場合、通常の libgcc_s は /lib/libgcc_s.so.1 ですから、そちらへの依存が優先されてしまい、前述のようなエラーになります。以下のようにして再現できました。

$ cat sample.c
#include <stdio.h>

extern void *__deregister_frame;
extern void *_gfortran_matmul_l4;

int
main(void)
{
  printf("%p\n", __deregister_frame);
  printf("%p\n", _gfortran_matmul_l4);

  return 0;
}

$ cc sample.c -L/usr/local/lib/gcc48 -lgfortran

$ ldd ./a.out
./a.out:
	libgfortran.so.3 => /usr/local/lib/gcc48/libgfortran.so.3 (0x80081f000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800b36000)
	libc.so.7 => /lib/libc.so.7 (0x800d44000)
	libquadmath.so.0 => /usr/local/lib/gcc48/libquadmath.so.0 (0x8010f0000)
	libm.so.5 => /lib/libm.so.5 (0x80132b000)

$ ./a.out
/lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found

一応は「混ぜるな危険」ということであるわけですが（ワークアラウンドとしては LD_LIBRARY_PATH=/usr/local/lib/gcc48 を付ければ一応は動く）、

しかし、可能であれば、それぞれの場所にあるライブラリが別々にロードされるようにすべきかと思います。が、可能でしょうか？

「ISLISPを使うべきでないたった1つの理由」に関して

「ISLISPを使うべきでないたった1つの理由」（ http://d.hatena.ne.jp/Isuzu_T/20130623/1372003378 ）が誤解している点について、簡単にまとめておこうと思います。

要点

上記はてなダイアリーから引用しますが、

マクロは，実行準備時に展開される，いかなる実行時情報も使えない．

仕様にあるこの一文が悲しみです．「実行時情報」が使えないということは，つまり，自分で定義した関数によるマクロの展開は行えない，ということです．なぜなら，関数が定義されるのは，実行時だからです．

ひとつめの引用の、規格票中の文は意訳などではなく、原文（英語）の仕様にもきっちり対応する文がありますので翻訳の問題などではありませんが、もしこのような誤解が多いようであれば削ったほうが良いような気もします。「実行準備」については仕様がある表現ですが、「実行時情報」（runtime information）という表現は仕様の中でここ以外には出てきません。

ユーザーが定義した関数をマクロの定義中で使うことの、このような視点（実行準備と実行）から見た可否については、類推っぽくなりますが、マクロの定義とその使用の関係から考えることができるでしょう。

マクロの展開は全て実行準備時に行われるわけですが、最上位のdefmacro形式によるマクロの定義は実行準備(時)ではなく、実行されて定義されるわけです。ですから、別の箇所でそのマクロが使用されて「実行準備時に展開され」る時に、そのマクロはそれ以前に「defmacro形式が実行されて、定義されたもの」ということになります。

同様にして、マクロの展開関数中で、それ以前にdefun形式により定義されている関数を使用することも問題ないと考えることができるでしょう。以下はこの話題に関するぐだぐだした話です。

その他

規格票中の最初の文と似たような表現が、PCL（『実践 Common Lisp』）中にあります。同書の §8.2 「マクロ展開時 vs. 実行時」に、

　マクロ展開時に動作するコードは実行時とはまったく異なる環境で動作するので、両者の違いを常にしっかりと区別することが大切だ。これはつまり、マクロ展開時は実行時に存在するデータにはアクセスできないってことでもある。（後略）

参考のため原文も見ておくと、

It's important to keep this distinction firmly in mind because code running at macro expansion time runs in a very different environment than code running at runtime. Namely, at macro expansion time, there's no way to access the data that will exist at runtime. (後略)

http://www.gigamonkeys.com/book/macros-defining-your-own.html

ここで言っている「実行時」というのは、そのコード片（式）を含んでいる関数が実引数に適用され評価される時、という意味であって、「実行時に存在するデータ」（the data that will exist at runtime）というのは、式中にあらわれる仮引数の値、といったようなものを指しており、Lispプログラマの常識的にいってごくあたりまえのことを言っているに過ぎません。

なぜほぼ同様の表現なのに、ISLISPの規格票の解釈では、前述のような誤解をもたらしたか、ということを考えるに、おそらくISLISPのミニマリズムに起因する実行モデルの不在ではないかと思います。以下で説明します。

JISの規格票では §1.1 の「適用範囲」の b) 適用外事項 の 3) に

ISLISPテキストを実行準備する方法，及び実行のために準備されたISLISPテキストを起動する方法。

とあり、実行準備→実行というフェーズがどう（いかにして）進行するのか、という点の詳述が範囲外となっています。

そのため、それについての記述は、§1.3 の「オブジェクトは、実行のために準備される (prepared for execution) 。」から始まる段落で述べられている以外には、まとまって存在していませんが、これが原因ではないでしょうか。

ここで、冒頭が「オブジェクトは、」となっていることに注意が必要かと思います。これがもし「ISLISPテキストは、」となっていたら、プログラム全体がまずいっぺんに実行準備され、そして実行される、という意味になるでしょう（つまり、冒頭で引用したような、マクロ中でユーザーが定義した関数が使えない、と考えてしまうことにつながります）。しかし、「オブジェクトは、」となっていますから、ISLISPの「テキスト」（§1.7.37を参照）を構成する個々の「最上位形式」（§1.7.38を参照）について述べているのであって、「最上位形式の並び」は（仕様上は）オブジェクトにはなりませんから、「プログラム全体がまずいっぺんに実行準備され」という解釈は妥当ではない、ということになります。

そういうわけで、仕様では（それぞれの最上位形式に対応する）オブジェクトについて「実行準備され、実行される」ということのみが述べられているということは確認できたとしてよいと思いますが、最後にもう少し、マクロについて考えます。

規格票中の 8. マクロ には、その順序として「マクロは，実行準備の段階で，それを使用する前に定義しなければならない。」とありますが、もしこれに加えるなら、「展開関数中で使用する関数も、そのマクロを使用する前に定義しなければならない。」ということになるかと思います。（あるいはコンパイルの都合を考えると、マクロ定義より前に定義を必須としたほうが良い？）

crubyのFloatにFast inverse square rootを（モンキーパッチで）追加する話

Fast inverse square root自体については「30のプログラミング言語でFast inverse square rootを実装してみました！」（ http://itchyny.hatenablog.com/entry/2016/07/25/100000 ）を参照してください。

せっかくの高速な手法ですから、高速な実装を考えてみます。Rubyの場合、まっとうに実装するのであれば Math モジュールに追加するべきですが、性能のことを考えると関与するオブジェクトが少ないほうが良いですから、Float クラスにモンキーパッチで追加することにしました。

こんな感じになります。

#include <stdint.h>
#include <float.h>
#include "ruby.h"

static VALUE
fast_inv_sqrt(VALUE v)
{
  double d = RFLOAT_VALUE(v);
  if ((d > 0.0) && (d <= DBL_MAX)) {
    //NOP
  } else {
    rb_raise(rb_eFloatDomainError, "out of domain");
  }
  union u_di {
    double d;
    uint64_t i;
  } d_i;
  d_i.d = d;
  d_i.i = 0x5fe6eb50c7b537a8ULL - (d_i.i >> 1);
  double d2 = d / 2.0;
  double g = d_i.d;
  d_i.d = g * (1.5 - d2*g*g);
#if 0
  d_i.i += 0x4e1c39a47a8ULL;
  g = d_i.d;
  d_i.d = g * (1.5 - d2*g*g);
  d_i.i += 0x14b9e8a78ULL;
#endif
  g = d_i.d;
  return DBL2NUM(g);
}

void
Init_fisqrt(void)
{
  rb_define_method(rb_cFloat, "fast_inv_sqrt", fast_inv_sqrt, 0);
}

ポイントとなる点をいくつか説明してゆきます。

まず Init_fisqrt が拡張ライブラリのエントリポイントで、これは見たままかと思います。

関数 fast_inv_sqrt が本体で、最初と最後にある VALUE と double の相互変換は拡張ライブラリの書き方の定番通りです。

続いて引数の範囲チェックですが、浮動小数点数のチェックは「真になる条件」でチェックするのがセオリーです（比較に NaN が関わるると偽になるため）。

ビットパターンを保存した浮動小数点数と整数の変換に union を使っているのも、この手のトリックの定番と言っていいでしょう（標準において、未定義ではなく処理系定義のため、気休め程度だがマシ）。

単精度の時の 0x5f3759df に相当するマジックナンバーは、妥当と思われる方法で私が探索（詳細は略）したものです。

#if 0 でコメントアウトしてある部分は、せっかくなので高精度化を図ってみたコードですが、これがあると **(-0.5) で正確な値を計算するよりも遅くなってしまったのでコメントアウトしました。単にニュートン法をもう1回繰返すだけではなく、誤差で必ず負の側に予測可能な範囲でズレることがわかっているので、それを調整する加算も入れてあります。

続いてベンチマークに使ったスクリプトを示します。

#! /usr/local/bin/ruby23

require 'benchmark'

require_relative 'fisqrt'

a = 1.0

result = Benchmark.realtime {
  (0..10000000).each {|i|
    a.fast_inv_sqrt
    a.fast_inv_sqrt
    a.fast_inv_sqrt
    a.fast_inv_sqrt
    a.fast_inv_sqrt
    a.fast_inv_sqrt
    a.fast_inv_sqrt
    a.fast_inv_sqrt
    a.fast_inv_sqrt
    a.fast_inv_sqrt
  }
}
print "result: #{result}s\n"

result = Benchmark.realtime {
  (0..10000000).each {|i|
    a**(-0.5)
    a**(-0.5)
    a**(-0.5)
    a**(-0.5)
    a**(-0.5)
    a**(-0.5)
    a**(-0.5)
    a**(-0.5)
    a**(-0.5)
    a**(-0.5)
  }
}
print "result: #{result}s\n"

result = Benchmark.realtime {
  (0..10000000).each {|i|
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
    1.0 / Math.sqrt(a)
  }
}
print "result: #{result}s\n"

次のようになります。わずかですが速いという結果が出ています。

result: 6.402902246918529s
result: 7.31780265388079s
result: 9.100973834982142s