情報を発信する人のところに情報が集まることを日々実感しているので、Linuxのメモリ管理に特に詳しいわけではないのですが最近遭遇した問題について自分の理解を書いておきます。ざっと調べても同じことを書いている人を見つけられなかったので、公開には意義があると考えています。識者の方がフィードバックをくださると嬉しいです。 ※ AIの出力をベースに書いているのでいつもと少し文体が違います。 背景 要約 調査 再現の難しさ Goアプリケーションの調査 pprofによる分析 GCログの調査 Linuxの調査 Goランタイムの調査 GoのGCとTHP khugepagedの問題 Goランタイムにおける回避策 回避策の削除 max_ptes_noneのデフォルト値について MADV_NOHUGEPAGEをやめた理由 調査内容まとめ 解決策 検証 C言語 Go言語 まとめ 背景 Go言語で書かれたOSSのア

前から思ってたことをちょっと書かずにいられなくなったのでポエムを書きました。 背景 問題 検知している方が正しいように見えがち 条件を揃えるのが難しい 環境の再現が難しい 検知数が多い方が良さそうに見える 正解かどうかの判断が難しい カバー範囲の正確な見極めが難しい 検知されないほうが嬉しい まとめ 背景 お前誰だよってなるかもしれないので書いておくと、Trivyという脆弱性スキャナーのメンテナをやっています。 github.com とある有名な方による以下のツイートがありました。 I just discovered, during @cloudflare #SecurityWeek no less, that Trivy (the vuln scanner) doesn't detect known issues in Alpine images. Including a critica

極限まで詳細を省けば何とか20分で雰囲気だけでも伝えられるんじゃないかと思って書きました。書き終えてから見返したら多分無理なので誇大広告となったことを深くお詫び申し上げます。 背景 概要 脆弱性の影響 ページキャッシュやsplice パイプ マージの可否 下準備 攻撃手順 まとめ 背景 先日Dirty PipeというLinuxカーネルの脆弱性が公表されました。 dirtypipe.cm4all.com Linuxのパイプに関する脆弱性なのですが、仕組みは意外とシンプルでぎりぎりブログでも伝わるかもしれないと思ったので自分の理解を書きました。あといつも細かく書きすぎて長くなるので、今回は雰囲気だけでも伝わるようにとにかく説明を簡略化し、ふわっとした概要だけでも理解してもらえるように頑張りました。その結果、若干正確性に欠ける部分があるかもしれませんがお許しください。細かい部分はまた別の記事でま

周りを見ていると何の苦もなく英語社会に適応しているわけですが、日々苦しんでいる人の奮闘記があっても良いのではないかと思って書きました。残念なエピソードを晒すことで実は自分もこうやって乗り切ってましたという人が現れお互いに助け合えることを期待しています。 概要 前提 バッドノウハウ 質問編 聞き取れなかった時にSorry?と聞き直さない 聞こえたところまで繰り返す 可能性のある質問全てに答える Do you mean ~ ? で可能性を潰していく うかつにYES/NOで答えない 他人に振ってみる 良い質問ですねぇを使う 何か言いそうな雰囲気を出して時間を稼ぐ 発言編 How are you?を速攻でキメる Can you hear me? Can you see my screen? に率先して答える How are you?にHow are you?で返す 発表編 話し続ける 質問が出ない

概要 内部挙動 ELFバイナリの準備 .go.buildinfo section Goのバージョン module情報 ldflagsについて Goのソースコード .go.buildinfo マジックバイト Goのバージョン情報へのポインタ module情報へのポインタ EXEファイルの処理 余談 まとめ 概要 Goでビルドしたバイナリは色々な情報を含んでいます。例えばビルドに使用したGoのバージョンを取得できます。 $ go version ./test ./test: go1.15.2 そしてついこの間知ったのですが、 -m オプションを使うことで利用しているmoduleの情報も取得可能です。 $ go version -m /usr/local/bin/terraform /usr/local/bin/terraform: go1.14.9 path github.com/hashic

普段あまりこういう誰の役に立つのか分からない記事は書かないのですが、解析をするまでの背景がOSSに関するとても良い話なので重い腰を上げて書きました。 概要 古のアプリケーション組み込み型のデータベースとしてBerkeley DBがあります。元々はカリフォルニア大学バークレー校によって開発され、その後Oracleによって買収されています。データ操作にSQLは使えず、アプリケーションに埋め込んで使用します。RDBまでは必要ないけどちょっとしたDBが必要みたいな時に使われているようです。機能はシンプルで組み込みのため性能も良いとのこと。詳しくは以下に書いてます。 docs.oracle.com 本記事ではそのBerkeley DBの中身がどのように実装されているのかの雰囲気を記します。Berkeley DBはBtree accessやHash access, Queue/Recno access

最近脆弱性の話とか本業と一切関係ないことを書いていたので、今回は本業に関する話です。 前提 所感 楽しい やりがいがある 実績になる 得意な形でアウトプットできる 勉強になる 深く特定領域を学べる 得た知見を公の場で共有しにくい 広く触れない（可能性がある） なぜ会社としてOSSをやるのか？ということを真剣に考えられる 市場の熟成 有料化のしやすさ 品質の向上 カンファレンスでの発表 ファンを作る 会社の売上に貢献できる方が精神的に楽 ユーザからのフィードバックが助かる メンテナンスコストが高くなる 方針を決められなくなる 宣伝は必要 まとめ 2019/08/01にOpen Source Engineerという肩書になってから既に1年が経過しました。そういうポジションの人はまだ日本では少ないんじゃないのかなと思ったので何か参考になればと所感を書いておきます。ちなみに最初の頃Open Sou

サイボウズさんの記事を読んで、自分も今回プロポーザル出したときに会社の人から貰ったアドバイスをまとめておこうと思いました。というのも、自分の席の隣の人が実際に今回のKubeCon Europe 2020でレビュワーだった人ですし、チームのボスはKubeConのChair経験者だったりするので、割と貴重な情報なのではないかと思っています。とはいえ何か特別なテクニックがあるわけではないです。 KubeConって何？とかは以下の記事を読んでもらえればと思います。 blog.cybozu.io 恐らくKubeConに限った話ではないですし指摘内容も普通の内容が多いと思いますが、一応次以降に自分で見返すこともありそうなので全部書いておきます。 プロポーザルに関するアドバイス 全部教えてもらったやつです。ただ自分なりに解釈した内容を書いてるので伝言ゲームで若干齟齬あるかもです。 タイトルは短く あまり

コンテナレジストリからイメージをpullする時にcurlで行えたら便利なのになと思うことが誰しもあると思います。自分は2ヶ月に1回ぐらいそういう時がやってくるのですが、大体やり方を忘れていて非常に時間を無駄にしていることに気づいてしまったのでメモを残しておきます。 コマンド このあと細かく説明を書いていますが、自分で備忘録的に見返すことが多いのでコマンドだけ先に書いておきます。以下はalpine:3.10を操作する例です。 Bearerトークン取得 $ export TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:library/alpine:pull" | jq -r '.token') マニフェストファイル取得 上のBearerトークン取得後に以下を実行。v2の