第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のパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま
cgroupsに影響するLinuxの新たな脆弱性CVE-2022-0492 コンテナエスケープの条件は
By Yuval Avrahami March 3, 2022 at 5:09 PM Category: Cloud Tags: containers, CVE-2022-0492, Linux, vulnerabilities This post is also available in: English (英語) 概要 2022年2月4日、Linuxはカーネルにおける新たな特権昇格脆弱性CVE-2022-0492を公表しました。CVE-2022-0492はコンテナの基本構成要素であるLinuxの機能、コントロールグループ(cgroup)における論理バグです。この問題は最近発見されたLinuxの権限昇格脆弱性のなかでもとりわけその単純さできわだつもので、「Linuxカーネルが誤って特権的オペレーションを非特権ユーザーに公開してしまった」という内容になっています。 さいわい、ほとんどのコン
第694回 libbpfとclangでポータブルなBPF CO-REバイナリ作成 | gihyo.jp
第688回と第690回では、カーネルのトレーシングツールとして注目されているeBPFを活用するためのツールとしてBCCを紹介しました。 また第692回ではBCC以外のeBPFを活用したツールの利用方法も紹介しています。 今回は一般的なコンパイラのようにバイナリを生成でき、移植性が高く、そして近い将来eBPFを使うための本流のひとつとなりそうなBPF CO-REについて紹介しましょう。 BPF CO-REの登場 BPF CO-RE（Compile Once - Run Everywhere）については第692回でも軽く紹介しました。改めてまとめると、次のような機能を実現する仕組みです。 BPFを利用したバイナリを実行環境とは異なる環境でビルドできる カーネルバージョン間の違いもある程度は吸収してくれる 実行バイナリのサイズはそれなりに小さくなる コンテナ内部などターゲットと異なるカーネルが動
epollによるNetwork I/O in Goランタイム
21/11/24 Go Reject Con 2021にて発表 https://moneyforward.connpass.com/event/228698/
ptrace より 100 倍速いシステムコールフック作った - かーねるさんとか
新しい高性能で汎用的なシステムコールフックの仕組みを作ってみました。 モチベーションとして、システムコールをフックしてユーザー空間でエミュレートしたくなったのですが、現状、性能と汎用性を両立する仕組みがなさそうだったので、新しい方法を考えました。 今回のシステムコールフックの仕組みは以下のような特徴があります。 ptrace より 100 倍以上高速 LD_PRELOAD や既存のバイナリ書き換えツールより確実 カーネルへの変更なし、かつカーネルモジュールを使わない プログラムのソースコード、プログラムの再コンパイル不要 eBPF でトレーシングをしているけれど、できれば制約が少ないユーザー空間でトレーシングツールを作りたい。もしくは、gVisor のようなサンドボックスを作りたいけれど、ptrace による性能劣化が大きいので、他の高速なシステムコールフックの仕組みが使いたい、というよう
IBM Proposing A CPU Namespace For The Linux Kernel - Phoronix
IBM Proposing A CPU Namespace For The Linux Kernel Written by Michael Larabel in Linux Kernel on 9 October 2021 at 06:56 PM EDT. 10 Comments IBM engineer Pratik Sampat published an early prototype of a CPU namespace interface for the Linux kernel. This CPU namespace was devised to address coherency issues with current means of viewing available CPU resources as well as addressing possible security
コンテナやコマンドなどのリソース単位で外部への意図しない通信をブロックする
特定の外部ネットワークへの通信の制限にはファイアウォールなどを利用することが多いですが、コンテナや実行されたコマンド名などをもとに、通信を制御したいという需要が自分の中でありました。 具体的には GitHub Self-hosted runner のような CI / CD 環境で、依存パッケージに悪意あるコードが入り込んでしまうようなサプライチェーン攻撃などを検知・防御し、意図せずにクレデンシャルなどの秘匿すべき情報が外部に漏洩するのを防ぎたいと思っていました。 このようなサプライチェーン攻撃への対策は様々ですが、実行時に悪意のある動作を検出するものとして、GitLab が Falco をベースとした Package Hunter などがあります。このツールは依存パッケージなどをインストールする際に実行されるシステムコールなどを監視するものです。 検知するだけであれば Package Hu
CoWはコウ可視化するんやで (aka. Rubyなどがforkした後のCoWを可視化してみる) - ローファイ日記
同僚の皆さんへのアンサーソングです。 hiboma.hatenadiary.jp ryuichi1208.hateblo.jp RubyKaigi やらですっかり遅く... と思ったがRubyKaigi takeoutの振り返りも書いてない... タイトルの通り（通り？）、forkしたプロセスがCoWをどれくらい起こしているか可視化するツールを作りました。 github.com まだ私の理解が浅いところもあるのですが、いったん動作例などを掲示してみます。 hiboma.c の場合 上のhibomaさんのCoWのサンプルプログラムの例です。プロジェクトのmiscというディレクトリ の下に exec_waiter.rb という補助スクリプトを置いてあります。それを経由してプログラムを起動すると、親のPIDを表示して実行が停止します。 cowsnoop/misc$ ruby exec_waite
Linux: mmap(2) したメモリに書き込みした際の Copy On Wirte を観察する - hibomaの日記
イントロ ペパボ社内 Slack で Linux の CoW = Copy On Write について、 id:ryuichi1208 id:udzura とディスカッションして盛り上がっていた。カーネル内で CoW を処理する関数を追えないか? という話があがったので、調べてみた次第。 ( なぜ CoW の話が出てきたのか / どんなことをディスカッションしてたのかは id:ryuichi1208 がまとめくれるかも? ) 結論 CoW を観察するには do_wp_pageを観察するといいみたい wiki.bit-hive.com ( いつもお世話になっております ) do_wp_page のソース https://elixir.bootlin.com/linux/v5.11.22/source/mm/memory.c#L3085 検証環境 Vagrant で用意した bento/ubu
kworkerのCPU使用率が高すぎるのでなんとかした - mnishikizawa's diary
題名の通りkworkerのCPU使用率が高いのをなんとかした記録。OSはCentOS 7.2 ぐぐってみたところ Linuxで一つのコアのCPU利用率が異様に高いのを何とかする - Qiitaや ubuntuでkworkerのcpu使用率がやたら高い - Qiitaが ヒットするが、こちらの環境とはマッチしないみたい。 覚えたてのperfを使ってみます。 Samples: 44K of event 'cycles', Event count (approx.): 40358935514 Children Self Command Shared Object Symbol + 70.47% 0.00% kworker/2:2 [kernel.kallsyms] [k] kthread + 70.47% 0.00% kworker/2:2 [kernel.kallsyms] [k] ret_f
メモリのデフラグはどうやって動いてる？ Linux Kernelの「Compaction」にみる断片化解消の仕組み
Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。齊加氏は、Linux KernelコードからCompaction機能の仕組みや工夫点を調査した結果について発表しました。 メモリの虫食い状態を緩和するデフラグメンテーション 齊加匠氏：「Deep Dive into the Linux Kernel メモリ管理におけるCompaction機能について」というタイトルで株式会社エヌ・ティ・ティ・データの齋加が発表します。 自己紹介です。所属は株式会社エヌ・ティ・ティ・データで、業務はアプリケーション開発です。OSは関係ないんですが、アプリケーション開発をしていて、主にSpringを使っています。好きなものはGolangやArch Linuxです。かねてよりメモリ管理に興味があって、Linux Kernelのメモリ管理につ
アプリケーションの巨大化で重要性を増す“hugepage” TLBヒット数を上げるLinuxのメモリ管理機能
Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。堀口氏からは「hugepage」の概要とカーネルコミュニティの開発動向について。 TLBの利用効率を上げるhugepage 堀口直也氏：「Linuxのhugepageの開発動向」について発表します。まず簡単に自己紹介です。私は堀口直也と申します。OSSコミュニティでの開発を軸に技術調査や評価、サポーターに従事しています。これまではカーネルコミュニティで、メモリ管理のコミュニティを中心に10年以上カーネル開発をしてきました。ここ数年はブロックチェーンのHyperledgerプロジェクトにも参加していて、ここでもOSSコミュニティで活動しています。 本日のLT（ライトニングトーク）は最初に「hugepage」の概要を話して、そのあとカーネルコミュニティの開発トピックについ
Socket migration for SO_REUSEPORT (Part 1) - Kuniyuki Iwashima
TCP ソケットと `SO_REUSEPORT` オプションに関する問題を解決するために Linux カーネル v5.14 から取り込まれる予定のパッチセットについて 2 回に分けて解説します。 - https://lore.kernel.org/bpf/20210612123224.12525-1-kuniyu@amazon.co.jp/ - https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=1f26622b791b6a1b346d1dfd9d04450e20af0f41 Part 1 では `SO_REUSEPORT` オプション、カーネルの挙動と問題点、パッチセットの効果について解説し、 Part 2 ではカーネルの実装と修正方法、追加した eBPF の機能について解説します。 ##
pidfd_open - w_o’s diary
pidfd_open pkill 打つたびに、「これpid再利用されたら地球が爆発するよな…」とか思っていたのだけど、今はpidfd_openがあるので助かった。 #define _GNU_SOURCE #include <sys/types.h> #include <sys/syscall.h> #include <unistd.h> #include <poll.h> #include <stdlib.h> #include <stdio.h> #include <sys/wait.h> #include <sys/stat.h> #include <fcntl.h> static int pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags) { return syscall(__NR_pi
perfを用いたシステムのボトルネック解析方法
背景システムの処理速度を改善するために、ボトルネック解析を行う必要があった。 ボトルネック解析の方法と、プロファイリングに使用したperfの使用方法に関して調査を行った。 記事の目的perfを使用し、ボトルネック解析を行う ここでは、perfの導入方法及び使用方法について記載する。 perfとはperf(Performance analysis tools for Linux)とはLinuxカーネル2.6.31以降で使用可能なLinuxの性能解析ツールである。 実行されているプロセス毎のCPU使用率やプロセス内で呼ばれている関数の割合などを調査できる。 利点gprofのように、プログラム作成時に専用のライブラリを入れたり、コンパイル時にオプションをつける必要がない フレームグラフにして、ビジュアライズできる 導入方法(Ubuntu編)Ubuntu16.04へperfを導入する手順について記
Linux bans University of Minnesota for sending buggy patches in the name of research [Update]
Greg Kroah-Hartman, who is one of the head honchos of the Linux kernel development and maintenance team, has banned the University of Minnesota (UMN) from further contributing to the Linux Kernel. The University had apparently introduced questionable patches into the kernel of Linux. The UMN had worked on a research paper dubbed "On the Feasibility of Stealthily Introducing Vulnerabilities in Open
![Linux bans University of Minnesota for sending buggy patches in the name of research [Update]](https://cdn-ak-scissors.b.st-hatena.com/image/square/186f57531da14866f6e824e0a98a1b5189d19aa2/height=288;version=1;width=512/https%3A%2F%2Fcdn.neowin.com%2Fnews%2Fimages%2Fuploaded%2F2020%2F07%2F1595709026_1543611652_tux_story.jpg)
fanotify(7)めも - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
fapolicydがどのようにアプリケーションの実行を禁止しているのだろうか？と思って調べためもです。 fapolicydがアプリケーションの実行を禁止する仕組み 仕組みとしてはfanotifyの仕組みを使ってファイルが実行のために開かれた場合に通知を受け取り、設定されたルールを調べて実行可能かどうかを返すということをしてます。 fanotify fanotifyの機能を使うには2つの関数があります。fanotify_init(2)とfanotify_mark(2)の2つです。fanotify_init(2)で初期化をしてファイルディスクリプタを得ます。次にfanotify_mark(2)で通知を受け取りたいイベントなどを設定します。イベントの受信はpoll(2)を使います。pollfd構造体の配列のうち1つはfanotify_init(2)によって初期化したfdを設定します。 実行の許可
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
partners/notfound
Put an io_uring on it: Exploiting the Linux Kernel - Blog | Grapl