革命の日々！ __attribute__(alloc_size) を使わないと_FORTIFY_SOURCE を活かせないよ。という話
_FORTIFY_SOURCEというバッファーオーバーフロー攻撃を防ぐのにとても有用なマクロがある。 知らなかった人は以下のmanでもまず見てください http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/feature_test_macros.7.html _FORTIFY_SOURCE (glibc 2.3.4 以降) このマクロを定義すると、文字列やメモリの操作を行う様々な関数を 使用する際にバッファオーバーフローを検出するための軽めのチェックが 実行されるようになる。すべてのバッファオーバーフローが検出される わけではなく、あくまでよくある例についてだけである。 現在の実装では、以下の関数にチェックが追加されている: memcpy(3), mempcpy(3), memmove(3), memset(3), stpcpy(3),
D_FORTIFY_SOURCEを使う - hidetzu's blog
これもバッファーオーバーフロー検出に関するお話。 gcc4からの機能です。 使い方 (o1以上の最適化オプションをつける) gcc -O1 -D_FORTIFY_SOURCE=1 foo.c検出時は、下記のいずれか コンパイル時 実行時 これの機能のすごいとこは、リリースビルドで使えるということ。 gオプションがいらないので、リリースするモジュールにも積極的に使えるということ。 #include <string.h> static char buf[6]; int main(int argc, char** argv) { strcpy(buf, argv[1]); return 0; } こんなソースを実行すると下記の感じになる。 ======= Memory map: ======== 08048000-08049000 r-xp 00000000 08:01 10888991 /ho
CおよびC++のコンパイラ・オプション強化ガイド - The Linux Foundation
このドキュメントは、C および C++のネイティブ（またはクロス）ツールチェーンを使用して、信頼性が高くセキュアなコードを提供するために貢献するコンパイラとリンカのオプションに関するガイドです。コンパイラオプションの強化の目的は、潜在的な攻撃や誤動作に対するセキュリティメカニズムを備えたアプリケーションバイナリ（実行可能ファイル）を生成することです。また、強化されたコンパイラオプションは、最新のオペレーティングシステム（OS） の既存のプラットフォーム セキュリティ機能とうまく統合するアプリケーションを生成するはずです。コンパイラコンパイラを効果的に設定することは、コンパイラーの警告、静的解析、デバッグインスツルメンテーションの強化など、開発中にもいくつかの利点をもたらします。 本ドキュメントは、以下の方々を対象としています： 組み込み機器、モノのインターネット機器、スマートフォン、パソコ
GCC / LLVM Sanitizer の使い方
はじめに メモリ関連のバグ（メモリリーク）を見つけるためのツールの一つである、GCCもしくはLLVMのSanitizerについての記事です。 使い方 使い方は至って簡単で、後述の用途に応じてコンパイルオプションを追加してビルドし、通常通り目的のプログラムを実行するだけです。 Memory Sanitizer メモリ領域は確保したものの、プログラムで意図的に初期化されていないメモリへのアクセスを検出する場合に利用します。 void main() { auto *buff = new char[256]; buff[0] = 1; std::cout << buff[1] << std::endl; // [1]は見初期化のためここでエラー検出 }
各種テスト - gcc - -fdiagnostics-color オプション
メッセージに色を使用。WHENにより色使用時を指定 WHEN に指定可能な値 : 「never」「always」「auto」 色の値は環境変数GCC_COLORSで定義
AutotoolsによるC/C++クロスビルド覚書き - Qiita
Autotoolsでのクロスコンパイルで悪戦苦闘したためメモ 例としてyoctoのi.MX6(imx6dlsabresd)ビルド環境を用いてAutotoolsを使ってクロスビルドする。 yoctoで作成したツールチェインをインストールしてビルドするのが正規の手順だが今回は理由あって環境変数等を設定して無理やりビルドを実行する。 環境変数の設定 SDKTARGETSYSROOT 必要ではないがsysrootのパスは繰り返し使用するため環境変数に設定しておく
AddressSanitizerを試す - cuspy diary
C言語 Advent Calendar 2016 16日目です。 clang 3.1, gcc 4.9以降にメモリ関連の不正な操作を検出するAddressSanitizerという仕組みが入りました。 二重freeやバッファオーバーフローなどCプログラミングにありがちなメモリ操作を検出できるので、ソフトウェアの品質向上だけでなく、セキュリティ対策としても有用です。 以下に思いつく限りのメモリの不正操作を実際に試してみました。 (1) スタックオーバーフロー(1.1) 正方向の書き込み [stack_overwrite.c] (https://github.com/hamano/santest/blob/master/tests/stack_overwrite.c)(1.2) 正方向の参照 [stack_overread.c] (https://github.com/hamano/santes
メモリバグ検出ツールのAddressSanitizerについて｜TECH BLOG｜モノリスソフト
はじめに こんにちは。モノリスソフト プログラマーの木村です。 C++プログラムのメモリバグ検出ツールである Address Santizer（以降ASan）について調べましたので紹介します。 ASanを導入することで、コードを大きく変更することなく、容易かつ効果的にメモリバグを検出できる可能性があります。 ASanの概要 ASanは、ランタイムのメモリバグ検出ツールです。 LLVM（v3.1～）でサポートされ、VisualStudio2019（v16.9～）でもサポートされるようになりました。 ASanによって以下のようなメモリバグを検出できます。 解放後アクセス ヒープバッファオーバーフロー スタックバッファオーバフロー グローバルバッファオーバフロー リターン後のアクセス スコープ外後のアクセス 初期化順序バグ ASanの動作概説 ASanではざっくり以下の方法でメモリチェックを行い
C/C++のためのデバッグツール
とすればよいのですが、これでもなおgccコマンドではClangが起動されます。この状態でGCCを使うにはgcc-10コマンドを使います。GCCが起動されることを確認するには とすればよいです。ただし、GCCのバージョンが上がった場合には、gcc-11, gcc-12, ...とする必要があります。 静的解析 ソースコードの解析には動的解析と静的解析があります。動的解析は実際にプログラムを実行して行う解析で、静的解析はプログラムを実行することなく行う解析です。動的解析は普段printfデバッグやデバッガで行っていると思うので、ここでは静的解析を紹介します。新たにソフトを入れなくても、GCCとClangには静的解析機能が付いています。GCCでは-fanalyzer、Clangでは--analyzeを付けてコンパイルすると、静的解析が行われます。また、いくつかのプログラムで試したのですが、どうや
各種テスト - gcc - 警告関連のオプション - フォーマット文字列関連のオプション - -Wformat-truncation
#include <stdio.h> int main(void) { int n = 123456; char c1[5]; char c2[11]; char c3[12]; /* 出力の切り捨てが発生する可能性が無い関数呼び出し */ snprintf(c1, 5, "test"); printf("%s\n", c1); /* 出力の切り捨てが発生する関数呼び出し */ snprintf(c1, 5, "test\n"); printf("%s\n", c1); /* 生成される文字列長が最小でも出力の切り捨てが発生する関数呼び出し */ snprintf(c1, 5, "test%i", n); printf("%s\n", c1); /* 変数の値次第では出力の切り捨ての可能性が有る関数呼び出し */ snprintf(c2, 11, "%i", n); printf("%s\
【C】可変長マクロで引数なしを受け渡すには ##__VA_ARGS__ (gcc拡張)
C言語のマクロの引数の最後に ... を指定することで任意個の引数を取り、 __VA_ARGS__ で参照できる：
コグノスケ GCCを調べる - memmoveのfoldingその1
VSCodeを使ってWindowsからLinuxアプリのデバッグ その1 目次: Linux その1、その2 同じことをしている人があまり居なさそうだったので、メモしておきます。 きっかけはGCCのコードをGDBのCUIモードで追っていて辛くなったことです。GCCのコードは超ぐちゃぐちゃの悲惨なコードで非常に追いづらく、GDBをもってしても何が起きているのか把握するのは困難です。せめてデバッガの画面くらいはGUIにして、見やすくできないか、と考えました。 WindowsからLinuxアプリのデバッグ、それぞれの役割 想定する構成は上記のとおりで、Linux側にはGUIがなく（ディスプレイを繋いでいない、など）、Windows側はデバッグのみで、Linux側でその他の全て（ビルドなど）を行う想定です。 Linux側の準備 この記事を読んでいるということは、既に何かデバッグしたいアプリケーショ
GCCの警告オプション設定 - Qiita
# 全ての警告メッセージを抑制したい場合 export CFLAGS="-w" export CXXFLAGS="-w" ./configure make # -Wnoを指定すれば、その警告は無効できる ## c # 暗黙の関数宣言 export CFLAGS="-Wno-implicit-function-declaration" # 廃止予定(deprecated) export CFLAGS="$CFLAGS -Wno-deprecated-declarations" # export CFLAGS="$CFLAGS -Wno-stringop-overflow" ## cpp # intからポインタへの変換 export CXXFLAGS="-Wno-int-to-pointer-cast" # export CXXFLAGS="$CXXFLAGS -Wno-class-memac
C++ コンパイル時「出力」 ～C++にできないことはない～ - Qiita
これは、 C++ でコンパイル時に出力まで済ませようとした話です。 コンパイラは GCC に限ります。 はじめに もうすぐクリスマスですね！ クリスマスにすることといえば……、 そう、コンパイル時処理ですね！！ コンパイル時処理 C++ のコンパイル時処理は非常に強力で、様々なことがコンパイル時にできてしまいます。 普通はコンパイル時に決まる定数の計算に使われますが、これを悪用利用してコンパイル時に処理がすべて終わるようなものも書くことができます。 例として、コンパイル時 FizzBuzz を書いてみます。 #include <array> #include <string_view> #include <algorithm> #include <concepts> #include <iostream> template <std::unsigned_integral T> conste
gccのDocker公式イメージ使ってC++でHelloWorldしてみた - Qiita
C++を扱うことになった 開発中のWebサービス案件でC++のソースコードを扱うことになりました。 とりあえずLinux環境で動けばよいので、 Dockerコンテナ内のgccでC++のソースコードがコンパイル＆実行できること を今回の目標とします。 （ make とかは今回使わないです。軽量化とかも意識してないです。） 今回作ったサンプルコードは以下に置きました。 https://github.com/segurvita/docker-gcc-sample Dockerイメージを探した Docker Hubでgccを検索してみたところ、Docker Hub公式のイメージがありました。 https://hub.docker.com/_/gcc/ これを使います。（もっと軽いのあるかもですが、 C++のソースコードを作った Hello World! します！
gccで各関数が使用しているスタックサイズを出力するオプション - いろいろ備忘録日記
概要 プログラムがいきなり落ちた gcc の -fstack-usage オプション 現在のスタック領域のサイズを調べる 試してみる makefile github にサンプルプロジェクトをアップ 参照情報 概要 忘れないうちメモメモ。こういうのは知ってるのと知らないので手間が大きく変わりますね・・・。 プログラムがいきなり落ちた 自分が書いたプログラムではないんですが、動かしていると特定の処理パターンを通したときにいきなり死ぬという状況が発生。 C言語なので、本当にスンって死んでくれます・・ｗ いろんなところをコメントアウトしたり、printfデバッグ入れたりして箇所は特定。 最終的にいろいろ調べたところの結果が「デフォルトのスタックサイズを超える割当をしてるのが原因」でした。これはアカン・・。 で、修正するのは良いとして、もうちょいマシな調べ方ないのかしら？って思いました。 手作業すぎ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mudflap_Pointer_Debugging - GCC Wiki
Does cygwin32 or cygwin64 gcc support asan now?
216624 – net/delegate: fails to build with clang 4.0
What is the logic of using $($(nproc) + 1) in make command?