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
排他制御の基礎の基礎
はじめに システムに存在するリソースには同時にアクセスしてはいけないものが多々あります。身近な例を挙げると、Ubuntuのパッケージ管理システムのデータベースがあります。aptコマンドの動作によってこのデータベースは更新されるのですが、同時に2つ以上のaptが動作できたとすると、データベースが破壊されてシステムが危機的状況に陥ります。 このような問題を避けるために、あるリソースに同時に1つの処理しかアクセスできなくする排他制御というしくみがあります。排他制御はOSが提供する重要な機能の一つです。 排他制御が必要なケース 排他制御は直感的ではなく非常に理解が難しいのですが、ここでは比較的理解が簡単なファイルロックというしくみを使って説明します。説明には、あるファイルの中身を読みだして、その中に書いてある数字に1を加えて終了するincというという単純なプログラムを使います。
なんだろう、嘘つくのやめてもらっていいですか？ 大学も技術者認定機関も、いつまで古いまたは間違ったシェルとカーネルの概念を説明し続けるのでしょうか？ シェルはカーネルの言葉をユーザーの言葉に翻訳したり、出力結果をユーザーに中継したり、カーネルを防御したりする層ではありません。指定したコマンドを実行するだけのプログラムです。勉強中の学生か代理執筆業者が適当な文献を調べて書いたとしか思えません。そして他人の説明を自分の言葉に置き換えるのが上手い人がおかしな説明をさらに広めています。個人サイトやオンライン学習サイト程度であれば適当なことを書いていても気にも留めませんが、大学や技術者認定機関のような正しいことを書いているに違いないと思えるような所までもが間違ったことを書いているから困ったものです。 みなさんは大学や技術者認定機関が言っていることなら正しいと思いこんでいないでしょうか？ そんなことあ
新しい高性能で汎用的なシステムコールフックの仕組みを作ってみました。 モチベーションとして、システムコールをフックしてユーザー空間でエミュレートしたくなったのですが、現状、性能と汎用性を両立する仕組みがなさそうだったので、新しい方法を考えました。 今回のシステムコールフックの仕組みは以下のような特徴があります。 ptrace より 100 倍以上高速 LD_PRELOAD や既存のバイナリ書き換えツールより確実 カーネルへの変更なし、かつカーネルモジュールを使わない プログラムのソースコード、プログラムの再コンパイル不要 eBPF でトレーシングをしているけれど、できれば制約が少ないユーザー空間でトレーシングツールを作りたい。もしくは、gVisor のようなサンドボックスを作りたいけれど、ptrace による性能劣化が大きいので、他の高速なシステムコールフックの仕組みが使いたい、というよう
slow logの時間は何を計測しているのか？ きっかけ とあるMySQLインスタンスで1Gbのネットワーク帯域を使い切ってレスポンスタイムが悪化していたという話を聞いた。 確かに遅いがlong_query_timeを小さくしてもslow_logは特に出ていなかったため、どのクエリが問題なのかを特定しづらかったらしい。 これを聞いたときはRedisとかインメモリのDBならまだしもMySQLがストレージより先に1GbのNICを使い切ることがあるのかーと驚いた。まあ、100GB以上のメモリも珍しくないので、ほとんどメモリから結果を返していれば1Gb/s以上返すことは難しくなさそうではある。 だが、long_query_timeを小さくしてもslow_logにクエリが出力されなかったという部分は気になった。 具体的にlong_query_timeがどれくらいなのか、同時接続数はどれくらいでQPS
GNU/Linux (x86/x86-64) のシステムコールをアセンブラから呼んでみる - CUBE SUGAR CONTAINER
今回は、表題の通り x86/x86-64 の GNU/Linux でシステムコールをアセンブラから呼んでみる。 システムコールは、OS (ディストリビューション) のコアとなるカーネルがユーザ空間のプログラムに向けて提供しているインターフェースのこと。 なお、アセンブラの実装に関しては以下の二つを試した。 NASM (Netwide Assembler) GAS (GNU Assembler) アセンブラには INTEL 記法と AT&T 記法という二つのシンタックスがある。 NASM はデフォルトで INTEL 記法を、GAS はデフォルトで AT&T 記法を使うことになる。 使った環境は次の通り。 $ uname -sr Linux 4.15.0-65-generic $ nasm -v NASM version 2.13.02 $ as -v GNU assembler versio
第688回の「eBPFのコンパイラーに対応したツールでさまざまな挙動を可視化する」ではBPF Compiler Collectionに付属の各種サンプルツールの使い方を紹介しました。今回はコンパイラーを活用して、自分でeBPF用コードを書くための基礎を学んでみましょう。 BCCのインストールとドキュメント 第688回も紹介したように、カーネル3.15で追加されその後拡充を続けている「eBPF」は任意の外部プログラムをカーネルの中で、より安全に実行できる仕組みです。カーネルモジュールを作る代わりに、独自のバイトコードをコンパイラーで生成し、それをカーネル内部にロード・実行することになります。これを使えばシステムコールの先のカーネルの状態を、プログラマブルに解析可能になります。 eBPF自体はカーネルの仕組みであり、ユーザーランドから使うためには、eBPF用のバイトコードにコンパイルする必要が
Kernel/VM探検隊は、カーネルやVM、およびその他なんでもIT技術の話題ジャンルについて誰でも何でも発表してワイワイ盛り上がろうという会です。yasukata氏は、バイナリの書き換えで、システムコールをフックする「Zpoline」の仕組みについて紹介しました。 システムコールをフックしたくなった理由 yasukata氏（以下、yasukata）：yasukataといいます。発表を始めます。 今回は、「Zpoline」という、バイナリを書き換えることでシステムコールをフックする仕組みを紹介します。ここではx84-64のCPUで動作するLinuxを想定しています。（スライドを示して）ソースコードはこちらにURLがあるので、よろしければ見てみてください。あとでスライドも公開するので、そちらも併せてご覧ください。 まず、なぜシステムコールをフックしたくなったのかですが、個人的にカーネルに実装
GitHub - agis/gtrace: Experimental system call tracer for Linux x86-64, written in Go
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
rust で udp パケット処理 - Qiita
この記事は MIXI DEVELOPERS Advent Calendar 2022 20 日目の記事です。 前書き GoogleCloud上で、rustでQUICのリレーサーバを作成するために、UDP Packetをたくさん受けとるために、コードを書いて試してみたので、その作業ログです。 コードはここに置いておきます 環境 環境は以下。 Google Cloud Compute Engine VM インスタンス 受信サーバ c2 インスタンス 16 vCPU (not Tier_1 network) 送信サーバ 受信サーバと同一VPCの複数のインスタンスからudpを投げまくる 計測はpacket per second(pps)を基準に検討しています。実際の数値自体はcoreの世代などの要因があり、あまり意味はありません。 ログ recvfrom(revmsg) / recvmmsg まず
Debug application inside Kubernetes using Linux Kernel tools Sonyのシステムエンジニア @KentaTadaさん runc Docker containerのコントリビューター Agenda oci-ftrace-syscall-analyzerの紹介 Kubernetes上でプロセスのコアダンプを取る方法の紹介 Kuberetesの全体像 oci-ftrace-syscall-analyzerの紹介 軽量でセキュアなruncベースのコンテナ環境を組み込み向けに開発した サードパーティ向けにセキュア(制限があってルートレスな)コンテナを立ち上げる要件 ftraceベースのシステムコールアナライザを作った 既存のKuberentesデバッグ方法 デバッグツールをPodに入れる デバッグ用イメージを作る プロセスの名前空間を共有し
はじめに mmap(2)とはmemory mappingを新規に作成するsystem callである。 #include <sys/mman.h> void *mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t off); mmap(2)は下図(Reference[1]のch.49より引用)のようにmapping typeとprivate/sharedによって、大きく4つに区分できる。 Reference[1] ch.49 Private/Sharedはflags引数にMAP_PRIVATE, MAP_SHAREDをそれぞれ付加する。Fileの場合は、flagに付加すべきものはないが、第５引数にfile descriptorを与える。Anonymousの場合は、MAP_ANONYMOUSを付け加え、fd=N
初代プレイステーションのサウンドをFPGAで演奏するものを作ってみたので、 忘れないうちにちょっとまとめ的なものを残しておこうかと。 なお現状ではあくまで技術デモのため、HDLコードやFPGAデータを公開する予定はありません。 GitHubに上げました。SFL+だけど。 ▼ FPGA使い万事塞翁が馬 プレステで遊んでいた日々…あのころの記憶から強くそして優しくBGMが流れてくる。 テレビ持ち込み禁止の寮にポータブル白黒テレビとプレステを持ち込んで遊んでいた。 映像は白黒だけど、せめてサウンドはと部屋の四隅にスピーカーを設置して楽しんだ日々。 いつか、このサウンドを、名曲たちをこの手で甦らせることをおぼろげに想いながら。 プレステの音源チップはスーファミの音源チップの弟（妹？）のようなものなので、 実装に関しては楽できる部分は多い。 スーファミも作ったことだし、じゃあプレステの音源も作れるの
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
初学者のための正しいシェルとカーネルの概念 ～ 大学も技術者認定機関も間違いだらけ - Qiita
ptrace より 100 倍速いシステムコールフック作った - かーねるさんとか
MySQLのslow_logは何を計測して出力されるのか - tom__bo’s Blog
第690回 BCCでeBPFのコードを書いてみる | gihyo.jp
ptraceより100倍以上高速なエミュレートを実現 バイナリの書き換えでシステムコールをフックする
Kubernetes Meetup #24 2つ目のスライドのやつ - inductor's blog
mmapにおけるMAP_PRIVATEの挙動 - 私のひらめき日記
PlayStation Sound Player on FPGA