プログラムで使用可能なメモリを制限する

私はどういうわけか、1 MBの利用可能なメモリで100万の整数をソートするタスクに取り組むことにしました。 しかし、その前に、プログラムで使用可能なメモリの量を制限する方法を考えなければなりませんでした。 それが私が思いついたものです。

プロセス仮想メモリ

メモリを制限するさまざまな方法に突入する前に、プロセスの仮想メモリがどのように機能するかを知る必要があります。 このトピックに関する最良の記事は、 「メモリ内のプログラムの構造」です。

この記事を読んだ後、メモリを制限するための2つのオプションを提供できます。仮想アドレススペースを削減するか、ヒープボリュームを削減します。

最初：アドレス空間の量を減らす。 それは非常に単純ですが、完全に正しいわけではありません。 すべてのスペースを1 MBに減らすことはできません-カーネルとライブラリーに十分なスペースがありません。

2番目：ヒープのボリュームを減らします。 これはそれほど簡単ではなく、通常は誰も行いません。これは、リンカを使用した大騒ぎを通じてしか利用できないためです。 しかし、私たちのタスクにとって、これはより適切なオプションです。

また、ライブラリおよびシステムコールをインターセプトしてメモリ使用量を追跡したり、サンドボックスをエミュレートおよび導入してプログラム環境を変更するなど、他の方法も検討します。

テストのために、big_allocと呼ばれる小さなプログラムを使用します。このプログラムは、100 MiBを配置してからリリースします。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <stdbool.h> // 1000   100 KiB = 100 000 KiB = 100 MiB #define NALLOCS 1000 #define ALLOC_SIZE 1024*100 // 100 KiB int main(int argc, const char *argv[]) { int i = 0; int **pp; bool failed = false; pp = malloc(NALLOCS * sizeof(int *)); for(i = 0; i < NALLOCS; i++) { pp[i] = malloc(ALLOC_SIZE); if (!pp[i]) { perror("malloc"); printf("  %d \n", i); failed = true; break; } //     ,   copy-on-write. memset(pp[i], 0xA, 100); printf("pp[%d] = %p\n", i, pp[i]); } if (!failed) printf("  %d \n", NALLOCS * ALLOC_SIZE); for(i = 0; i < NALLOCS; i++) { if (pp[i]) free(pp[i]); } free(pp); return 0; } 

すべてのソースはgithubにあります。

限界

古いUNIXハッカーは、メモリを制限する必要があるときにすぐに思い出します。 これは、プログラムのリソースを制限できるbashのユーティリティです。 実際、これはsetrlimitへのインターフェースです。

プログラムのメモリ量に制限を設定できます。

 $ ulimit -m 1024 

私たちはチェックします：

 $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 7802 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) 1024 open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited 

1024 kb-1 MiBの制限を設定しました。 しかし、プログラムを実行しようとすると、エラーなしで機能します。 1024 kbの制限にもかかわらず、プログラムが4872 kbほどかかることは明らかです。

その理由は、Linuxが厳しい制限を設定していないためで、男は次のように述べています

 ulimit [-HSTabcdefilmnpqrstuvx [limit]] ... -m The maximum resident set size (many systems do not honor this limit) 

ulimit -dオプションもありますが、これは機能するはずですが、mmapが原因で機能しません（リンカーのセクションを参照）。

QEMU

ソフトウェア環境を操作するには、QEMUが最適です。 仮想アドレス空間を制限するための–Rオプションがあります。 しかし、小さすぎる値に制限することはできません-libcとカーネルは適合しません。

見て：

 $ qemu-i386 -R 1048576 ./big_alloc big_alloc: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory 

ここで、-R 1048576は、仮想アドレススペースごとに1 MiBを残します。

このためには、20 MBのオーダーを取る必要があります。 ここに：

 $ qemu-i386 -R 20M ./big_alloc malloc: Cannot allocate memory Failed after 100 allocations 

100回の反復（10 MB）後に停止します。

一般的に、QEMUは依然として制限方法のリーダーであり、-R値をいじるだけで十分です。

コンテナ

別のオプションは、コンテナでプログラムを実行し、リソースを制限することです。 これを行うには、次のことができます。

• いくつかのドッカーを使用する
• lxcパッケージのユーザーモードツールを使用する
• libvirtを使用してスクリプトを記述します。
• 他の何か...

