page0050
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
開始行:
* OSECPUのセキュリティ
-(by [[K]], 2013.07.08)
** (1) 一般的なセキュリティ
-OSECPUはASLRがいらない（そんなことしなくても守りきれる）
--だからアドレス空間が少ししかなくても問題ない
--ページングをサポートしていないCPUでも平気
-OSECPUはNX-bitとかセグメンテーションによるハードウェア保...
--これらの機能を持たない幅広いCPUに対応可能
--LMEM/SMEM命令のポインタに対する自動チェックが、これらを...
-OSECPUには特権モードがない
--それでもシステムはアプリに対してデータを隠せる、隠した...
---隠したまま渡す = ハンドルとしての使い道（システムから...
--逆にアプリはシステムに対してデータを隠すことができる、...
--この特権モードがないという設計によって、rootを取りに行...
-OSECPUではuse-after-free脆弱性が発生しない
--指している先のメモリがfreeされると、自動的にポインタが...
--同じ仕組みによって、double-free脆弱性も発生しない
-OSECPUの無限ループ対策
--ウォッチドッグタイマーなどは不要
-関連：[[page0018]]
** (2) （川合の考える）拡張されたセキュリティ
-たとえばバッファオーバーラン脆弱性があったとして、プログ...
-こういうのを早期に（＝開発中に）誰かが教えてくれたら、こ...
-となれば、もしもそういう便利機能があれば、それは十分に立...
-これをさらに発展させて、ユーザやプログラマが不便な思いを...
--というか、そういうふうにしていかないと、セキュアなOSな...
** (3) ガーベージコレクション方式 vs free方式
-これをここで少し議論しようと思う。
-まずアプリのサイズを考えると、実はGC方式の方が有利である...
-なぜか？GC方式には欠点があるからだ。定期的にポインタを精...
-僕は以前Javaで大量のオブジェクトを作っては捨て、作っては...
-僕はどのオブジェクトが必要で、どのオブジェクトが不要なの...
-ということで、OSECPUではGC方式を採用しないことにした。自...
--註：僕はJavaのGCに楽をさせるためのテクニックなども知っ...
-OSECPUではfree方式を採用したものの、もちろんそれにともな...
-しかしまあ、リークしてしまったメモリに対して、このメモリ...
** (4) ユーザはどこまでOSに頼っていいのか。どこからは自分...
-ということを考えてみたメモ：
-アプリ開発者の視点：
--(1-1) OSECPUは幅広いCPUとOSに対応可能なので、一度作った...
---つまり移植に関してはOS任せにしてしまっていい。
--(1-2) ガーベージコレクト方式を採用していないので、メモ...
---解放タイミングを間違えたことによるバグについて、use-af...
--(1-3) あるアプリが他のアプリのワークエリアなどをバグで...
---x86ではこんなことはもはや当たり前で、何をいまさらと思...
--(1-4) たとえば32bitのintで利用しているメモリに対して、1...
---もっと一般的に言えば、異なる型でアクセスする行為がすべ...
--(1-5) たとえばT_UINT8なメモリに対して、-1を書き込むこと...
---そのような場合、おそらくこのメモリを読みだせば255が返...
---速度低減と引き換えにしてでも、これのチェックを入れて、...
---とにかく現状では、この手のバグについては人間が気にする...
--(1-6) コードの一部を自らのバグによって改変してしまって...
---一部でも実行されはじめたコードはその後どの部分も変更さ...
-アプリ利用者の視点：
--(2-1) ユーザは信用できるアプリと信用できないアプリを区...
---自分が作ったアプリは基本的に信用できるだろう。ソースコ...
---しかしそれ以外の物はすべて信用するべきではない。
---この区別を何度もやるのはきっと大変なので、何か設定ファ...
--(2-2) 信用できないアプリには、壊されては困るようなデー...
--(a) 悪意あるソフトウェアはユーザの大事なデータを壊した...
--(b) 悪意あるソフトウェアはユーザのシステムを破壊したい。
--(c) 悪意あるソフトウェアはユーザの大事なデータを盗みた...
--この3点への対策が重要となりそう。
--(b)に関しては、アプリがシステムや他のアプリへの干渉や設...
--(a)に関しては、アプリがファイルへのライトアクセスをする...
* こめんと欄
#comment
終了行:
* OSECPUのセキュリティ
-(by [[K]], 2013.07.08)
** (1) 一般的なセキュリティ
-OSECPUはASLRがいらない（そんなことしなくても守りきれる）
--だからアドレス空間が少ししかなくても問題ない
--ページングをサポートしていないCPUでも平気
-OSECPUはNX-bitとかセグメンテーションによるハードウェア保...
--これらの機能を持たない幅広いCPUに対応可能
--LMEM/SMEM命令のポインタに対する自動チェックが、これらを...
-OSECPUには特権モードがない
--それでもシステムはアプリに対してデータを隠せる、隠した...
---隠したまま渡す = ハンドルとしての使い道（システムから...
--逆にアプリはシステムに対してデータを隠すことができる、...
--この特権モードがないという設計によって、rootを取りに行...
-OSECPUではuse-after-free脆弱性が発生しない
--指している先のメモリがfreeされると、自動的にポインタが...
--同じ仕組みによって、double-free脆弱性も発生しない
-OSECPUの無限ループ対策
--ウォッチドッグタイマーなどは不要
-関連：[[page0018]]
** (2) （川合の考える）拡張されたセキュリティ
-たとえばバッファオーバーラン脆弱性があったとして、プログ...
-こういうのを早期に（＝開発中に）誰かが教えてくれたら、こ...
-となれば、もしもそういう便利機能があれば、それは十分に立...
-これをさらに発展させて、ユーザやプログラマが不便な思いを...
--というか、そういうふうにしていかないと、セキュアなOSな...
** (3) ガーベージコレクション方式 vs free方式
-これをここで少し議論しようと思う。
-まずアプリのサイズを考えると、実はGC方式の方が有利である...
-なぜか？GC方式には欠点があるからだ。定期的にポインタを精...
-僕は以前Javaで大量のオブジェクトを作っては捨て、作っては...
-僕はどのオブジェクトが必要で、どのオブジェクトが不要なの...
-ということで、OSECPUではGC方式を採用しないことにした。自...
--註：僕はJavaのGCに楽をさせるためのテクニックなども知っ...
-OSECPUではfree方式を採用したものの、もちろんそれにともな...
-しかしまあ、リークしてしまったメモリに対して、このメモリ...
** (4) ユーザはどこまでOSに頼っていいのか。どこからは自分...
-ということを考えてみたメモ：
-アプリ開発者の視点：
--(1-1) OSECPUは幅広いCPUとOSに対応可能なので、一度作った...
---つまり移植に関してはOS任せにしてしまっていい。
--(1-2) ガーベージコレクト方式を採用していないので、メモ...
---解放タイミングを間違えたことによるバグについて、use-af...
--(1-3) あるアプリが他のアプリのワークエリアなどをバグで...
---x86ではこんなことはもはや当たり前で、何をいまさらと思...
--(1-4) たとえば32bitのintで利用しているメモリに対して、1...
---もっと一般的に言えば、異なる型でアクセスする行為がすべ...
--(1-5) たとえばT_UINT8なメモリに対して、-1を書き込むこと...
---そのような場合、おそらくこのメモリを読みだせば255が返...
---速度低減と引き換えにしてでも、これのチェックを入れて、...
---とにかく現状では、この手のバグについては人間が気にする...
--(1-6) コードの一部を自らのバグによって改変してしまって...
---一部でも実行されはじめたコードはその後どの部分も変更さ...
-アプリ利用者の視点：
--(2-1) ユーザは信用できるアプリと信用できないアプリを区...
---自分が作ったアプリは基本的に信用できるだろう。ソースコ...
---しかしそれ以外の物はすべて信用するべきではない。
---この区別を何度もやるのはきっと大変なので、何か設定ファ...
--(2-2) 信用できないアプリには、壊されては困るようなデー...
--(a) 悪意あるソフトウェアはユーザの大事なデータを壊した...
--(b) 悪意あるソフトウェアはユーザのシステムを破壊したい。
--(c) 悪意あるソフトウェアはユーザの大事なデータを盗みた...
--この3点への対策が重要となりそう。
--(b)に関しては、アプリがシステムや他のアプリへの干渉や設...
--(a)に関しては、アプリがファイルへのライトアクセスをする...
* こめんと欄
#comment
ページ名:
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
