ヨタの日々

_ 読書

2010年5月24日 - 2010年5月30日の読書メーター
読んだ本の数：1冊
読んだページ数：227ページ

聖剣の刀鍛冶<9>(MF文庫J)
「あああっ どうしたらいいのさ？」アリアのマイペースのような感じが好きだ
読了日：05月30日 著者：三浦 勇雄

読書メーター

_ [静的リンク][スタティックリンク][static link]Static Linking Considered Harmful

( via めもがき )

あたしゃ今時full static linked rootに拘るのは20世紀だよねキャハハちゅーナウなヤングのでOpenBSD向けにこれ以上新しい作業する気はナッシングですが。ここは珍しいことに 例の人と意見が一致している。

ということで翻訳練習してみる。直訳のようになるなあ。

Static Linking Considered Harmful

スタティックリンクは有害だと思う

There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. Here are a few reasons why dynamic linking is superior:

あまりにも多くのひとびとがスタティックリンクが有益だと思っている( または主張さえする )。それはこれまでも、今後も本当のことではない。なぜダイナミックリンクが優れているのか、その理由を 2,3 示す:

fixes (either security or only bug) have to be applied to only one place: the new DSO(s). If various applications are linked statically, all of them would have to be relinked. By the time the problem is discovered the sysadmin usually forgot which apps are built with the problematic library. I consider this alone (together with the next one) to be the killer arguments.

(ダイナミックリンクなら)フィックスを適用しなければいけないのは一箇所だけ、つまり新しい DSO (を用意する)だけである。様々なアプリケーションがスタティックリンクされてるならば、すべて再リンクしなおさなければならない。問題が発見されたときになると、システム管理者はどのアプリケーションが問題のライブラリを使って構築されているのか忘れてしまう。これ (と次の論点) だけで、(スタティックリンクを捨てるのに) 十分な論拠だと思う。

Security measures like load address randomization cannot be used. With statically linked applications, only the stack and heap address can be randomized. All text has a fixed address in all invocations. With dynamically linked applications, the kernel has the ability to load all DSOs at arbitrary addresses, independent from each other. In case the application is built as a position independent executable (PIE) even this code can be loaded at random addresses. Fixed addresses (or even only fixed offsets) are the dreams of attackers. And no, it is not possible in general to generate PIEs with static linking. On IA-32 it is possible to use code compiled without -fpic and -fpie in PIEs (although with a cost) but this is not true for other architectures, including x86-64.

セキュリティ対策のようにランダムなロードアドレスは使えない。スタティックリンクされたアプリケーションは、スタック領域とヒープ領域だけがランダムに出来る。すべてのテキスト領域は固定アドレスになる。ダイナミックリンクされたアプリケーションは、カーネルは互いに独立している任意のアドレスですべての DSOs をロード出来る。この場合、アプリケーションはランダムアドレスでロード可能な実行可能( PIE )なコードとしてビルドできる。固定アドレス( または固定のオフセットでさえ ) は攻撃者の標的です。一般的に、スタティックリンクでは PIE を生成することは不可能だ。IA-32 では -fpic と -pie 無しで PIE をコンパイルすれば可能だ( コストかかるけど )。しかし他のアーキテクチャ( x86-64 を含む )ではその手段は使えない。

more efficient use of physical memory. All processes share the same physical pages for the code in the DSOs. With prelinking startup times for dynamically linked code is as good as that of statically linked code.

物理メモリのより効率的な使用法。すべてのプロセスは DSOs 内にある物理ページのコードを共有する。スタートアップをプレリンクされたダイナミックリンクコードは、スタティックリンクコードと同じくらいよいです。

all kinds of features in the libc (locale (through iconv), NSS, IDN, ...) require dynamic linking to load the appropriate external code. We have very limited support for doing this in statically linked code. But it requires that the dynamically loaded modules available at runtime must come from the same glibc version as the code linked into the application. And it is completely unsupported to dynamically load DSOs this way which are not part of glibc. Shipping all the dependencies goes completely against the "advantage" of static linking people site: that shipping one binary is enough to make it work everywhere.

