Google、ActiveX対抗技術「Native Client」を公開 65
ストーリー by hylom
ActiveXの悪夢、再燃？ 部門より
ActiveXの悪夢、再燃？ 部門より
Googlee 曰く、
Googleが8日、Webブラウザ上でネイティブバイナリコードを実行する「Native Client」を公開した。同様の技術にはInternet Explorerで動作するマイクロソフトのActiveXがあるが、Native ClientはWindowsだけでなくMac OS XやLinuxでも動作するのが特徴。
Native ClientはランタイムとWebブラウザ用のプラグイン、そしてGCCベースのコンパイラから構成されており、SourceForge.JPマガジンによると
セキュリティでは、インナーサンドボックスとよぶソフトウェアコンテナシステムを利用して、静的な分析技術によりネイティブコードモジュールとホストシステム間で意図しないインタラクションの発生を防ぐとのこと。Native Clientは修正BSDライセンスで公開されており、対応プラットフォームはx86版のWindowsおよびMac OS X、Linux。対応ブラウザはFirefoxおよびSafari、Google Chrome、Opera。
オープンソースということで移植などは困難ではないかもしれないものの、ユーザビリティ的にもセキュリティ的にも、プラットフォーム依存のバイナリを動かすということが必要なのだろうか、とタレコミ子は思ってしまうのだが……。
本家コメントより (スコア:5, 参考になる)
- Win, Mac, Linuxで共通の44個のシステムコールを持つ
- 既存のexecutableは使えない。再コンパイルしないといけない。例えばretは安全なものに置き換わる
- GPUは使えない
- 危険なコードはローダによってはじかれる
- call gateを使ってる（・・・trampoline codeとかはよくわからなかった）
- AMDの64bitにx86のセグメントはないのでこの手法は使えない
AVG anti-virus data base out of date
利用できるAPI (スコア:2, 参考になる)
NewlibのC LibとMath Lib
gccのstdc++ Lib
Gecko/MozillaのプラグインAPIであるNPAPIのサブセット
その他
video、audio操作用のBasic Multimedai Interface
NPAPI用の追加機能
ブラウザとのやりとりをするためのSimple RPC
それ以外に組み込みのランタイムコールとしてファイルIOとソケットなんかを提供するようだ。
うーん、結構多いな。サンプルも見てみよう。
脆弱性は？ (スコア:2, すばらしい洞察)
Re:脆弱性は？ (スコア:1, 既出)
x86に縛られるという選択 (スコア:2, 興味深い)
現状それでもどうにかなってしまうほどに、x86アーキテクチャが普及しているからこそできる手段ではありますね
＃考えようによっては、Atomをはじめとする携帯端末向けx86プロセッサを後押しする技術ではあるかも
そうでなくとも携帯端末向けにはARM辺りのネイティブコードでOSを横断・・・といったこと考えられるでしょうが。
Re:x86に縛られるという選択 (スコア:1)
x86 → x86-64 アーキテクチャへの移行途中なのに！
またもや 64bit 普及に歯止めがかかってしまい、OS が 64bit でも IE と IE(32bit) を使い分け続ける状況が続いてしまうような気がします。
それとも 64bit ブラウザから 32bit の Native Client コードを実行できるのでしょうか。
Re:x86に縛られるという選択 (スコア:1)
これ、できそうな気がするんですが。
x86-64は「バイナリレベルで後方互換」とかいってませんでしたっけ。うろ覚えしてるだけなので、あれですが…。
64bitの良さは生かせないけど、制約になるほどのものでもない気がします。
GoogleのブラウザOSの土台作りの布石なんだろう (スコア:2, すばらしい洞察)
ウイルススキャンソフトとかデフラグソフトとか
そういったソフトをブラウザ上で動かすための、
手段を提供するための布石に見える。
段々、Googleが環境を整えてきている感がします。
Re:GoogleのブラウザOSの土台作りの布石なんだろう (スコア:1)
ウィルスチェッカやデフラグソフトなんて興味持ってなさそう。
Re:GoogleのブラウザOSの土台作りの布石なんだろう (スコア:1)
＞ウィルスチェッカやデフラグソフトなんて興味持ってなさそう。
「NativeClient上で、Linux起動成功！」
とかになるんですね。
ブラウザは、単にアプリを起動するためのランチャーとなると
考えると、広域版ファイルマネージャ的なものになることを考えているんでしょうかね。
Re:GoogleのブラウザOSの土台作りの布石なんだろう (スコア:1, 参考になる)
呼んだ？
つ JPC is an x86 PC emulator written entirely in Java.
http://www-jpc.physics.ox.ac.uk/DemoLinux.html [ox.ac.uk]
Re: (スコア:0)
権限昇格の大穴でも開けるつもりなのか知らんが
ウェブブラウザにディスク管理なんかされたら堪らん。
Re: (スコア:0)
片隅 (スコア:2)
これはどうなんだろ。
枯れた技術って何だろうって、最近思います。
誰もが使えて、極一部であってもなじみがある。
最先端は求めない。平易な技術が求められ容易に理解できることこそ重要。
でも、その技術者、ノウハウのベース構築あって次があるのは間違いない。
でも、平易に利用できるという部分で、
今後も求められる技術基礎部分のレベルは上がるが、(たぶん)ユーザーにはよりよい利便性が提供される。
その世界では、基礎技術者向けではないフレームワーク作りの負担が増えて、
難度を上げーの、技術者蟻地獄の悪循環に陥ると。(予想)
# 社会の教科書で時間がないから、近代史全部省かれて、独自で再勉強みたいな。
どう、平易にすれば良いのでしょうね。
皆さんの会社ではどうしているのだろう。そういう技術者教育。
がんばろう。と自分に言い聞かせる。
枯れた技術 (スコア:-100, いいから早く寝ろ) (スコア:1)
・・・「枯れ果てた」ですな。失礼。
イントラでは便利だが (スコア:1, 興味深い)
マルチプラットホームなのが本当に利点となり得るかが疑問だけどね。
うーん (スコア:1)
Windows以外でもOS依存のコードを動かせる、というだけ……？
神社でC#.NET
Re: (スコア:0)
#JAVAは重いし、Flashも広告にやたら使われてて重いしバッテリ食うしウザイし、だからって無効にしたら表示できないサイトが出るし。
Re:うーん (スコア:1, すばらしい洞察)
それだったらNative Client広告に切り替わって同じ悩みが再来するような・・・
Re:うーん (スコア:1, 興味深い)
プラットフォームの一つとしては興味深いし、閉じてないネットワーク上で利用するならどんなサービスが可能かとか面白いかもしれませんね。ついでに、そこに広告を紛れ込ませるならどこまでならOKか、もね。
# Flashも今と昔のものではすっかり違うのに、同じ感覚で
# アニメを要求してくる作成会社とか何とかならんかなι
Re:うーん (スコア:1)
Native ClientがFlash並に普及すればFlash広告並には普及するんじゃないかと。
Re:うーん (スコア:1, 参考になる)
偉大なるx86セグメントの大勝利 (スコア:1, おもしろおかしい)
2.2. A Sandbox in a Sandbox
Native Client is built around an x86-specific intra-process
“inner-sandbox.” We believe that the inner-sandbox is robust;
regardless, to provide defense in depth [12], [15]
we are also developing a second “outer-sandbox” that
implements isolation at the process boundary.
The inner-sandbox uses static analysis to detect security
defects in untrusted x86 code. Previously, such analysis
has been challenging for arbitrary x86 code due to such
practices as self-modifying code and overlapping instructions.
In Native Client we disallow such practices through
a set of alignment and structural rules that, when observed,
insure that the native code module can be disassembled
reliably, such that all reachable instructions are identified
during disassembly. With reliable disassembly as a tool, our
validator can then insure that the executable includes only
the subset of legal instructions, disallowing unsafe machine
instructions.
The inner-sandbox further uses x86 segmented memory
to constrain both data and instruction memory references.
Leveraging existing hardware to implement these range
checks greatly simplifies the runtime checks required to
constrain memory references, in turn reducing the performance
impact of safety mechanisms.
Re:偉大なるx86セグメントの大勝利 (スコア:1, 興味深い)
内部表現が関数アドレスじゃなくなってたりして。
誰か調べて教えてたもれ。
Re:偉大なるx86セグメントの大勝利 (スコア:1)
Javaでもx86コードを実行できる(JNIではなくx86コードを理解するライブラリがある)ので、発想としてはそんな感じ？？
---
2.2.サンドボックス内サンドボックス
Native Clientはx86特有の内部のプロセス"インナーサンドボックス"に構築されます。
インナーサンドボックスは堅牢であると信じています。とにかく、徹底的な防御を提供するため、プロセス境界の分離を実装する第2の"アウターサンドボックス"も開発しました。
インナーサンドボックスは、信頼できないx86コードにおいて、セキュリティーの問題を検出するために静的解析を利用します。
以前から、このような解析は自己書き換えコードやオーバーラップ命令といったような慣習による不定なx86コードを課題としてきました。
Native Client では、このような慣習を認めず、アラインメントと構造的なルールのセットを通し、それらが観測されたときは、ネイティブコードモジュールは信頼できるようにディスアセンブルされ、ディスアセンブルをする間に全ての到達可能な命令が特定されることを保証します。
信頼できるディスアセンブリにより、私たちのバリデータは、実行可能コードは許可された命令のサブセットだけを含み、安全ではないマシン命令を禁止することを保証することができます。
インナーサンドボックスはさらに、データと命令のメモリ参照の両方に制約を与えるため、x86のセグメント化されたメモリを使います。
これらの範囲チェックを実装するために既存のハードウェアを活用することで、メモリ参照に制約を与えるために必要な実行時チェックを大いに簡素化し安全機構のパフォーマンスへの影響を減らします。
Re:偉大なるx86セグメントの大勝利 (スコア:1)
Re:偉大なるx86セグメントの大勝利 (スコア:1)
NtQueryInformationProcess は documented ですが、
その (Native Client における) 使用方法が undocumented です。
具体的には、NtQueryInformationProcess の第2引数に undocumented な
ProcessLdtInformation (= 10) を渡しています。
gCPUの前準備か？ (スコア:1)
ブラウザ専用かつオープン仕様なＣＰＵ。汎用でなく高価でなくどの半導体メーカでも作れるＣＰＵ。
みんなでコードを書けば必要十分な命令体系が見えてくる。
Native Code?Client? (スコア:0)
Re:Native Code?Client? (スコア:3, 参考になる)
実はこれってアリなんじゃないかなぁ、と思います。Javaと比べてみると、最大のデメリットは、サーバー側のバイナリの量が増えることですが、オーサリングソフトがしっかりしていれば、あまり負担にはなりませんよね。ソース1つで[プラットフォーム数]倍のバイナリを吐くだけですし。実質的なダメージは、サーバーにおける容量に相当するもの(+キャッシュ)だけです。しかし、転送時は1ページビューにつき送る量は増えないどころか、むしろ減るので、現実的にはあまり負担になるとは思えません。そういう意味では、ユーザーにもウェブ開発者にもメリットがある方式ではないでしょうか。
強いて言うなら、UAがプラットフォームの申告を偽った時におかしくなるくらいですが、GMailのようなAJAXは既にプラットフォームごとに違うスクリプトを送り込むことを余儀なくされているわけで、それに比べれば、まだマシというか、なんというか、きっちり動いてくれそうな気がします。ただ、いくらオープンソースでも、オーサリング(ウェブ開発者)が対応するプラットフォームを決めるわけですから、マイナーなOS/CPUは辛いですね。JavaやFlashと違って、単に移植できたから万歳というわけには行きません。それとも、ここへさらに仮想環境を咬ませるような複雑な時代へ突入するのでしょうか……
Re:Native Code?Client? (スコア:2, 参考になる)
プラットフォームという言葉はCPU、ハードウェア、OSを含む言葉なので
誤解#1471137 [srad.jp]を招いていると思います
CPU(x86)依存だがOS非依存なバイナリというべきでしょう。
ちなみにX Window Systemのグラフィックドライバや拡張機能も同様です。
(コレと違って安全性チェックはありませんが)
Re:Native Code?Client? (スコア:1)
>完全にプラットフォーム依存なバイナリを送る
という点ですが
「Windowsでも、scons-out/nacl以下は同じで、Macと同様にFirefoxで問題なく表示できてますので、同一html/nexeでポータビリティありそうなのが確認できました.」
http://b.hatena.ne.jp/takuma104/20081209#bookmark-11220424 [hatena.ne.jp]
「takuma104さんのブコメ(引用者注：上の文章)によると、同じバイナリ (ELF フォーマット) が Mac でも Windows でもそのまま動いたとのこと。3.2 で書かれている、セキュア ELF ローダ (sel_ldr) とその先にあるランタイムで、プラットフォーム間の差異を吸収しているのでしょう。」
http://blog.deadbeaf.org/2008/12/09/google-native-client/ [deadbeaf.org]
という指摘がありますので「完全にプラットフォーム依存」なバイナリを送るものの、それを実行できないはずの環境でも「中間生成コード」のようになんとかして実行しちゃう技術なんでしょうか…？
とりあえず、いいたかったのは、どうもバイナリも(主要部分は)共通らしいということなんですが。
(でもランタイムみたいなものはやっぱりOSの数だけバリエーションかできるのか…。)
たしかに、x86マシン同士ではOSなどが異なっていても、同じことをするプログラムなら、マシン語レベルでも変わらない部分があるはずなので、その差さえ上手く吸収すれば動いちゃうってことなんでしょうけど。本気で、それを考えることがすごい。(で、それが正直どうなってるのか、いまいち分からないんですが…。)
でもこれ、趣味で「使ってみよう」というようなレベルでは、Javaとの違いは、NaClのが多少速いかもということと、書くとき使えるのがC/C++だということ、ぐらいでしょうか。
Re:Native Code?Client? (スコア:1, 参考になる)
そのミニOS上のx86バイナリが共通だということです。
アイデアとしてはJavaからはっきり後退しているんですけども。
> でもこれ、趣味で「使ってみよう」というようなレベルでは、Javaとの違いは、NaClのが多少速いかもということと、書くとき使えるのがC/C++だということ、ぐらいでしょうか。
その通りですが、APIもリッチのようです。
Javaがクロスプラットフォームな中間生成コードを (スコア:0)
Re: (スコア:0)
意味がわかりません。実行環境がクロスプラットフォームなものって何ですか？
Re: (スコア:0)
Re:Native Code?Client? (スコア:1)
オープンソースなのにデモというのは (スコア:0)
Re:オープンソースなのにデモというのは (スコア:1, 参考になる)
アルファ -> ベータ -> RC -> リリース
Google
デモ -> アルファ(Google labの状態) -> 永遠のベータ
MS 参考 [srad.jp]
アルファ -> ベータ -> RC -> エスクロー -> リリース
Re:オープンソースなのにデモというのは (スコア:1)
[注意]コメント主は大変叩かれ弱い性質です。優しく接してあげて下さい
～おもしろおかしい以外に興味はありません～
意図しないインタラクション (スコア:0)
> 析技術によりネイティブコードモジュールとホストシステム間で意図しないインタラクションの発生を防
> ぐ
実行前デバッガー？
# ちがうって…
昔からあった (スコア:0)
Re:昔からあった (スコア:1)
「ネイティブコードとコンパイラを同梱して配布すれば
仮想マシン使わなくてもプラットフォームに関係なく実行できるんじゃね？
やべぇ俺天才」
とか思ってましたけど、そら誰でも思いつきますよね、っていう
Re:昔からあった (スコア:1, おもしろおかしい)
今さら何を… (スコア:0)
Re:今さら何を… (スコア:5, 興味深い)
Google の真の competitor は、MS ではなく Adobe なのでは
ないかと思う今日このごろ。
Re:今さら何を… (スコア:3, 参考になる)
大きな違いなはずです。
Native Clientはどうかとういうと、
mootoh.log - Native Client [deadbeaf.org]
をみてみると、やっぱしActiveXに近いような気がします。
酔っぱらいでイキオイで投稿したので、間違ってても許してね
Re:今さら何を… (スコア:1, 興味深い)
似たようなもんだからどれにも似てるのはしかたないな
Re: (スコア:0)
何か変な感じだ・・・ (スコア:0)
JNLP使えば、ブラウザの足かせから解放されるよ〜
# まぁ、ブラウザはむしろ今は足かせと言うより
# 使い込んだ靴みたいなものか