vdsoとvsyscallとは何ですか？

やった sudo cat /proc/1/maps -vv

出力を理解しようとしています。予想どおり、多くの共有ライブラリがメモリマッピングセグメントにマッピングされているのがわかります。

7f3c00137000-7f3c00179000 r-xp 00000000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c00179000-7f3c00379000 ---p 00042000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c00379000-7f3c0037a000 r--p 00042000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c0037a000-7f3c0037b000 rw-p 00043000 08:01 21233923                   /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8
7f3c0037b000-7f3c00383000 r-xp 00000000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00383000-7f3c00583000 ---p 00008000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00583000-7f3c00584000 r--p 00008000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00584000-7f3c00585000 rw-p 00009000 08:01 21237216                   /lib/x86_64-linux-gnu/libnih-dbus.so.1.0.0
7f3c00585000-7f3c0059b000 r-xp 00000000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0
7f3c0059b000-7f3c0079b000 ---p 00016000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0
7f3c0079b000-7f3c0079c000 r--p 00016000 08:01 21237220                   /lib/x86_64-linux-gnu/libnih.so.1.0.0

終わりに向かってのようなものがあります

7f3c0165b000-7f3c0177e000 rw-p 00000000 00:00 0                          [heap]
7fff97863000-7fff97884000 rw-p 00000000 00:00 0                          [stack]
7fff97945000-7fff97946000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

どういうないvdsoとvsyscall意味ですか？vsyscallはメモリのカーネル部分ですか？誰かがこの問題に光を当てることができれば素晴らしいと思います。

vsyscallとVDSOセグメントは、Linuxにおける特定のシステムコールを促進するために使用される二つのメカニズムです。たとえば、gettimeofdayは通常、このメカニズムを介して呼び出されます。導入された最初のメカニズムはvsyscallでした。これは、システムコールのオーバーヘッドを削減するために、実行するために実際のレベルの特権を必要としない特定のシステムコールを実行する方法として追加されました。前の例gettimeofdayに従う必要があるのは、カーネルの現在の時刻を読み取ることだけです。gettimeofday頻繁に呼び出す（タイムスタンプを生成するなど）アプリケーションがあり、少しでもオーバーヘッドを気にします。この懸念に対処するために、カーネルは現在の時刻と高速を含むページをユーザースペースにマップしますgettimeofday実装（つまり、vsyscallに節約された時間を読み取る関数）。この仮想システムコールを使用すると、Cライブラリはgettimeofday、従来のシステムコールモデルINT 0x80またはによって通常導入されるカーネルスペースとユーザースペースの間のコンテキストスイッチによって導入されるオーバーヘッドのない高速を提供できますSYSCALL。

ただし、このvsyscallメカニズムにはいくつかの制限があります。割り当てられるメモリは小さく、4つのシステムコールしか許可されません。さらに重要で深刻なのは、vsyscallページの場所が次のようになっているため、vsyscallページが各プロセスの同じアドレスに静的に割り当てられることです。カーネルABIに釘付け。vsyscallのこの静的な割り当ては、Linuxで一般的に使用されるメモリ空間のランダム化によってもたらされる利点を損ないます。攻撃者は、スタックオーバーフローを悪用してアプリケーションを侵害した後、vsyscallからシステムコールを呼び出すことができます。任意のパラメータを持つページ。彼に必要なのはシステムコールのアドレスだけです。これは静的に割り当てられているため簡単に予測できます（異なるアプリケーションでもコマンドを再実行しようとすると、vsyscallのアドレスが変更されないことがわかります）。このタイプの攻撃を阻止するには、vsyscallページの場所を削除するか、少なくともランダム化するとよいでしょう。残念ながら、アプリケーションはそのページの存在と正確なアドレスに依存しているため、何もできません。

このセキュリティの問題は、固定アドレスのすべてのシステムコール命令を特別なトラップ命令に置き換えることで対処されています。vsyscallページを呼び出そうとするアプリケーションは、カーネルにトラップし、カーネル空間で目的の仮想システムコールをエミュレートします。その結果、最初にカーネルシステムコールを回避するためにそこに配置された仮想システムコールをエミュレートするカーネルシステムコールが作成されます。その結果、vsyscallの実行に時間がかかりますが、重要なことに、既存のABIが破損することはありません。アプリケーションが使用しようとしている場合はいずれの場合も、景気減速にのみ見られますvsyscallの代わりにページをVDSO。

VDSOは、その限界を克服しながら、vsyscallと同じ機能を提供しています。vDSO（仮想動的リンク共有オブジェクト）は、ユーザースペースに割り当てられたメモリ領域であり、ユーザースペースの一部のカーネル機能を安全な方法で公開します。これは、によって引き起こされるセキュリティの脅威を解決するために導入されましたvsyscall。vDSOは動的に割り当てられるため、セキュリティ上の懸念が解決され、4つを超えるシステムコールを実行できます。VDSOのリンクはglibcライブラリを介して提供されています。リンカは、そのようなルーチンに。などのvDSOバージョンが付随している場合、glibcvDSO機能にリンクします。プログラムの実行時、カーネルにvDSOがない場合gettimeofday サポート、従来のシステムコールが行われます。

クレジットと便利なリンク：

• 素晴らしいチュートリアル、独自のvDSOを作成する方法。
• vsyscallとvDSO、素晴らしい記事
• 役立つ記事とリンク
• linux-gate.so.1とは何ですか？

これを新しいカーネルに追加したいのですvDSOが、これは「安全な」システムコールだけでなく、システムでシステムコールを呼び出すのに適したシステムコールメカニズムを決定するために使用されます。