ただし、cgroupsというLinuxサブシステムを使用すると、リソースが制限されます。 直接プレイすることもできますが、lxcを使用することをお勧めします。 dockerを使用したいのですが、64ビットマシンでのみ機能します。

LXCはLinuXコンテナです。 これは、カーネル機能を管理し、コンテナを作成するためのユーザースペースのツールとライブラリのセットです-アプリケーションまたはシステム全体の分離された安全な環境。

カーネル関数は次のとおりです。

• 制御グループ（cgroups）
• カーネル名前空間
• chroot
• カーネル機能
• SELinux、AppArmor
• Seccompポリシー

ドキュメントは、 オフサイトまたは著者のブログで見つけることができます。

コンテナでアプリケーションを実行するには、lxc-execute configを提供する必要があります。ここで、コンテナのすべての設定を指定します。 / usr / share / doc / lxc / examplesのサンプルから開始できます。 男はlxc-macvlan.confから始めることをお勧めします。 始めましょう：

 # cp /usr/share/doc/lxc/examples/lxc-macvlan.conf lxc-my.conf # lxc-execute -n foo -f ./lxc-my.conf ./big_alloc Successfully allocated 102400000 bytes 

うまくいく！

cgroupでメモリを制限しましょう。 LXCでは、メモリ制限を設定することにより、cgroupコンテナのメモリサブシステムを構成できます。 パラメータはRedHatのドキュメントに記載されています 。 私が見つけた2：

• memory.limit_in_bytes-ファイルキャッシュを含むユーザーメモリの最大量を設定します
• memory.memsw.limit_in_bytes-メモリーとスワップの合計の最大量を設定します

lxc-my.confに追加したもの：

 lxc.cgroup.memory.limit_in_bytes = 2M lxc.cgroup.memory.memsw.limit_in_bytes = 2M 

以下を開始します。

 # lxc-execute -n foo -f ./lxc-my.conf ./big_alloc # 

沈黙-どうやら、記憶が少なすぎる。 シェルから実行してみましょう

 # lxc-execute -n foo -f ./lxc-my.conf /bin/bash # 

bashは起動しませんでした。 / bin / shを試してみましょう：

 # lxc-execute -n foo -f ./lxc-my.conf -l DEBUG -o log /bin/sh sh-4.2# ./dev/big_alloc/big_alloc Killed 

そして、dmesgでは、プロセスの輝かしい死を追跡できます。

 [15447.035569] big_alloc invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0 ... [15447.035779] Task in /lxc/foo [15447.035785] killed as a result of limit of [15447.035789] /lxc/foo [15447.035795] memory: usage 3072kB, limit 3072kB, failcnt 127 [15447.035800] memory+swap: usage 3072kB, limit 3072kB, failcnt 0 [15447.035805] kmem: usage 0kB, limit 18014398509481983kB, failcnt 0 [15447.035808] Memory cgroup stats for /lxc/foo: cache:32KB rss:3040KB rss_huge:0KB mapped_file:0KB writeback:0KB swap:0KB inactive_anon:1588KB active_anon:1448KB inactive_file:16KB active_file:16KB unevictable:0KB [15447.035836] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name [15447.035963] [ 9225] 0 9225 942 308 10 0 0 init.lxc [15447.035971] [ 9228] 0 9228 833 698 6 0 0 sh [15447.035978] [ 9252] 0 9252 16106 843 36 0 0 big_alloc [15447.035983] Memory cgroup out of memory: Kill process 9252 (big_alloc) score 1110 or sacrifice child [15447.035990] Killed process 9252 (big_alloc) total-vm:64424kB, anon-rss:2396kB, file-rss:976kB 

big_allocからmallocの失敗と使用可能なメモリの量に関するエラーメッセージは受信しませんでしたが、コンテナを使用してメモリを制限することに成功したようです。 今のところ、これについて詳しく見ていきましょう

リンカー

バイナリイメージを変更して、使用可能なヒープスペースを制限してみましょう。 レイアウトは、プログラムを構築する最後のステップです。 このために、リンカーとそのスクリプトが使用されます。 スクリプトは、メモリ内のプログラムセクションの説明であり、あらゆる種類の属性やその他のものです。

