Linuxカーネルパラメータのチューニング＆設計 - Qiita
Linuxカーネルパラメータのチューニング＆設計 0.目的 【カーネルパラメータのチューニング】を修得する目的は、サーバの特性を理解し、それぞれに合ったカーネルパラメータのチューニングすることでリソースの有効活用をできるようになることを目的とし、私個人の経験を元にした見解を以下の記事に掲載します。 1.最初に サーバには、それぞれ必要なリソース特性があり、それに合わせたカーネルパラメータのチューニングが必要となります。 世の中の流れはオンプレよりクラウドに移行してはいるので、カーネルパラメータのチューニングよりスケールアップなりスケールアウトするなりの対応をすべきなのでしょう。 ですが、カーネルパラメータのチューニングを知らないとどちらを選択すべきかも理解しずらいと思いますので軽率には出来きません。(待ち行列理論もしらないといけませんが) また、最近のLinuxはデフォルト値が大きくなって
[訳] The burstable CFS bandwidth controller
LWN の The burstable CFS bandwidth controller の日本語訳です。 カーネルの CFS 帯域幅コントローラーは cgroup 毎に利用可能な CPU 時間を効率的に制御できる。特定のプロセスが CPU 時間を大幅に消費するのを防ぎ、CPU 時間を使いたい全てのプロセスに十分な時間を確保できる。とはいえ当然のことながら、帯域幅コントローラーが全てのワークロードに完璧に対応できるわけではない。Huaixin Chang の一連のパッチは、バーストするレイテンシの影響を受けやすいワークロードでより良く動作することを目指している。 帯域幅コントローラーは “Completely Fair Scheduling (完全に公平なスケジューリング)” (CFS) タスク (”リアルタイムプロセス”と対比して”通常プロセス”とも呼ばれる) にのみ適用される。リアルタ
![[訳] The burstable CFS bandwidth controller](https://cdn-ak-scissors.b.st-hatena.com/image/square/053b2fd0c855cd9a8a7b72a29f20a75217b89ed5/height=288;version=1;width=512/https%3A%2F%2Fstorage.googleapis.com%2Fzenn-user-upload%2Favatar%2Fd9647d1a08.jpeg){kind=avatar}
Linuxにおけるデバイスファイルの仕組み
Linuxにおけるデバイスファイルはデバイスをファイルという概念を通して扱えるようにしたものです。デバイスファイルは通常のファイルと同様に読み書きを行うことができます。しかし実際には、その読み書きはデバイスドライバを通じてデバイスの制御に変換されます。 この記事では、デバイスファイルへの読み書きがどのようにデバイスの制御に変換されるのかを説明します。デバイスファイルはデバイスドライバとファイルの2つのコンポーネントに依存したものであるので、最初にデバイスドライバ、次にファイルについて説明し、最後にデバイスファイルがどのようにデバイスドライバと結び付けられるかを解説します。 この記事の内容は主に詳解 Linuxカーネル 第3版及びhttps://github.com/torvalds/linux/tree/v6.1によります。 目次 デバイスドライバ デバイスドライバの実例 read_wri
Netlinkと友達になろう - ネットワークは砕けない
Netlinkを学び始めました。記録です。 今回はNetlink メッセージをコードで書く内容であったり、そのメッセージをキャプチャしてバイナリを読みながらNetlinkを理解する記事になります。 Netlinkとは? ユーザー空間とカーネル空間のやりとりを行う事が出来るLinux kernelのサブシステムです。 Netlinkは、socket通信を利用してユーザー側はカーネル空間との通信を行う事が出来るため通常のネットワークプログラミングと同じように、Netlinkに関する様々な要素を持ったヘッダーを付加し送信を行った後、recv関数といったソケットからメッセージを受け取る関数を使用する事でカーネル空間とユーザ空間の通信を実現しています。 linuxjm.osdn.jp ネットワーク経由でNetlinkを使用する主な要素としては以下が挙げられます。 経路テーブルに関する操作(例:追加,
Linuxカーネルから見た「コマンド名」
はじめに Linuxを使っているみなさんは普段からLinux上で様々なコマンドを実行していると思います。それらを識別するときに「コマンド名」という単語を使っていると思いますが、文脈によってこの単語が意味するものは異なります。本記事ではLinuxカーネルがいうところのコマンド名がどういうものかについて書きます。 一番最初に短い結論、その次に具体的な説明、そして最後にこれについて調べようとしたきっかけ、およびその後の調査プロセスについて書きます。 結論 Linuxカーネルから見たコマンド名は実行ファイル名のbasename(ファイル名からディレクトリ部分を除いたもの)の先頭15バイト カーネルのメモリ内のプロセス(正確にはカーネルレベルのスレッド)ごとに存在するtask_structという名前の構造体の中のcommという16バイトのフィールドにNULL終端文字列として格納されている カーネルの
Netlink IPCを使ってLinuxカーネルのネットワーク情報にアクセスする - Hash λ Bye
背景 Linux networkingには下記のような様々な構成要素があります。 ネットワークデバイス 経路テーブル フィルタ etc. これらを操作する必要がある場合、一般的には iproute2 などのコマンドラインツールから操作を行うことが多いかと思います。 しかしOpenStackやKubernetesなどの大規模なクラスタを管理する環境では、複数ホストにまたがってネットワークを動的にかつ一貫した方法で構成することが求められます。 こうしたニーズを実現するために、Linux networkingの構成要素を自作のプログラムから直接制御することが最も効率的な場合があります。 NetlinkというLinuxのサブシステムはLinuxカーネル内のネットワーク関連リソースを制御します。このNetlinkサブシステムを活用することでネットワーク管理を自動化することができます。 概要 Netl
Transparent memory offloading: more memory at a fraction of the cost and power
Transparent memory offloading: more memory at a fraction of the cost and power Transparent memory offloading (TMO) is Meta’s data center solution for offering more memory at a fraction of the cost and power of existing technologies In production since 2021, TMO saves 20 percent to 32 percent of memory per server across millions of servers in our data center fleet We are witnessing massive growth i
Meta's Transparent Memory Offloading Saves Them 20~32% Of Memory Per Linux Server - Phoronix
Meta's Transparent Memory Offloading Saves Them 20~32% Of Memory Per Linux Server Written by Michael Larabel in Linux Kernel on 20 June 2022 at 06:15 PM EDT. 29 Comments Meta's engineering team today published an interesting blog post about Transparent Memory Offloading (TMO) as a new Linux kernel feature they developed that is already used in production on Facebook/Meta servers. Within Meta's dat
Linux Kernel Exploitation Technique: Overwriting modprobe_path
Linux Kernel Exploitation Technique: Overwriting modprobe_path Preface If you have taken a look at my series on learning linux kernel exploitation, you probably have known that I have been learning the topic lately. For the previous several weeks, my team and I have participated in some CTFs, namely DiceCTF and UnionCTF, which both have a linux kernel pwn challenge. To my little knowledge and aver
Linux の sysctl net.ipv4. icmp_echo_ignore_broadcasts / macOS (XNU) sysctl net.inet.icmp.bmcastecho の実装を読む - hibomaの日記
Linux の sysctl net.ipv4. icmp_echo_ignore_broadcasts と、 macOS / XNU の sysctl net.inet.icmp.bmcastecho の実装を調べたエントリです 何の sysctl ですか? Linux の sysctl net.ipv4. icmp_echo_ignore_broadcasts は CIS Benchmarks で Smurf 攻撃対策として取り上げられています。 www.cisecurity.org Smurf 攻撃とは何ですか? Smurf 攻撃自体の説明は他のサイトで確認してください ja.wikipedia.org SMURF攻撃とは、攻撃者が標的となるサーバーをInternet Control Message Protocol（ICMP）パケットで圧倒させようとする分散サービス妨害（DDoS）
spliceを使って高速・省メモリでGzipからZIPを作る - knqyf263's blog
良い話を含むので概要の最初だけでも読んでもらえると幸いです。この話が実用的かと言うと多分全然実用的ではないので理解しても仕方ないかなと言う気がします。 概要 ファイルフォーマット gzip 10-byteのヘッダ 拡張ヘッダ ファイル本体 フッタ（trailer） zip ローカルファイルヘッダ Data descriptor セントラルディレクトリエントリ セントラルディレクトリの終端レコード gzipからzipへの変換 gzipヘッダの処理 gzipファイル本体の処理 gzip trailerの処理 複数gzipファイルの連結 PoC まとめ 概要 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com この脆弱性の原理自体も面白いのですが、その前に報告者の組織で行っているGzipとZIPの処理で引っかかったのでまず先にそち
UNIX Domain Socket の SO_SNDBUF, SO_RCVBUF についての覚書 - hibomaの日記
macOS と Linux の UNIX Domain Socket の SO_SNDBUF, SO_RCVBUF について調べていた。 経緯 会社で @kurotaky のトラブルシューティングの相談を受けた際の覚書。 下記のように UNIX Domain Socket を挟んで IPC しているコードがあり、macOS と Linux で挙動が違っているのを調べていた。Linux では Go Ethereum が送ってくるデータを全部読み出せるが、macOS だと一部 ( 8192 バイト 注1 ) しか読み出せないとのことだった。 Ruby のコード <----- UNIX Domain Socket -----> Go Ethereum 色々調べてみたところ、macOS / Linux で UNIX Domain Socket のデフォルトの SO_SNDBUF, SO_RCVBU
Dirty Pipe（CVE-2022-0847）の発見経緯が面白かった - knqyf263's blog
最初に断っておくと今回は万人向けの記事ではないです。面白かったので自分が忘れないようにまとめているだけです。 本記事の位置付け はじめに 発見経緯 CRCのエラー HTTPアクセスログ 壊れたgzipのtrailerを見てみる 壊れたファイルの法則性 月次ログファイルの生成 Linuxカーネルのバグの可能性 バグ混入の歴史 ログ破損の原因 8バイトの謎 PoCの制約 まとめ 本記事の位置付け Dirty Pipe（CVE-2022-0847）三部作の最後です。ダークナイト三部作で言うとダークナイト ライジングにあたります。ダーティとダークって似てませんか。 spliceを使って高速・省メモリでGzipからZIPを作る 20分で分かるDirty Pipe（CVE-2022-0847） Dirty Pipe（CVE-2022-0847）の発見経緯が面白かった（本記事） 上の1, 2を前提知識と
第49回 cgroup v2のリソース分配の方法とインターフェースファイルの操作 | gihyo.jp
前回はcgroup v2で使えるコントローラのうち、v1から大きく変わったコントローラや、新たに実装されたコントローラについて説明しました。 今回はcgroup v2で行われるリソース制御のタイプ、cgroupで使うインターフェースファイルに関係する規則や、コントローラでリソース制限を設定する際に関係するファイルのフォーマットや書き込み方について説明したいと思います。 cgroupとcgroup内ファイルの命名規則 cgroup v1には、cgroupで使用するファイルやその内部の書式について、明確な規則はありませんでした。cgroup v2では、ファイルに関する規則がきちっと定められました。この決まりを説明していきましょう。 今回の実行例は、前回と同じくUbuntu 21.10環境で実行しています。 まず、cgroup自体の動きに影響するcgroupコアに関係するインターフェースファイル
20分で分かるDirty Pipe（CVE-2022-0847） - knqyf263's blog
極限まで詳細を省けば何とか20分で雰囲気だけでも伝えられるんじゃないかと思って書きました。書き終えてから見返したら多分無理なので誇大広告となったことを深くお詫び申し上げます。 背景 概要 脆弱性の影響 ページキャッシュやsplice パイプ マージの可否 下準備 攻撃手順 まとめ 背景 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com Linuxのパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PATCH v2] HID: logitech-hidpp: rework one more time the retries attempts
Recent kernels and USB keyboard/mouse connections — Fedora Linux Users
Memory_pressure - linux-mm.org Wiki
KMSAN Patches For The Linux Kernel Updated For Catching Uninitialized Memory Problems - Phoronix
partners/notfound