xv6のメモリ管理周りのコードリーディング - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
xv6のページング周りをちょっと見てたので記録をφ(..)メモメモ 参照したドキュメントはbook-rev10.pdfです。 book-rev10.pdfのP21、 Figure 1-2にxv6のメモリレイアウトがあります。 仮想アドレスの0から0x80000000がユーザー空間で、0x80000000〜0xFFFFFFFFがカーネル空間ですね。カーネル空間のうち先頭の0x100000バイトはBIOSの領域となってます。 カーネルのアドレス空間はvm.cにあるkmap構造体で管理してます。 static struct kmap { void *virt; uint phys_start; uint phys_end; int perm; } kmap[] = { { (void*)KERNBASE, 0, EXTMEM, PTE_W}, // I/O space { (void*)KERN
cgroup: プロセスが所属しているmemoryサブシステムが使用しているメモリの使用量を見るツール - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
pythonでなんとなく。 show memory usage in memcg. memoryサブシステムにtest1を作ってメモリの上限を100Mで設定。 root@saga:/sys/fs/cgroup/memory/test1# cat memory.limit_in_bytes 104857600 root@saga:/sys/fs/cgroup/memory/test1# cat memory.memsw.limit_in_bytes 104857600 root@saga:/sys/fs/cgroup/memory/test1# pid 4473はtest1に所属するbashのプロセス。このシェルから1MiBのmalloc()を繰り返すプロセスを実行する。 ツールはpid 4473を指定して実行 masami@saga:~/codes/memcgstat$ ./memcgst
memory cgroupとpageのLRUめも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
カーネルは4.1系です。 include/linux/mm_inline.hにLRUへの登録・削除処理の実装があります。 static __always_inline void add_page_to_lru_list(struct page *page, struct lruvec *lruvec, enum lru_list lru) { int nr_pages = hpage_nr_pages(page); mem_cgroup_update_lru_size(lruvec, lru, nr_pages); list_add(&page->lru, &lruvec->lists[lru]); __mod_zone_page_state(lruvec_zone(lruvec), NR_LRU_BASE + lru, nr_pages); } static __always_inlin
Linuxのsystem call fuzzer「syzkaller」めも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxのシステムコールのファジングツールとしてsyzkallerというのがあって、これはコードカバレッジを見つつ入力を変えていってくれるというファジングするツールです。 試してみたのでどんな感じなのかを簡単にめも。 まず、ツール自体はgolangで書かれているのでgoの実行環境が必要です。あとテスト対象のカーネル側でコードカバレッジを利用可能になっている必要があります。この辺はsyzkallerのドキュメントに書かれています。 ツールはビルドして行います。make一発で良いのですが、デフォルトだとstatic linkなバイナリを作ります。うちだと-lpthreadと-lcのところでそんなライブラリはないとか怒られてしまったので、動的リンクにしました。ホストとゲストのディストリビューションが同じならライブラリのABIの違いとかないですし、これで良いでしょう。 ファジングはVMを使って行
cgroupのv1とv2の切り分け的なところ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
cgroupはv1とv2という2つの実装（と言っていいのか？）があってそれらはkernel/cgroup.cで一つのコードベースにまとまっているのでコード読んでで混乱するなーというところで、誰得なめもを。 特に、4.1とかのカーネルだとv2のコードはまだ正式版となってないけどマージはされていて、DEVELsane_behaviorというオプションを使うことでv2の機能が使えるようになってます（参考： Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForward）。今はv2がちゃんと入っているのでこのオプションは不要で、cgroupのマウント時にcgroup v2としてマウントするかどうかで切り分けできます。cgroup_mount()のis_v2がそれです。 2083 static struct dentry *cgroup_mount(struct f
Linuxカーネルのコードネームの扱いが不憫なので/proc/sys/kernel/codenameで読めるようにした - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
たぶん、この辺の会話から Linuxカーネルのコードネームって気にした事無いな— int $0x03@SNS部 (@masami256) 2017年1月30日 この記事に繋がってたりするのかな？なんて思ったりということで、 さらに話を続けてみてですね、こんなpatchを書きました。4.10.0-rc6がベースのカーネルです。 diff --git a/Makefile b/Makefile index 96b27a8..6c3f392 100644 --- a/Makefile +++ b/Makefile @@ -1024,6 +1024,7 @@ endif prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic prepare1: prepare2 $(version_h) include/genera
gdbでアドレスが指す先のアドレスをdereferenceするコマンドを作った - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
gdbであるアドレスがアドレスを指している場合のdereferenceを簡単にやりたかったのでpythonでコマンド作ってみました。 これは例えばcのコードがこうで、 void func(char *p) { printf("[*] %s\n", p); } func()のディスアセンブル結果にこのような処理があるとします。 0x000000000040066e <+8>: mov %rdi,-0x8(%rbp) このとき、rbp - 8のアドレスは0x7fffffffdc68で、ここはアドレス0x0000000000602010を指しています。 (gdb) x/gx $rbp - 8 0x7fffffffdc68: 0x0000000000602010 このアドレスが指す内容は以下のようにしてdereferenceできますが、ちょっと面倒ですよね。 (gdb) x/s *(char **
c++で書かれたコードのアセンブリの読み方めも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
http://pwnable.kr/play.phpのuafがc++で書かれていたので読む必要が有ったので今後のためにもメモ程度に覚書を。今回はgdbのdisasとかobjdumpでアセンブリを読む時にnewはどのように呼んでいるるのかとかのめもです。 読んでいるバイナリのタイプはLinuxのELF64です。 基本的にはcHumanというクラスが有って、このクラスを継承したManとWomanというクラスがあります。main関数では最初にManとWomanのクラスのインスタンスをnewして作成します。そして、virtual関数のintroduce()を呼びます。 やっている処理のc++のコードを単純に書くとこんな感じになります。 Human *m = new Man("hoge", 1); m->introduce(); Humanクラスはこのようなクラスです。 class Human{ p
Docker + GNU GLOBALで手軽にソースコードリーディング環境を作る - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Kia Ora! この記事はプロ生ちゃん Advent Calendar 2016の16日目の記事です。 2015年はbash-completionでコマンド補完するときにプロ生ちゃんに何か言ってもらう - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモなんて記事を書きました。2014年はプロ生ちゃん Advent Calenderではないけど、 systemdでshutdown時にプロ生ちゃんに挨拶してもらう - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモなんてネタを書いたりしました。 今年はすぱこー焼きそばソースを頂きました(∩´∀｀)∩ﾜｰｲ 某氏よりプロ生ちゃんのソースを頂いたので今度焼きそばでも作ろう( ´ ▽ ` ) pic.twitter.com/etNhHQdTdj— int $0x03@SNS部 (@masami256) October 31, 2016 今年
Linuxカーネルのライブパッチを使ってテスト用のstubを作る - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2016の1日目の記事です。 テストする時にstubって便利ですよね。最近はnodejsで仕事のコードを書いているのでsinon便利だなとか思ってます。じゃあ、Linuxカーネルでもstub作れたら便利だよねという思うわけです。そうすると、我々にはlivepatchという機能があります。 というわけで、Linuxカーネルのlivepatchを使ってstubを作れるようにしてみようと思ったのが今回の記事のネタです。 今回のコードはLinux 4.9.0-rc4で動かしています。 stub機能の前提としてlivepacthを使うのでstubのコードはlivepatch方式でカーネルモジュールとして作成します。どんな関数をどのようにstubするかはカーネルモジュールで決めるので、ここは使う人の自由となります。カーネル側はstubをするための機
nodejsのmomentの関数をstubする - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
現在時刻取得のところmomentを使ってるけど、テスト書くときは固定値になって欲しいよねというところのめも。 momentを使っているクラスがこんなんだとして、 'use strict'; const moment = require('moment'); module.exports = class Foo { static get unixtime() { return moment().unix(); } }; stubでスタブを作る場合はstub()の第一引数にはmomentではなくて、moment.fnを渡す。 'use strict'; const sinon = require('sinon'); const moment = require('moment'); const Foo = require('./foo'); const stub = sinon.stub(mo
作成したファイル（struct dentry *）の読み書き用バッファをプロセス等固有に持たせるめも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
たとえば、debugfsのディレクトリとファイルをプロセス毎に作って、ファイルの中身はプロセスごとに変えたいってことをしたい場合にどうするかというメモです。 foobarという機能がdebugfsのルートディレクトリにディレクトリを作成して、piyoというプロセスはfoobar/piyo、poyoならfoobar/poyoとディレクトリができます。で、ファイルはfileという名前で固定されているけど、内容は個々に違う感じです。 /sys/kernel/debugfs/foobar --- /piyo/file |-- /poyo/file piyo/、poyo/は任意のタイミングで作成できて、foobarはstart_main()の時に初期化の関数を呼んで作るものとします。 foobar用に1つだけファイルを作成するならバッファは一つで良いのでファイルのdentryはこんな感じで作れます。
Linuxのカーネルモジュールがロードされるアドレス範囲 - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
カーネルモジュールがロードされるアドレスって範囲決まってたはずだけど、自分で言っといてホントそうだったけ？とか思ったので確認。 @RKX1209 たしかmodule mapping spaceだと思った… https://t.co/4rH8h4G3rS— int $0x03 (@masami256) 2016年10月4日 調べるのはLinux 4.8。 まず、Documentation/x86/x86_64/mm.txtを確認して、以下のところをチェック。 22 ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space で、この範囲にロードされるよねってとこです。 それでは、モジュールがどのように配置されるのかをコードで確認してみます。まずkernel/module.cのload_module()からみます。 こ
pid cgroupのコードを読む - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinuxカーネルもくもく会 #24 - connpassで書いてます。今日は前に追加されたcgroupsのpid管理のコードを読んでみます。 ファイルはcgroup_pids.cです。Linux 4.7のコードを対象にします。 最初にデータ構造です。pidの場合はpids_cgroup構造体が使われます。この構造体はcgroup_pids.cで定義されています。 43 struct pids_cgroup { 44 struct cgroup_subsys_state css; 45 46 /* 47 * Use 64-bit types so that we can safely represent "max" as 48 * %PIDS_MAX = (%PID_MAX_LIMIT + 1). 49 */ 50 atomic64_t counter; 51 int64_t l
Linux 2.0.40の頃のkmalloc() - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
たまには古いカーネルでも読んでみましょう的なところで、Linux 2.0.40の頃はkmalloc()はどんな実装だったのかというところでも見てみましょう。最近のkmalloc()の実装は使用しているディストーションが採用しているスラブアローケータの__kmalloc()の実装を見てみましょう。今のkmalloc()はスラブアローケータを使用しています。SLUBだとこんな感じです。 で、Linux 2.0.40はkernel.orgのファイル作成日時で見ると08-Feb-2004 07:13となっているので、12年前にリリースされたんですね。このバージョンが2.0系の最終バージョンです。 この当時のkmallocはスラブアローケータは使用していないけど、スラブアローケータ的に要求されたサイズを一番近い2の累乗サイズに切り上げて使っています。サイズはblocksizeという変数で管理してます
Linuxカーネルのコードを読んで勉強になったこと - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxカーネルのコードを読んでて、なるほど〜と思うことはよくあるけど、その中でも特に今までの考え方をぶち壊してくれたのはなんだっけと思ったところ、やっぱりリスト構造かなと言うところ。 c言語でリスト構造を作る場合、一般的な教科書方式だと↓のようにデータとnextポインタは密結合になってると思います。これの場合、struct foobarのポインタをnext要素に使っているので、他の構造体（例えば、struct hogehoge）で同じことをしようとすると、その構造体ではstruct hogehoge *nextというメンバ変数を持つ必要があります。 ヘッド要素はstruct foobarです。 struct foobar { int n; char s[64]; struct foobar *next; }; struct foobar head; Linuxカーネルの場合、データとリ
exit(2)とpid namespaceめも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
プロセスが終了するときにもpid namespaceが関係するので、その辺りのめもです。 流れとしてはこんな感じです。 do_exit()@kernel/exit.c -> exit_notify@kernel/exit.c -> forget_original_parent()@kernel/exit.c -> find_child_reaper()@kernel/exit.c -> zap_pid_ns_processes()@kernel/pid_namespace.c 今回読むのはzap_pid_ns_processes()です。 プロトタイプはこうです。 184 void zap_pid_ns_processes(struct pid_namespace *pid_ns) この関数はPID Namespace（pid_ns）に属するプロセスに対してSIGKILLを投げていって、プ
bccでuprobes - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
前回（LinuxのBPFとbccでデバッグする - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ）はbccを使ってkprobeでカーネル内の関数にprobeを設定したので今回はユーザーランドのほうでuprobesを使うメモ。 fork()が呼ばれたときにプロセス名、pid等を表示する。 #!/usr/bin/env python from bcc import BPF bpf_source = """ #include <uapi/linux/ptrace.h> void fork_enter(struct pt_regs *ctx) { bpf_trace_printk("fork()\\n"); } """ b = BPF(text=bpf_source) b.attach_uprobe(name="c", sym="fork", fn_name="fork_enter") wh
LinuxのBPFとbccでデバッグする - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
最近公開されたスライドでLinuxのパフォーマンスチューニングとかDTraceで有名なBrendan GreggさんのLinux BPF Superpowersが面白かったのでBPFとbccに手を出してみました。 BPFはLinuxカーネルのパケットフィルタリングの機能で、その名の通りBerkeley Packet Filterです。bcc「BPF Compiler Collection」というのはBPFを使いやすくするためのツールです。 BPFを使う場合、一番基本的なのはbpf(2)を使ってc言語で書くことだと思います。bccはpython＋c言語でBPFを使うようになっています。 (´-`).oO(BPFとbccの関係というのはkprobesとsystemtapの関係に近いような気がします で、Berkeley Packet Filterでデバッグってなんだよ？ってなると思うのですが、
Linuxカーネルのデバッグでprintk(9)デバッグを卒業したいっ！ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2015の25日目の記事です。 Linuxカーネルのデバッグである意味一番手軽なのがprintk(9)によるデバッグだと思うんですが（ユーザランドのプログラムで言うところのprintf(3)デバッグ）、この場合h速いCPUを積んだマシンならビルドはすぐに終わるけど、カーネルを変えている以上は再起動はしないといけないし、ちょっと手間ですよね。ということで、printk(9)によるデバッグはそろそろ卒業しようというのがテーマです。 ちなみに、printk(KERN_INFO"foobar\n")よりもpr_info("foobar\n")のほうがお手軽です。pr_で始まるマクロがinclude/linux/printk.hに定義されています。 Linuxのデバッグをするための方法としても下記のようなものがあります（kmemleakとかloc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
