lguest for 2.6.22

コンパイルでエラーになってしまったので、2.6.21 の頃のものと比較。

--- arch/i386/kernel/asm-offsets.c.orig 2007-07-12 00:06:33.000000000 +0900
+++ arch/i386/kernel/asm-offsets.c      2007-07-12 00:17:51.000000000 +0900
@@ -16,6 +16,10 @@
 #include <asm/processor.h>
 #include <asm/thread_info.h>
 #include <asm/elf.h>
+#ifdef CONFIG_LGUEST_GUEST
+#include <linux/lguest.h>
+#include "../../../drivers/lguest/lg.h"
+#endif

 #define DEFINE(sym, val) \
         asm volatile("\n->" #sym " %0 " #val : : "i" (val))
@@ -115,4 +119,17 @@
        OFFSET(PARAVIRT_iret, paravirt_ops, iret);
        OFFSET(PARAVIRT_read_cr0, paravirt_ops, read_cr0);
 #endif
+#ifdef CONFIG_LGUEST_GUEST
+       BLANK();
+       OFFSET(LGUEST_DATA_irq_enabled, lguest_data, irq_enabled);
+       OFFSET(LGUEST_PAGES_host_gdt_desc, lguest_pages, state.host_gdt_desc);
+       OFFSET(LGUEST_PAGES_host_idt_desc, lguest_pages, state.host_idt_desc);
+       OFFSET(LGUEST_PAGES_host_cr3, lguest_pages, state.host_cr3);
+       OFFSET(LGUEST_PAGES_host_sp, lguest_pages, state.host_sp);
+       OFFSET(LGUEST_PAGES_guest_gdt_desc, lguest_pages,state.guest_gdt_desc);
+       OFFSET(LGUEST_PAGES_guest_idt_desc, lguest_pages,state.guest_idt_desc);
+       OFFSET(LGUEST_PAGES_guest_gdt, lguest_pages, state.guest_gdt);
+       OFFSET(LGUEST_PAGES_regs_trapnum, lguest_pages, regs.trapnum);
+       OFFSET(LGUEST_PAGES_regs_errcode, lguest_pages, regs.errcode);
+       OFFSET(LGUEST_PAGES_regs, lguest_pages, regs);
+#endif
 }

とりあえず通るは通った。

LSRR の受信

ちょっと情けないが、ちょっと jot。興味があちこちしてしまいデジャヴばかりの様な気がする。

ip_rcv()
  NF_IP_PREROUTING
    ip_rcv_finish()
      ip_rcv_options() ヘッダ長 20バイト超ならばオプションあり
        ip_rcv_options_compile() sk_buff 内 cb に設定
        ip_opeions_rcv_srr()
          ip_route_input()
        ip_route_input()
        dst_input()

ip_forward()
  NF_IP_FORWARD
    ip_forward_finish()
      ip_forward_options()
      dst_output()
        ip_output()
          ip_fragment()

skb->pkt_type は eth_type_trans() にて設定
rt->rt_type の設定は....
  ip_route_input()
    ip_route_input_slow()
      ip_mkroute_input()
        (ip_mkroute_input_def())
        __mkroute_input()
          rt_set_nexthop()
  output側も同じ感じ。
  ip_local_deliver() は ip_route_input_slow() にて rth->u.dst.input に

ip_local_deliver()
  NF_IP_LOCAL_IN
    ip_local_deliver_finish()

先日の見難い図を簡単にすると

hostA ---- host B ---- host C

にて

1. host B から host A , hostB を通って hostC
2. hostC から hostB, hostA 再度 hostB に戻って hostC

といった lsrr を投げと、1.の場合は hostB。2.の場合は hostC の PREROUTING で -j LOG は取れるものの INPUT にはログが残らず、もちろん到達せず。両方の場合で IP上は src dst 共に自アドレスとなっている。/proc の accept_source_route を 1。rp_filter を 0。netfilter の全ての hook のポリシを ACCEPT としたが、通さず。2. にて hostB を通過している点、1. 2. にて PREROUTING に LOG が残っているので、ip_rcv_finish() あたりなのか...調べること。

conntrackd の internal と external キャッシュ

ソースをつらつらと眺めていたところ、少し理解できた。

internal

カーネルから (netlink 経由で) 受け取った内容を展開。なので master 側の話

external

マスタから (マルチキャストで) 受け取った内容を展開。なので slave 側の話。VRRP でマスタが落ちたと判断した場合、この内容を (netlink 経由で) カーネルに通知。通知を受けたカーネルは netlink で通知。で巡り巡って旧 slave 現 master となった internal に展開される。