ビルドスクリプトの例：

 ENTRY(main) SECTIONS { . = 0x10000; .text : { *(.text) } . = 0x8000000; .data : { *(.data) } .bss : { *(.bss) } } 

ドットは現在の位置を示します。 たとえば、.textセクションは0×10000で始まり、次に0×8000000で始まる次の2つのセクションがあります：.dataと.bss。 エントリポイントがメインです。

すべてがクールですが、実際のプログラムでは機能しません。 Cプログラムで記述する主な関数は、実際に呼び出される最初の関数ではありません。 最初に、多くの初期化と消去が行われます。 このコードはCランタイムライブラリ（crt）に含まれており、/ usr / libのcrt＃.oライブラリに配布されます。

詳細は、gcc –vを実行して確認できます。 最初に、cclを呼び出し、アセンブラコードを作成し、asを介してオブジェクトファイルに変換し、最後にcollect2を使用してELFとともにすべてを収集します。 collect2-ldラッパー。 オブジェクトファイルと5つの追加ライブラリを受け入れて、最終的なバイナリイメージを作成します。

  /usr/lib/gcc/i686-redhat-linux/4.8.3/./././crt1.o /usr/lib/gcc/i686-redhat-linux/4.8.3/./././crti.o /usr/lib/gcc/i686-redhat-linux/4.8.3/crtbegin.o /tmp/ccEZwSgF.o <-     /usr/lib/gcc/i686-redhat-linux/4.8.3/crtend.o /usr/lib/gcc/i686-redhat-linux/4.8.3/./././crtn.o 

これらはすべて非常に複雑なため、独自のスクリプトを作成する代わりに、デフォルトのリンカースクリプトを編集します。 -Wl、-verboseをgccに渡して取得します。

 gcc big_alloc.c -o big_alloc -Wl,-verbose 

次に、それを変更する方法について考えてみましょう。 デフォルトでバイナリがどのように構築されるかを見てみましょう。 コンパイルし、.dataセクションのアドレスを探します。 objdump -h big_allocの出力は次のとおりです。

 Sections: Idx Name Size VMA LMA File off Algn ... 12 .text 000002e4 080483e0 080483e0 000003e0 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE ... 23 .data 00000004 0804a028 0804a028 00001028 2**2 CONTENTS, ALLOC, LOAD, DATA 24 .bss 00000004 0804a02c 0804a02c 0000102c 2**2 ALLOC 

.text、.data、および.bssセクションは、約128 MiBにあります。

