プログラム解析入門 もしくはC/C++を安全に書くのが難しすぎる話 Last updated: Jul 30, 2022 Kinuko Yasuda <@kinu>
サイボウズ社内ではC++で開発している製品があります。 未知のバッファオーバーランなどの脆弱性への対策として、重要なコンポーネントについてはプロダクション環境で利用しているバイナリでも AddressSanitizer を有効にしてビルドしています。 その製品で利用しているコンパイラをgcc5.3.0からgcc7.5.0に更新したところ性能劣化が発生しました。 製品コードとは別の部分が原因のため、根本原因の追跡が難しそうです。perf,bpftraceを使って性能劣化を追いかけてみましょう。 本記事で利用しているAddressSanitizer, bpftrace, perfコマンドはネット上に良質な記事がありますので、使い方などの解説は今回は省略させていただきます。 gcc7.5.0において、性能劣化が発生する再現コードとして次のようなものを用意しました。 #include <strin
今年に入って Octopassというプロダクトを公開しました。それは、Linuxのユーザや権限をGithubのTeamと連携して運用を楽にするというツールでした。色んな方々のご協力により、多くのRetweetやはてぶいただいたことで、ある程度、Octopass を必要としそうな人の目に触れたのではないかと思っています。(Githubのスター数が少ないのは今後の課題)その中で「すごく便利」「ぜひ導入したい」というフィードバックは、継続して機能追加していくというモチベーションにつながっていて、非常にありがたいです。 さて、この Octopass は、Linuxユーザ名前解決をするためにの glibc の libnssモジュールをCで実装しています。cgoやその他の言語でShared Objectを吐き出しても良かったのですが、それだと技術的挑戦が足りないとして、触れてこなかったCに挑戦しました
At PSPDFKit, we continue to grow our product range, working hard to add new features and improve existing ones, all while handling the countless special cases the world of PDF contains. As a natural consequence of this, we have a large ever-growing codebase. But more code means longer build times, and nobody likes longer build times. So in this post, we’ll show how you can use the excellent tool d
2. • (主にLinux上における)プログラム開発、 デバッグ、不具合調査のためのツールの紹介 • 広く浅く • 同じことを複数の手段で • キーワードや「できること」を知っていれば後は自分で 概要と目的 2/30 3. • gcc, clang • ソース読み • ag, GNU GLOBAL, Doxygen, callgrind • デバッグ • gdb, objdump, c++filt, core dump, addr2line • メモリチェック • ASan, Valgrind, TCMalloc • 静的解析 • cppcheck, scan-build • 実行時解析 • SystemTap, perf 目次 3/30 4. • 警告系オプション • -Wall -Wextra ; 必須 • コンパイラの警告を無視してはいけない • https://gcc.gnu.or
サイボウズ・ラボの光成です。 先日、社内で主にLinux上でC/C++を用いている開発者向けの講義をしました。 「こんなことができる」と知ってもらい、興味を持てば各自で勉強してもらおうと広く浅くツールを紹介しました。 gtags, ASan, Valgrind, addr2line, cppcheck, SystemTap, perfなどです。 興味があれば講義資料「C/C++プログラマのための開発ツール」をごらんください。 コンパイラオプション 受講者には新人やサイボウズ・ラボユースの学生もいたので基本的なところから紹介しました。 C/C++コンパイラを使うときはできるだけ警告オプションをつけるのが望ましいです。 警告が出るのは自分のコードの書き方に不備があることが多いからです。 gccやclangでは-Wall -Wextraは基本としてそれ以外にも有用なオプションがあります(C++用
第10章 著名な脆弱性対策 バッファオーバーフロー: #4 あふれを検出するデバッグ 領域あふれの問題の検出については、ロジックが複雑に入り組んでいる場合、ソースコードから見いだすのは容易でない。そのような場合、デバッガ等のツールの下で対象のプログラムを動かして、問題を見つけ出すことになる。 スタックおよびヒープにおけるあふれを検出するためのコンパイラのオプションやデバッグ・ツールがいくつか存在する。 次にその主なものを紹介する。 あふれの検出等に使うことのできるデバッグ・ツール ヒープにおける領域あふれやダブルフリー等の問題を検出できるツールをふたつ紹介する。ひとつは独立したツール、もうひとつは統合開発環境の中の機能である。 (1) Valgrind [GNU/Linux] ヒープデバッガを中心とした GNU/Linux 専用のツールスイートである。割当領域外への書き込みや、メモリリーク
OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く