Linux Kernel の net/ipv4/tcp_input.c は、challenge ACK セグメントの割合を適切に判定しないため、TCP セッションをハイジャックされる脆弱性が存在します。
ブートローダからカーネルまで これまでの私の ブログ投稿 を読まれた方はご存じかと思いますが、しばらく前から低水準言語を使うようになりました。Linux用x86_64アセンブリ言語プログラミングについても書いています。また、同時にLinuxのソースコードにも触れるようになりました。下層がどのように機能しているのか、コンピュータでプログラムがどのように実行されるのか、どのようにメモリに配置されるのか、カーネルがどのように処理や記憶をするのか、下層でネットワークスタックがどのように動くのかなどなど、多くのことを理解しようと意欲が湧いています。これをきっかけに、 x86_64 版Linuxカーネルについてシリーズを書いてみようと思いました。 私はプロのカーネルプログラマではないことと、仕事でもカーネルのコードを書いていないことをご了承ください。個人的な趣味です。私は下層で何が起きているのかとても
こんにちわ。せじまです。今年に入ってからアクティビティトラッカーを二回壊しまして、新しい分野の製品って設計いろいろ難しいんだなと、しみじみ思う今日このごろです。 先日、社内勉強会で Ethernet や CPU などの話をしました。前回のCPUに関する話に続き、今回のスライドも幅広い方に読んでいただけそうな内容かと思いましたので、公開させていただくことにしました。前回のスライドを読んでない方は、できればそちらを読んでいただいてからの方が、より理解が深まるのではないかと思います。 忙しい人のために三行でまとめると 2020年代には、サーバのネットワークインターフェースが 40Gbps 超えてそうな予感 もし Ethernet でそれだけ大量のパケットをさばくなら、(標準化されてないけれど) Jumbo Frame 使わないと厳しいかも 2020年代には、NICやブロックデバイス等、CPUを取
Linux OS でキャッシュをクリアする方法 (Kernel 2.6.16〜) 性能の試験をするときにファイルシステムのキャッシュによる影響を排除する。 root もしくはスーパーユーザーコマンドにて行なう。 % su root or sudo # sync # sysctl -w vm.drop_caches=1 # sysctl -w vm.drop_caches=2 # sysctl -w vm.drop_caches=3 or # echo 1 > /proc/sys/vm/drop_caches # echo 2 > /proc/sys/vm/drop_caches # echo 3 > /proc/sys/vm/drop_caches 1 … ページキャッシュのクリア 2 … ディレクトリエントリー(dentry)と inode のクリア 3 … ページキャッシュおよびディレ
static, benchmarking, tuning: sar, perf-tools, bcc/BPF: bpftrace, BPF book: Images license: creative commons Attribution-ShareAlike 4.0. This page links to various Linux performance material I've created, including the tools maps on the right. These use a large font size to suit slide decks. You can also print them out for your office wall. They show: Linux observability tools, Linux static perfor
July 16, 2014 This article was contributed by David Drysdale The previous article explored the kernel implementation of system calls (syscalls) in its most vanilla form: a normal syscall, on the most common architecture: x86_64. We complete our look at syscalls with variations on that basic theme, covering other x86 architectures and other syscall mechanisms. We start by exploring the various 32-b
Linuxカーネルに興味があるんだけど特に作りたいものってないんだよなーなんて割とあると思う訳です。俺とか。。。 まあ、kernelnewbiesのメーリングリストでもよく見る話題かと思います。この辺なんかもそうですね。 で、そんな時にオススメできるのがkmemleak。カーネルに組み込まれたメモリーリーク検出ツールです。 使い方は至って簡単でカーネルのコンフィグレーションにあるKernel memory leak detectorを有効にしたカーネルを普通に使えばOK。カーネルはメインラインのrcでもtipでもlinux-nextでも何でも良いと思います。 設定の場所はKernel Hacking -> Memory Debugging -> Kernel memory leak detectorにチェックをするのと、 その下のMaximum kmemleak early log ent
Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間
この記事は英語から大ざっぱに翻訳されたものであり、場合によっては不慣れな翻訳者や機械翻訳によって翻訳されたものかもしれません。 翻訳を改善してくださる方を募集しています。 SwappinessはLinuxカーネルがスワップ処理を行う頻度を変更するためのパラメータである。 Swappinessには0から100までの値を設定することができる。 低い値を設定するとカーネルは可能な限りスワップを行わないようにし、高い値を設定すると積極的にスワップ領域を利用しようとする。 既定の値は60となっており、たいていのシステムでは100に設定すると全体的なパフォーマンスに悪影響を及ぼし、0を含め低い値に設定すると応答速度が向上する(反応までの遅延が減少する)とされる。[1] 要約すると次のようになる。 値 スワップ頻度
kazeburoさんがCentOS6.2での事例を紹介されていますが、CentOS5系でもkernelを上げればRPS/RFSが使えるようになって、NICの負荷状況が劇的に改善します。 やり方は意外に簡単で、ELRepoからkernel-ml-2.6.35-14.2.el5.elrepo.x86_64.rpmを落としてきてインストール。 あとは、/boot/grub/menu.lstの設定をdefault=0にしてrebootすればOK。 $ uname -r 2.6.35-14.2.el5.elrepo ELRepoはNICのドライバなんかもいろいろ提供してくれるし、古いバージョンのRPMをarchiveで提供してくれて非常にいいですね(kernelの過去RPMはないのかな)。 RPS/RFSを有効にする設定はCentOS6と同様です。 # echo "f" > /sys/class/n
3月18日にLinuxの最新版「Linux 3.3」が公開されました。今回のバージョンではAndroidプロジェクトのコードのマージが大きな特徴の1つですが、ネットワーク関係でも大きな前進がありました。1つはOpen vSwitchがメインラインにマージされ、Linux 3.3から標準サポートとなったこと、そしてネットワークインターフェイスを束ねて帯域幅の拡大を実現する「Teaming」機能が改善されたことです。 LinuxにはすでにLinux bridgeがありますが、Open vSwitchはさらに高度な機能を備えたソフトウェアスイッチとして標準サポートされるとのこと。仮想環境のソフトウェアスイッチとして普及しつつあるOpen vSwitchは、さらにその地位を固めようとしています。 なぜOpen vSwitchがLinuxのメインラインに? ところで、なぜOpen vSwitchがL
えーっと、久しぶりに Linux Kernel にダメダメなバグが発見されて、よりにもよってうちの製品も影響を受けたので、ここに詳細を書くことにした。 つーか。新しい Kernel を使うなら皆で使おうよ。なんだよその「1つだけ」影響を受けて残りは「影響も受けないぐらい古い」ってのは… 概要 大雑把に 208.5日連続運転した Linux Kernel が突如として reboot する。 実機でなおかつ Time Stamp Counter を内包している必要があるので、Pentium4以降のプロセッサ(が、それはようするに今ある Intel 系CPU全部)か、その互換CPUである必要がある。32bit モード、64bit モードの区別はない。 逆に VMware や Xen など、仮想マシン上で動いている kernel に影響はない。これはそもそもバグを内包したルーチンを、仮想マシンで動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く