libc のありとあらゆる特徴( locale ( iconv を通して )、NSS、IDN、...） は適切な外部コードをロードするためにダイナミックリンクが要求される。我々は、スタティックリンクされたコードでこうすることに対する非常に限られたサポートをする。しかし、それはダイナミックリンクモジュールを実行時に利用するときに、コードがアプリケーションとリンクしたのと同じ glibc バージョンをによるものでなければならないことを要求する。そして、このように glibc の一部でない DSO をダイナミックにロードすることは完全にサポートされていない。依存するものをすべてまとめて配布することは、スタティックリンク推進者の言う「利点」に真っ向から反している。彼らはこう言う: 「バイナリを 1 つ配布するだけで、どこでも動作する」

Related, trivial NSS modules can be used from statically linked apps directly. If they require extensive dependencies (like the LDAP NSS module, not part of glibc proper) this will likely not work. And since the selection of the NSS modules is up the the person deploying the code (not the developer), it is not possible to make the assumption that these kind of modules are not used.

関連して、ちっぽけな NSS モジュールならスタティックリンクされたアプリケーションから直接使うことができます。彼らが広い依存関係（ LDAP NSSモジュール( 本来の glibc の一部でない ) のように )を必要とするならば、これはたぶん動かない。そして、NSS モジュールの選択権は (開発者ではなく) デプロイする人にあるので、この種のモジュールが使われないと仮定することはできない。

no accidental violation of the (L)GPL. Should a program which is statically linked be given to a third party, it is necessary to provide the possibility to regenerate the program code.

過失による (L)GPLの違反がない。スタティックリンクされたプログラムをサードパーティへ与えるなら、プログラムコードを再構築できるようにしておく必要があるのだ。

tools and hacks like ltrace, LD_PRELOAD, LD_PROFILE, LD_AUDIT don't work. These can be effective debugging and profiling, especially for remote debugging where the user cannot be trusted with doing complex debugging work.

ltrace、LD_PRELOAD、LD_PROFILE、LD_AUDITのようなツールとハックは出来ない。特にユーザーが複雑なデバッグ作業を任せられないようなときにリモートデバッグとして、これらは効果的なデバッグ作業とプロファイリングになる。

There are certainly more reasons. The often used argument about statically linked apps being more portable (i.e., can be copied to other systems and simply used since there are no dependencies) is not true since every non-trivial program needs dynamic linking at least for one of the reasons mentioned above. And dynamic linking kills the portability of statically linked apps.

もちろんより多くの理由がある。しばしば使われる、スタティックリンクされたアプリケーションはよりポータブルだ( たとえば、他のシステムへコピーできるし、依存関係がない ) という理由は、些細ではないプログラムにとってこれまで挙げた理由のうちの少なくとも 1 つの理由のためにダイナミックリンクが必要なので真ではない。そして、ダイナミックリンクはスタティックリンクアプリケーションのポータビリティを生かせない。

Conclusion: Never use static linking!

結論: スタティックリンクを使ってはいけない!

_ [リッジレーサー7]リッジレーサー7

オンラインバトルなど。NANAKI が速すぎる。誰のサブアカなのか

• 走行距離 86191 km
• RSGP 進行度 100.0 %
• 名声 23291 FP
• オンラインバトル勝利数 859/3144

_ ○活

業務時間外に活動しようという話題がどうのこうの。その活動が業務なのか趣味なのか。業務ならやらない。趣味ならやる。

業務( 工数がかかる行為 )をおこなうことについては業務時間なのだから工数が発生するし朝早く会社に来るなどして作業するとたしかに誰も居ない効率的なのだけど勤務時間をシフトできないならばそれはできないしカネを貰えないのに作業してもそれはサービス残業と同じだし勤務時間より早い時間は残業として認められないのでオレはやる気はまったく起きない。これっぽっちも。

趣味ならやる。翻訳したり Python のコードを写経したり本読んだり。

昔「○勝ファミコン」という雑誌があったなあ

_ きゅうけい!!

＠喫茶店

LPIC 201 模擬試験1回目 24点

_ 飯

蔵で飯

チャイナdayということで釣られてみた。やはりこの店は落ち着くなあ