gdbでスタックがどこにあるか見てみましょう：

 [restrict-memory]$ gdb big_alloc ... Reading symbols from big_alloc...done. (gdb) break main Breakpoint 1 at 0x80484fa: file big_alloc.c, line 12. (gdb) r Starting program: /home/avd/dev/restrict-memory/big_alloc Breakpoint 1, main (argc=1, argv=0xbffff164) at big_alloc.c:12 12 int i = 0; Missing separate debuginfos, use: debuginfo-install glibc-2.18-16.fc20.i686 (gdb) info registers eax 0x1 1 ecx 0x9a8fc98f -1701852785 edx 0xbffff0f4 -1073745676 ebx 0x42427000 1111650304 esp 0xbffff0a0 0xbffff0a0 ebp 0xbffff0c8 0xbffff0c8 esi 0x0 0 edi 0x0 0 eip 0x80484fa 0x80484fa <main+10> eflags 0x286 [ PF SF IF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 

espは0xbffff0a0を指します。これは約3 GiBです。 したがって、約2.9 GiBの束があります。

現実の世界では、スタックの最上位アドレスはランダムであり、たとえば出力で見ることができます：

 # cat /proc/self/maps 

知っているように、ヒープは.dataの最後からスタックに向かって増加します。 .dataセクションをできるだけ高く移動するとどうなりますか？

スタックの前の2 MiBにデータセグメントを配置しましょう。 スタックのトップを取り、2 MiBを引きます：

0xbffff0a0-0x200000 = 0xbfdff0a0

.dataで始まるすべてのセクションを次のアドレスにシフトします。

 . = 0xbfdff0a0 .data : { *(.data .data.* .gnu.linkonce.d.*) SORT(CONSTRUCTORS) } 

コンパイルします：

 $ gcc big_alloc.c -o big_alloc -Wl,-T hack.lst 

-Wlおよび-T hack.lstオプションは、hack.lstをスクリプトとして使用するようリンカーに指示します。

タイトルを見てみましょう：

 : Idx Name Size VMA LMA File off Algn ... 23 .data 00000004 bfdff0a0 bfdff0a0 000010a0 2**2 CONTENTS, ALLOC, LOAD, DATA 24 .bss 00000004 bfdff0a4 bfdff0a4 000010a4 2**2 ALLOC 

それでも、データはメモリに保存されます。 どうやって？ mallocによって返されるポインターの値を確認しようとすると、配置は.dataセクションの終わりから0xbf8b7000のようなアドレスで始まり、徐々にポインターを増やしていき、その後0xb5e76000のような低いアドレスに戻ります。 束が成長しているように見えます。

考えてみれば、何も変なことはありません。 glibcのソースを確認したところ、brkが失敗するとmmapが使用されることがわかりました。 そのため、glibcはカーネルにページを配置するように要求し、カーネルはプロセスに仮想メモリに大量の穴があることを確認し、空の場所の1つにページを配置します。

straceでbig_allocを実行すると、理論が確認されました。 通常のバイナリを見てください：

 brk(0) = 0x8135000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77df000 mmap2(NULL, 95800, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77c7000 mmap2(0x4226d000, 1825436, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4226d000 mmap2(0x42425000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b8000) = 0x42425000 mmap2(0x42428000, 10908, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x42428000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77c6000 mprotect(0x42425000, 8192, PROT_READ) = 0 mprotect(0x8049000, 4096, PROT_READ) = 0 mprotect(0x42269000, 4096, PROT_READ) = 0 munmap(0xb77c7000, 95800) = 0 brk(0) = 0x8135000 brk(0x8156000) = 0x8156000 brk(0) = 0x8156000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77de000 brk(0) = 0x8156000 brk(0x8188000) = 0x8188000 brk(0) = 0x8188000 brk(0x81ba000) = 0x81ba000 brk(0) = 0x81ba000 brk(0x81ec000) = 0x81ec000 ... brk(0) = 0x9c19000 brk(0x9c4b000) = 0x9c4b000 brk(0) = 0x9c4b000 brk(0x9c7d000) = 0x9c7d000 brk(0) = 0x9c7d000 brk(0x9caf000) = 0x9caf000 ... brk(0) = 0xe29c000 brk(0xe2ce000) = 0xe2ce000 brk(0) = 0xe2ce000 brk(0xe300000) = 0xe300000 brk(0) = 0xe300000 brk(0) = 0xe300000 brk(0x8156000) = 0x8156000 brk(0) = 0x8156000 +++ exited with 0 +++ 

そして今、変更されたもののために：

 brk(0) = 0xbf896000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb778f000 mmap2(NULL, 95800, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7777000 mmap2(0x4226d000, 1825436, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4226d000 mmap2(0x42425000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b8000) = 0x42425000 mmap2(0x42428000, 10908, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x42428000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7776000 mprotect(0x42425000, 8192, PROT_READ) = 0 mprotect(0x8049000, 4096, PROT_READ) = 0 mprotect(0x42269000, 4096, PROT_READ) = 0 munmap(0xb7777000, 95800) = 0 brk(0) = 0xbf896000 brk(0xbf8b7000) = 0xbf8b7000 brk(0) = 0xbf8b7000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb778e000 brk(0) = 0xbf8b7000 brk(0xbf8e9000) = 0xbf8e9000 brk(0) = 0xbf8e9000 brk(0xbf91b000) = 0xbf91b000 brk(0) = 0xbf91b000 brk(0xbf94d000) = 0xbf94d000 brk(0) = 0xbf94d000 brk(0xbf97f000) = 0xbf97f000 ... brk(0) = 0xbff8e000 brk(0xbffc0000) = 0xbffc0000 brk(0) = 0xbffc0000 brk(0xbfff2000) = 0xbffc0000 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7676000 brk(0) = 0xbffc0000 brk(0xbfffa000) = 0xbffc0000 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7576000 brk(0) = 0xbffc0000 brk(0xbfffa000) = 0xbffc0000 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7476000 brk(0) = 0xbffc0000 brk(0xbfffa000) = 0xbffc0000 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7376000 ... brk(0) = 0xbffc0000 brk(0xbfffa000) = 0xbffc0000 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb1c76000 brk(0) = 0xbffc0000 brk(0xbfffa000) = 0xbffc0000 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb1b76000 brk(0) = 0xbffc0000 brk(0xbfffa000) = 0xbffc0000 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb1a76000 brk(0) = 0xbffc0000 brk(0) = 0xbffc0000 brk(0) = 0xbffc0000 ... brk(0) = 0xbffc0000 brk(0) = 0xbffc0000 brk(0) = 0xbffc0000 +++ exited with 0 +++ 

カーネルがページを空のスペースに配置するため、ヒープ領域を減らすために.dataセクションをスタックにシフトしても意味がありません。

サンドボックス

プログラムメモリを制限するもう1つの方法は、サンドボックス化です。 エミュレーションとの違いは、何もエミュレートせず、プログラムの動作の一部を単に監視および制御することです。 マルウェアを分離して分析し、システムに悪影響を与えないようにするときに、セキュリティ研究でよく使用されます。

LD_PRELOADを使用したトリック

LD_PRELOADは特別な環境変数であり、次のような動的なリンカーにプリロードされたライブラリを優先的に使用させます。 libc。 ちなみに、このトリックは一部のマルウェアでも使用されています 。

私は、malloc / free呼び出しをインターセプトし、メモリーを処理し、制限に達したときにENOMEMを返す単純なサンドボックスを作成しました。

これを行うために、malloc / freeを中心に実装した共有ライブラリを作成し、mallocの量だけカウンターを増やし、freeが呼び出されたときに減らします。 LD_PRELOADを介してプリロードされます。

私のmalloc実装：

 void *malloc(size_t size) { void *p = NULL; if (libc_malloc == NULL) save_libc_malloc(); if (mem_allocated <= MEM_THRESHOLD) { p = libc_malloc(size); } else { errno = ENOMEM; return NULL; } if (!no_hook) { no_hook = 1; account(p, size); no_hook = 0; } return p; } 

libc_malloc-libcからの元のmallocへのポインター。 ストリーム内のno_hookローカルフラグ。 フックでmallocを使用し、再帰呼び出しを避けるために使用されます。

mallocは、 uthashライブラリーによってアカウント関数で暗黙的に使用されます。 ハッシュテーブルを使用する理由 freeを呼び出すときはポインタを渡すだけで、freeの内部では割り当てられたメモリ量がわからないためです。 したがって、キーポインターと値の形式で割り当てられたメモリの量を持つテーブルがあります。 これが私がmallocで行うことです。

 struct malloc_item *item, *out; item = malloc(sizeof(*item)); item->p = ptr; item->size = size; HASH_ADD_PTR(HT, p, item); mem_allocated += size; fprintf(stderr, "Alloc: %p -> %zu\n", ptr, size); 

mem_allocatedは、mallocの制限と比較される静的変数です。

今すぐ無料で電話すると、次のことが起こります：

 struct malloc_item *found; HASH_FIND_PTR(HT, &ptr, found); if (found) { mem_allocated -= found->size; fprintf(stderr, "Free: %p -> %zu\n", found->p, found->size); HASH_DEL(HT, found); free(found); } else { fprintf(stderr, "Freeing unaccounted allocation %p\n", ptr); } 

はい、mem_allocatedを減らします。

そして、最良の部分はそれが機能することです。

 [restrict-memory]$ LD_PRELOAD=./libmemrestrict.so ./big_alloc pp[0] = 0x25ac210 pp[1] = 0x25c5270 pp[2] = 0x25de2d0 pp[3] = 0x25f7330 pp[4] = 0x2610390 pp[5] = 0x26293f0 pp[6] = 0x2642450 pp[7] = 0x265b4b0 pp[8] = 0x2674510 pp[9] = 0x268d570 pp[10] = 0x26a65d0 pp[11] = 0x26bf630 pp[12] = 0x26d8690 pp[13] = 0x26f16f0 pp[14] = 0x270a750 pp[15] = 0x27237b0 pp[16] = 0x273c810 pp[17] = 0x2755870 pp[18] = 0x276e8d0 pp[19] = 0x2787930 pp[20] = 0x27a0990 malloc: Cannot allocate memory Failed after 21 allocations 

GitHubの完全なライブラリコード

LD_PRELOADはメモリを制限する優れた方法であることがわかりました

ptrace

ptraceは、サンドボックスを構築する別の方法です。 これは、別のプロセスの実行を制御できるシステムコールです。 さまざまなPOSIX OSに組み込まれています。

これは、strace、ltrace、およびほぼすべてのサンドボックスプログラム（systrace、sydbox、mbox、gdbを含むデバッガー）などのトレーサーの基礎です。

ptraceでツールを作成しました。 brk呼び出しを追跡し、元のブレーク値と次のbrk呼び出しで設定される新しい値の間の距離を測定します。

プログラムは2つのプロセスを分岐して開始します。 親-トレーサー、および子-トレーサー。 子プロセスでは、ptrace（PTRACE_TRACEME）を呼び出してからexecvを呼び出します。 親では、ptrace（PTRACE_SYSCALL）を使用してsyscallで停止し、子からのbrk呼び出しを除外してから、別のptrace（PTRACE_SYSCALL）を使用してbrkから返される値を取得します。

brkが指定された値を超えると、-ENOMEMをbrkの戻り値として設定します。 これはeaxレジスタで設定されているため、ptrace（PTRACE_SETREGS）で上書きします。 最もおいしい部分は次のとおりです。

 //    if (!syscall_trace(pid, &state)) { dbg("brk return: 0x%08X, brk_start 0x%08X\n", state.eax, brk_start); if (brk_start) // We have start of brk { diff = state.eax - brk_start; //      //    brk  -ENOMEM if (diff > THRESHOLD || threshold) { dbg("THRESHOLD!\n"); threshold = true; state.eax = -ENOMEM; ptrace(PTRACE_SETREGS, pid, 0, &state); } else { dbg("diff 0x%08X\n", diff); } } else { dbg("Assigning 0x%08X to brk_start\n", state.eax); brk_start = state.eax; } } 

また、libcにはbrkで問題が発生した場合にそれらを呼び出すのに十分な頭脳があるため、mmap / mmap2への呼び出しもインターセプトします。 そのため、セットポイントを超えてmmap呼び出しが表示されたら、ENOMEMでそれを中断します。

うまくいく！

 [restrict-memory]$ ./ptrace-restrict ./big_alloc pp[0] = 0x8958fb0 pp[1] = 0x8971fb8 pp[2] = 0x898afc0 pp[3] = 0x89a3fc8 pp[4] = 0x89bcfd0 pp[5] = 0x89d5fd8 pp[6] = 0x89eefe0 pp[7] = 0x8a07fe8 pp[8] = 0x8a20ff0 pp[9] = 0x8a39ff8 pp[10] = 0x8a53000 pp[11] = 0x8a6c008 pp[12] = 0x8a85010 pp[13] = 0x8a9e018 pp[14] = 0x8ab7020 pp[15] = 0x8ad0028 pp[16] = 0x8ae9030 pp[17] = 0x8b02038 pp[18] = 0x8b1b040 pp[19] = 0x8b34048 pp[20] = 0x8b4d050 malloc: Cannot allocate memory Failed after 21 allocations 

しかし、私はそれが好きではありません。 ABIに関連付けられています。 ここでは、64ビットマシンでeaxの代わりにraxを使用する必要があるため、別のバージョンを作成するか、＃ifdefを使用するか、-m32オプションを強制的に使用する必要があります。 そして、ほとんどの場合、異なるABIを持つ他のPOSIXのようなシステムでは動作しません。

他の方法

他に何ができますか（これらのオプションはさまざまな理由で拒否されました）：

• mallocをフックします。 彼らはもはやサポートされていないことを人間に言います
• PR_SET_MM_START_BRKを使用したSeccompおよびprctl 。 それは動作するかもしれません-しかし、 ドキュメントが言うように、これはサンドボックスではなく、利用可能なカーネル表面を最小化する方法です。 つまり、手動のptraceを使用するよりもさらに厄介です
• libvirt-sandbox 。 lxcとqemuの単なるラッパー。
• SELinuxサンドボックス 。 cgroupを使用するため、機能しません。

参照資料

• グスタボ・ドゥアルテ文献
• Linuxでのプログラムの時間とメモリ消費の制限 。
• Linuxサンドボックス