サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
SystemTapで真犯人を捕まえろ！：Linuxトラブルシューティング探偵団 番外編（3）（1/4 ページ）NTTグループの各社で鳴らした俺たちLinuxトラブルシューティング探偵団は、各社で培ったOSS関連技術を手に、NTT OSSセンタに集められた。普段は基本的にNTTグループのみを相手に活動しているが、それだけで終わる俺たちじゃあない。 ソースコードさえあればどんなトラブルでも解決する命知らず、不可能を可能にし、多くのバグを粉砕する、俺たちLinuxトラブルシューティング探偵団！ 助けを借りたいときは、いつでもいってくれ！ OS：高田哲生 俺はリーダー、高田哲生。Linuxの達人。俺のようにソースコードレベルでOSを理解している人間でなければ、百戦錬磨のLinuxトラブルシューティング探偵団のリーダーは務まらん。 Web：福山義仁 俺は、福山義仁。Web技術の達人さ。Apache
概要 自分で構築したProxmox VE(PVE)のwebコンソールを眺めていたら、 4GBメモリのVMを4台しか起動していないのに仮想ホストでは48GB中37GBもメモリが使用されていた。 それの原因を突き止めるために調べていたらzfsが原因ということが判明した。 何も知らず、何も気にせず、zfsでPVEを構築していたら気付かない事象だと感じたのと、 メモリについて知ったことが多いため記事にした。 調査1(ホスト再起動) 困った時はホスト再起動するのが一番ということで、まずは再起動。 再起動後はメモリをほとんど使用されていなく、VM起動してもVMのメモリ領域くらいしか使われていない。 これで解決したと思い放置していたら、いつの間にかメモリ使用量が増えている。 なので変なプロセスがいるとかではなく、何かが起きていることがわかった。 調査2(プロセス確認) まずはメモリ使用量を確認する。 /
The GNU C Library is used as the C library in the GNU systems and most systems with theLinux kernel. 8月2日(米国時間)、「GNU C Library 2.26 released [LWN.net]」において、GNU C Libraryの最新版となる「GNU C Library 2.26」の公開が伝えられた。GNU C LibraryはGNUシステムやGNU/Linuxシステムで広く使われているCライブラリ。 バージョン2.26における主な機能は次のとおり。 malloc(3)へスレッド毎キャッシュを追加。特定用途で大幅な性能改善を実現 Unicode 10.0.0をサポート(文字エンコーディング、文字型情報、音訳テーブルアップデート) ハンガリー文字の取り扱い向上DNSリゾルバの改善
この脆弱性は2016年2月17日に対策済みバージョンと共に公開されました。内容としては getaddrinfo の呼び出しにおいてスタックバッファオーバーフローが発生する物です。公開時点で以下の通り、PoC を含めた技術的な詳細が公開されています。本記事では、脆弱性が発生するまでの処理と、回避策について解説したいと思います。CVE-2015-7547 — glibc getaddrinfo() stack-based buffer overflowGoogle OnlineSecurityBlog:CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow 脆弱性に至るまで 今回の脆弱性は getaddrinfo の呼び出しに起因しています。脆弱性のある箇所までの関数呼び出しは以下の様になっています。 getaddri
2016年2月17日に公開されたGNU Cライブラリの複数の脆弱性の内、CVE-2015-7547*1は任意のコードが実行可能であるとしてGoogleが報告しています。ここではこれら脆弱性に関連する情報をまとめます。 脆弱性情報 VulnerabilityNote VU#457759 glibc vulnerable to stack buffer overflow inDNS resolver JVNVU#97236594: glibc にバッファオーバーフローの脆弱性CVECVE-2015-7547CVE-2015-8776CVE-2015-8778CVE-2015-8779 影響 DoS/RCE DoS DoS DoS 重要度 High Low Low Low ステータス PoC公開 PoC公開 PoC公開 PoC公開 対策 修正版へ更新 修正版へ更新 修正版へ更新 修
glibcの脆弱性「GHOST」、影響範囲を見極め冷静な対処を：安定版Linuxディストリビューションの一部に影響、アップデートの適用を 2015年1月28日、Linuxで広く利用されているGNU Cライブラリ（glibc）に、バッファオーバーフローの脆弱性が存在することが明らかになった。Red Hat EnterpriseLinux 6＆7といった安定版のLinuxディストリビューションに影響があるため、注意が必要だ。 2015年1月28日、Linuxで広く利用されているGNU Cライブラリ（glibc）に、バッファオーバーフローの脆弱性（CVE-2015-0235）が存在することが明らかになった。脆弱性自体は2013年5月21日に修正されているが、「セキュリティ上の問題」として認識されなかったことから、Debian 7やRed Hat EnterpriseLinux 6＆7、Cen
「GHOST」の正体見たり枯れ尾花？ 名前には踊らされなかったセキュリティクラスター：セキュリティクラスター まとめのまとめ 2015年1月版（1/3 ページ） 2015年1月「GHOST」が登場します。名前の付いた脆弱性で、任意のコードが実行できるとあって大変なことになる……しかし、セキュリティクラスターは淡々と対応していたようです。 連載目次 2015年1月のセキュリティクラスターは、しばらくお正月休み明けののんびりした雰囲気が続いていましたが、半ばくらいから活発になってきました。まず、脆弱性のあるサイトを構築した業者に賠償金を支払う判決について、活発な意見が交わされます。そして同時期に平行して、みずほ銀行を発端とした銀行WebサイトのSSLについての議論が行われました。首都大学東京が世界に向けて成績データを公開していたことが明らかになり、みんなにあきれられるという事件も。 そして1月
ヒープは空いているメモリー空間から動的に獲得するものでが、ユーザメモリー空間に空きが有る限り獲得できるものでありません。ユーザプロセスで使用するmalloc関数は、glibcで実装されており、すなわちユーザプロセスとして実装されています。ヒープ処理としてカーネルはそのヒープと使えるメモリー空間を提供するのみで、ヒープ領域を設定するシステムコールはbrk関数です。 まず、min_brkにヒープ開始アドレスをセットしています。CONFIG_COMPAT_BRKでそのアドレスをmm->end_code（実行コードの終端アドレス）か、mm->start_brk（ヒープ開始アドレス）としているようです。そして拡張するアドレスがそれより小さければエラーです。 rlim = current->signal->rlim[RLIMIT_DATA].rlim_curで、プロセスのデータのリソースの拡張が可能で
YLUG の 「第67回カーネル読書会 (glibc malloc について)」の ビデオで， 「mmap()/munmap() を使って 1MB アラインされたメモリ領域を得る方法」 が紹介されていた．発表者の kosaki さんは， その方法を知って「腰を抜かした」と言っていたが， 私は1985年頃に同じようなことを考えたことがあるので， 出しゃばってここで整理・解説しておこう． 「同じようなこと」といっても，当時 mmap()/munmap() を使ったわけではないので， 以下の説明は mmap()/munmap() に依存する話ではなく， 一般のメモリ割り当て関数 (malloc() など) でも通用する話である． また，mmap()/munmap() はいまだに使ったことがないので，以下の説明で mmap()/munmap() に関する部分は間違っているかもしれない． もしそうで
◆プロセスのアドレス空間の実装 プロセスのアドレス空間は、次のような連続領域に分割されている。 テキスト 機械語を置く。VM_EXEC 属性と VM_READ属性が付いている。書き込み禁止 で共有可能。mm_struct の start_code と end_code が、開始番地と終了番地 を保持する。 データ(初期値付き) データを置く。VM_READ|VM_WRITE 属性が付いている(以下同様)。共有不 可。ファイルに初期値が含まている。 BSS(初期値無しデータ) 0 で初期化されるデータを置く。ファイルに初期値が含まれない。 ヒープ データを置く。malloc() の原資(の１つ)。brk() や sbrk() システム・ コールで大きさが変更される。番地が大きい方に伸びる。mm_struct の start_brk とbrk が開始番地と終了番地を保持する。 スタック 関数呼
HEAP領域とSTACK領域の間の未使用領域は、下記の領域に使われる 共有ライブラリのロード領域 メモリ・マップト・ファイル用領域 プロセス間共有メモリ用領域 メモリ・マップト・I/O用領域 メモリ・マップトによる追加HEAP領域 小さなサイズをmallocをしたときはHEAP領域に確保されるが、大きなサイズのメモリをmallocしたときはメモリマップ領域に確保される(glibcの場合) すべてmmapにするとメモリのフラグメンテーションがおきないが、mmapは重いしページサイズ単位しか扱えない。 32bit環境では論理メモリが2^32=4GBまでしか確保できない。このうちOSがメモリの上位1or2GBを使うので、実際にはアプリは3or2GBまでしかメモリは使えない。64bit環境になると、もっと使えるようになる。 HEAP領域は下に（上位アドレス方向）、STACK領域は上に（下位アドレス
Linuxのメモリ管理についてLinuxのメモリ管理について勉強中なので、簡単なまとめをメモ。 仮想アドレスと実アドレス多くのマルチタスクOSでは仮想アドレス空間を持っています。仮想アドレス空間の仕組みを利用すれば、物理メモリ上では不連続にマッピングされたページでも、プロセスからは連続した領域として扱うことができます。 ここでいうページとは、メモリを一定の大きさに区切って管理するための単位のことで、4Kバイトのことが多いようです。仮想アドレスと実アドレスへの変換はページ変換テーブルを用いて行われます。 実メモリの管理実メモリはバディシステムと呼ばれる仕組みで管理されています。 バディシステムは空きページを２の冪剰の単位で分割したページフレームのリストで管理します。たとえば、4ページ分の連続メモリを確保したい場合は、まずオーダー2（2の2剰個の連続ページ）のリストから空きを探し、無かった場合は一つ上のオーダーから探します
Linux x64環境において、ELF実行ファイル、共有ライブラリ、スタック領域、ヒープ領域のアドレスがどのように決まるのかについてのメモ。 環境 Ubuntu 12.04 LTS 64bit版 $ uname -aLinux vm-ubuntu64 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:39:31 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04.4 LTS Release: 12.04 Codename: precise $ gcc --version gcc (Ubuntu/Linaro 4
2014-05-25 進撃のmalloc #kernelvm 勉強会 malloc -Wikipedia ガチャピン先生 進撃のmallocってなんだ gblicのmalloc近辺の開発にかかわる MM SummitRuby core commiter(コミット率TOP10コミッタ) @kosaki55tea LKMLでのdisりあい 殴り合い [www.youtube.com/watch?v=cjaRZEtDTxc:embed] ebizzy | Free Development software downloads at SourceForge.net N個のスレッドがs病の間に何回malloc memcpy freeが出来るかを測定 カーネルでは時間をあまり食ってない mallocバグ知識 2行消したら20倍高速化Linuxキーワード - glibc とは：ITpro 1スレッ
(vm.overcommit_memoryの説明はぐぐってください:google:vm.overcommit_memory) 例えば vm.overcommit_memory = 2 vm.overcommit_ratio = 90なときに、実際の上限と今現在の値はどこで確認できるか？ the total virtual address space on the system is limited to (SS + RAM*(r/100)), where SS is the size of the swap space, and RAM is the size of the physical memory, and r is the contents of the file /proc/sys/vm/overcommit_ratio. proc(5): process info pseu
プログラミング言語 malloc(3)のメモリ管理構造 2007/11/30技術本部 クラウド基盤エキスパート 角馬 文彦 この記事の目次 malloc()といえばＣ言語ではお馴染みのライブラリで、最も良く使用されるライブラリの一つです。しかしその分だけ何らかの不具合を経験した人も多いのではないでしょうか。本書ではmalloc()、free()で確保、解放されるメモリリソースが内部的にどのように管理されているかを説明していきます。mallocライブラリの仕様を理解する事で、ライブラリ使用時に何らかの不具合が発生した際の手助けになればと思います。 ここではLinuxディストリビューションで標準的に使用されているglibcのmallocライブラリを扱います。今回の調査では次の環境を使用しています。 ディストリビューション :Debian sarge パッケージバージョン :glibc-2.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
