Linuxカーネルのコンテナ技術を解説する人気シリーズ『Linux Container Book』第3弾が発売／『Linux Container Book 3』は特殊な機能やセキュリティ面における興味深い点を深掘り【Book Watch/ニュース】
ebpf-goによるLinuxカーネルトレース入門
ebpf-goによるLinuxカーネルトレース入門 ebpf-goを使用したLinuxカーネルトレース(fentry)について紹介します。 ebpf-goは、eBPFのGo向けライブラリです。このライブラリは、libbpfに依存せず(cgoを使用せず)にeBPFプログラムとデータのやり取りが可能であるため、ポータビリティが高くGo言語に適したeBPFライブラリとなります。 fentryは、カーネル関数のエントリポイントにプログラムをアタッチするためのBPFプログラムタイプです。簡潔に言うと、カーネル関数にフック処理を行うことができます。 GitHub: ebpf-go(cilium/ebpf) 公式ドキュメント: The eBPF Library for Go 本記事ではebpf-goのexamples内のtcprttを基に、ebpf-goの開発方法についても説明します。 前提条件として、
カーネルことはじめ
この記事は未踏ジュニアAdvent Calendar : 10日目です. カーネル, 書きたくないですか? こんにちは, horizon (@horizon2k38)です. 私は2023年の未踏ジュニアでA9Nというマイクロカーネルを作成していました. 人類なら誰しもがカーネルを書きたいと思ったことがあるはずです. そんな方のために, 未踏期間で得られた "0からカーネルを如何にして学び, 実装したか" という知見をより一般化して解説しようと思います. この記事の内容をすべて達成することで, あなたもきっとカーネルを書くことができるでしょう. やれば出来る きっと 絶対 私No.1 注: この記事はどちらかといえば初心者向けなので, 自信がある方は最下部の"参考文献"と, 私が書いた低レイヤー学習のロードマップのみ読むことをおすすめします. カーネル/OSとは そもそもカーネルとは, 所謂
第54回 Linuxカーネルのコンテナ機能 ―cgroup v2から使うCPUの帯域幅制限（2） | gihyo.jp
前回は、CPUコントローラでの帯域幅制限がどのように行われるのかについて簡単に説明しました。 前回の最後に、説明のために挙げた例がかなり理想的な状況であると書きました。今回は、帯域幅制限の機能を詳しく見ていくために、前回よりはもう少し複雑な状況について説明していきましょう。 未使用クォータの返却 前回説明で示した例では、CPUは割り当てられたスライスをすべて使いきっていました。しかし、複数のCPUがある環境で、タスクが終了したり、I/O待ちなどにより、クォータが割り当たったCPUで実行可能なタスクがなくなった場合はどうなるでしょう? 図1 割り当てられたスライスが使われない場合 図1のように、クォータプールに10msクォータが残っているとします。 ①でCPU1でCPUを使用するタスクから要求がありスライスが転送され、クォータの残りが5msとなりました ②で再度CPU1でCPUを使用するタス
はじめに - Writing an OS in 1,000 Lines
1000行でOSを作ってみよう 本書では、小さなOSをゼロから少しずつ作っていきます。 OSと聞くと腰が引けるかもしれませんが、OS (特にカーネル) の基本機能は案外単純です。巨大なオープンソースソフトウェアとしてよく挙げられるLinuxでさえ、バージョン0.01はたった8413行でした。様々な要求に応えるために次第に肥大化していっただけで、当初は大変素朴な実装になっていました。 本書ではコンテキストスイッチ、ページング、ユーザーモード、コマンドラインシェル、ディスクデバイスドライバ、ファイルの読み書きをC言語で実装します。これだけ様々な機能が詰め込まれているのに、コードは合計でたった1000行未満です。 「1000行なら1日でできそう」と思うかもしれませんが、初学者には少なくとも3日はかかるでしょう。OS自作のハマりポイントは「デバッグ」です。アプリケーション開発とは違うデバッグ手法
Linux システムコール 徹底入門
Linux システムコールについて調べたことをまとめる。システムコールの仕組みを理解すると、 OS とアプリケーションがどのように連携して動いているのかを理解できるようになります。 システムコールは CPU に依存する処理が多いため、 x86_64 に絞ります。 検証環境]# cat /etc/redhat-release CentOS Linux release 8.0.1905 (Core) ]# uname -a Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ]# cat /proc/cpuinfo | head processor : 0 vendor_id : GenuineInte
TechFeed Experts Night#19 「トラブルシューティングから Linux カーネルに潜り込む」の発表をしました - Pepabo Tech Portal
セキュリティ対策室の 伊藤洋也 ( @hiboma ) です 5/24(水) に 株式会社テックフィード様 主催の オンラインイベントの TechFeed Experts Night#19 〜 達人に聞く、Linuxカーネルコードの歩き方 に登壇しました。 次のような趣旨で開催されたイベントになります。 今回のTechFeed Experts Nightは「達人に聞く、Linuxカーネルコードの歩き方」がテーマです。 Linuxカーネルコードのエキスパートたちが、最前線のトレンドからマニアックな技術情報を30分間のセッションに凝縮！ それらをネタに、エキスパートたちが語り合うアフタートークもあります！ 今回このイベントで 「トラブルシューティングから Linux カーネルに潜り込む」の発表をしました。 トラブルシューティングから Linux カーネルに潜り込む 発表のスライドはこちらです。
【Linuxカーネルを読む】ChatGPTで爆速コードリーディング - Qiita
はじめに OpenAIによって開発されたChatGPTが話題になっています。特に、2023年3月14日に公開された最新モデルであるGPT-4は、これまで私達がAIに持っていた認識を根底から覆したのではないでしょうか？ 私は、「普通に人間とやりとりしているのと変わらんやん…」と率直に驚きました。 エンジニアの業務の中でも、自動コーディング支援、技術的課題の壁打ち相手、ドキュメント自動生成、学習支援等さまざまな用途に活用する可能性を皆さん検証している段階です。私もその波に乗っている真っ最中です。 そこで今回は、ソースコードリーディングをChatGPTをメンターにしたら爆速にできるのではないか？という仮説を検証してみました。 そしてどうせやるなら、ソースコードリーディングのハードルの高さナンバーワン（個人調べ）の「Linuxカーネル」を題材にしてみました。 なお、使用したモデルはGPT-4です。
GitHub - elastic/bpfcov: Source-code based coverage for eBPF programs actually running in the Linux kernel
Source-code based coverage for eBPF programs actually running in the Linux kernel This project provides 2 main components: libBPFCov.so - an out-of-tree LLVM pass to instrument your eBPF programs for coverage. bpfcov - a CLI to collect source-based coverage from your eBPF programs. This section aims to provide a high-level overiew of the steps you need to get started with bpfcov. Compile the LLVM
Kernel Queue: The Complete Guide On The Most Essential Technology For High-Performance I/O
Kernel Queue: The Complete Guide On The Most Essential Technology For High-Performance I/O When talking about high-performance software we probably think of server software (such as nginx) which processes millions requests from thousands clients in parallel. Surely, what makes server software work so fast is high-end CPU running with huge amount of memory and a very fast network link. But even the
Linux eBPFトレーシング技術の概論とツール実装 - ゆううきブログ
eBPF（extended Berkley Packet Filter）という用語を著者が初めてみかけたのは、2015年ごろだった。最初は、eBPFをその字面のとおり、パケットキャプチャやパケットフィルタリングを担うだけの、Linuxの新しいサブシステムであろうと認識していた。しかし、実際にはそうではなかった。 システム性能の分析のための方法論をまとめた書籍Systems Performance 1 の著者で有名なBrendan Greggが、Linuxのネットワークサブシステムとは特に関係ない文脈で、古典的なシステム性能計測ツールでは計測できないことを計測するツールを作っていた。その計測ツールがeBPFという技術によって実装されていることを知ったときに、eBPFに興味をもったのだった。また、eBPFは、システム性能を調べる用途以外にXDP（eXpress Data Path）と呼ばれるプ
XDP入門
こんにちは．閃光のハサウェイが配信開始されたので早速視聴しました．メッサーがいいですね． 前回もXDP関連の話題でしたが，今回はXDPに入門します． XDPを学習する際のロードマップやつまりどころの解消になればと思います． 2023-12-30 加筆 # 本記事を公開して約 2 年が経過しました. この加筆で古くなってしまった情報を修正しています. 差分は このブログの Github の PR を見てください. この 2 年間で eBPF 及び XDP への注目はさらに高まったように感じます. 取得できる情報も充実してきました. 特に O’reilly より発売された 入門 eBPF(原書: Learning eBPF) は非常に充実した内容になっています. 日本語でこれらの情報に触れられるようになったことは大変ありがたいです. 2023 年は個人的にも XDP に関して新たに発展的なコン
第692回 sysfsやbpftoolを用いたeBPFの活用 | gihyo.jp
第688回と第690回では、カーネルのトレーシングツールとして注目されているeBPFを活用するためのツールとしてBCCを紹介しました。しかしながら、BCCだけがeBPFを扱えるツールというわけではありません。今回はツールなしに利用できるsysfsや、よりユーザーフレンドリーなトレーシングツールであるbpftoolを紹介します。 Python版BCCの問題点 これまで紹介していたBPF Compiler Collection（BCC）のツールはいずれもフロントエンドとしてPythonを使っていました。つまり利用者はまずPythonスクリプトを起動し、その中でeBPFのオブジェクトをコンパイルし、ロードすることでようやくトレースが始まっていたのです。 実行環境でBPFオブジェクトをビルドする必要があるこの方法にはいくつかの問題点が存在します。 実行環境にコンパイラをインストールする必要がある
epollによるNetwork I/O in Goランタイム
21/11/24 Go Reject Con 2021にて発表 https://moneyforward.connpass.com/event/228698/
Improving NGINX Performance with Kernel TLS and SSL_sendfile( )
* Kernel version must be 5.10, not 4.14; see OSs That Do Not Support kTLS and the Amazon Linux 2 FAQ ** Inherits its kTLS support status from RHEL 8 as its upstream source *** See the FreeBSD commit log OSs That Do Not Support kTLSThe following OSs do not support kTLS, for the indicated reason: Alpine Linux 3.11–3.14 – Kernel is built with the CONFIG_TLS=n option, which disables building kTLS as a
How a simple Linux kernel memory corruption bug can lead to complete system compromise
In this case, reallocating the object as one of those three types didn't seem to me like a nice way forward (although it should be possible to exploit this somehow with some effort, e.g. by using count.counter to corrupt the buf field of seq_file). Also, some systems might be using the slab_nomerge kernel command line flag, which disables this merging behavior. Another approach that I didn't look
第688回 eBPFのコンパイラーに対応したツールでさまざまな挙動を可視化する | gihyo.jp
実行中のシステムの挙動を詳細にトレースする仕組みは、特に「よくわからない問題」に遭遇している時に重要です。今回はLinux向けのトレーシングツールの本命とも言えるeBPFを利用した各種ツールを紹介します。 eBPFに関する記事が今回以降、数回にわたって解説されています。あわせてご覧ください。 第688回 eBPFのコンパイラーに対応したツールでさまざまな挙動を可視化する（今回の記事） 第690回 BCCでeBPFのコードを書いてみる 第692回 sysfsやbpftoolを用いたeBPFの活用 第694回 libbpfとclangでポータブルなBPF CO-REバイナリ作成 第695回 入門BPF CO-RE eBPFとBPF Compiler Collection 改めて言うまでもなく、Linuxカーネルもしくはカーネル上で動いている各種タスクのパフォーマンスや挙動を調べなくてはならない
ptrace より 100 倍速いシステムコールフック作った - かーねるさんとか
新しい高性能で汎用的なシステムコールフックの仕組みを作ってみました。 モチベーションとして、システムコールをフックしてユーザー空間でエミュレートしたくなったのですが、現状、性能と汎用性を両立する仕組みがなさそうだったので、新しい方法を考えました。 今回のシステムコールフックの仕組みは以下のような特徴があります。 ptrace より 100 倍以上高速 LD_PRELOAD や既存のバイナリ書き換えツールより確実 カーネルへの変更なし、かつカーネルモジュールを使わない プログラムのソースコード、プログラムの再コンパイル不要 eBPF でトレーシングをしているけれど、できれば制約が少ないユーザー空間でトレーシングツールを作りたい。もしくは、gVisor のようなサンドボックスを作りたいけれど、ptrace による性能劣化が大きいので、他の高速なシステムコールフックの仕組みが使いたい、というよう
Socket migration for SO_REUSEPORT (Part 1) - Kuniyuki Iwashima
TCP ソケットと `SO_REUSEPORT` オプションに関する問題を解決するために Linux カーネル v5.14 から取り込まれる予定のパッチセットについて 2 回に分けて解説します。 - https://lore.kernel.org/bpf/[email protected]/ - https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=1f26622b791b6a1b346d1dfd9d04450e20af0f41 Part 1 では `SO_REUSEPORT` オプション、カーネルの挙動と問題点、パッチセットの効果について解説し、 Part 2 ではカーネルの実装と修正方法、追加した eBPF の機能について解説します。 ## SO_REUSEPORT とは 従来、 Linu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
device mapperによるディスクI/O障害のエミュレーション