じゃ internal って意味ないじゃん。と思ったのだが、これは master と slave のやりとり --- プロトコル --- の問題らしい。

sync モードと nack モードなるものがあり、現在 nack モードを推奨。internal を参照しているのは sync モードのみらしく、しかも ENOBUFS の時のみ。nack モードの場合どんなやりとりか調べること。でも、まだ実際に稼働させたことなし.... virtualize 何にしようか。

いろいろ。

元気がないので、記事引用などなど
OLS 2日目：カーネル開発、ファイルシステムについての講演。タイトルとは無関係っぽいが

　Anton Blanchard氏によって手短にデモが行なわれたPower6プロセッサには、4.7GHzのコアが16基搭載されていた。Blanchard氏がデモを印象付けるために、Linuxカーネルを10回コンパイルするベンチマークツールを使用してデモを行なったところ、たったの20秒で完了した。

あーはっはっはっはっはっはぁ....

Lguest ソッコーで 2.6.22 のパッチが出ていた

Releases

The good news is: lguest is all one big kernel patch, including the launcher. You can download the latest patch for 2.6.22.

やっぱ買うなら x86 かぁ。

TCPの輻輳制御について。2.6.22 のもの全てではないが TCP and Linux' Pluggable Congestion Control Algorithmsなくなってくれるな。まだ読んでいない。また末尾のリンクも良さげ。

conntrack と LSRR

ソースルーティング (ポリシのではない) を試すべく

  ~~~~~~~~~~~~~~~        +-----------+     +---------+      +---------+
{ The Internet} ----+ firewall+----+ host 1 +----+ host 2 |
  ~~~~~~~~~~~~~~~        +-----------+     +---------+      +---------+
                                <-----------------<
                                >-------------------------------->

みたいな構成で試したところ... firewall から出ない。accept_source_route は 0 なのに何故? ふと思い HOWTO 見た一般過程向き? のルールの抜粋

 
    -A block -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A block -i ! eth0 -m conntrack --ctstate NEW -j ACCEPT
    -A block -j DROP

DROP の前に LOG を入れてみると見事 dmesg に表示。う〜んと悩むこと小一時間。結果は state に INVALID を入れてあげれば通った。iptables (8) から抜粋すると

Possible states are INVALID meaning that the packet is associated with no known connection,

lsrr 面倒見ないよ、知らん。って事らしい。
で、こちらも中途....

conntrackd に至る前置き

古い記事ですが、Slashdot 本家に Firewall Failover With pfsync And CARPという記事があった。良いなぁ。と linux 周りを眺めていたら ct_sync? という conntrackd 実装している方が、以前全てカーネルスペースで実装しようとしていた形跡を発見。ML にも入らず日々ダラダラ過ごしていたところ、conntrackd なるものを発見。ct_sync より勢いがありそうな感じで今後に期待....というのが今更ながらの前置き。そうそう CARP と conntrackd 使ってみたらしき ML への投稿があった気がする。

元気が無いのでまたまた貢献できないと思ふぅ。商用ファイアウォール製品と比較して、辛いな。と思う部分ですので、頑張って下さい。

conntrackd のオプション

目に余る逸脱ぶりなので、ちょっと戻る。-c の ``external cache'' という言葉に戸惑う。相変わらず内部、外部キャッシュの意味を理解していない.... conntrack-tools/src/main.c から

static const char usage_client_commands[] =
        "Client mode commands:\n"
        "  -c, commit external cache to conntrack table\n"

(プライマリ) 外部のキャッシュをコミット

        "  -f, flush internal and external cache\n"

(プライマリ、バックアップ) キャッシュのクリア

        "  -F, flush kernel conntrack table\n"

(バックアップ) カーネルの conntrack テーブルのクリア

        "  -i, display content of the internal cache\n"

内部キャッシュの表示

        "  -e, display the content of the external cache\n"

外部キャッシュの表示

        "  -k, kill conntrack daemon\n"

停止

        "  -s, dump statistics\n"

統計情報表示

        "  -R, resync with kernel conntrack table\n"

(プライマリ) カーネルの conntrack テーブルとの再同期

        "  -n, request resync with other node (only NACK mode)\n"

(ん? script_.*.sh にない) NACK モードにて他ノードとの再同期

        "  -x, dump cache in XML format (requires -i or -e)";

どーゆ経過か知らないけどキャッシュ内容の XML 出力