（これはx86-64 Linuxのコンテキストです。）
私は非常に信頼性が高く、生成されたアセンブリを完全に制御できるユーザースペース実行可能ファイルを作成しようとしています。自動スタック割り当てに依存したくないので、スタックを既知の場所に配置したいと思います。私のプログラムが（正確には）最大414バイトのスタックスペースを使用すると計算しているとします。 .bssセクションに414バイトを割り当て、RSPを一番上に向けるのは安全ですか？私はスタック管理がいつでもこの領域の外側のバイトにアクセスしないようにしたいと思います。
確かだが私のものプログラムはこの領域の外に書き込まず、一部のシステムコール（インストルクションを使用）を実行する必要があり、syscall少なくともカーネルコードの一部は呼び出し可能コンテキストで実行されるようです。私のスタックは壊れますか？
さらに、割り込みはプログラム内の任意の時点で発生する可能性があり、「赤い領域」の後ろに隠れているストーリーは、割り込みハンドラがRSP-128の外側の任意の広い領域に自由に書き込むことができ、潜在的に私のデータを破壊する可能性があることを示しているようです。この動作についてどのような保証がありますか？
ベストアンサー1
.bssセクションに414バイトを割り当て、RSPを一番上に向けるのは安全ですか？
実行可能ファイルに関するすべてを制御し、おそらくどのライブラリにもリンクしないので、それは大丈夫でしょう。特に、MAP_STACK mmap旗 現在は効果なし、読み書き可能なすべてのページをスタックに使用できます。
少なくともカーネルコードの一部は、呼び出し可能コンテキストで実行されます。
はい、システムコールは呼び出しプロセス内で実行されますが...
私のスタックは壊れますか？
...カーネルの実行独自のスタックに- そうしないと、システムコールの実行中にユーザースペースがカーネルの内部値を変更できます。一部のシステムコールはスタックに興味がありますが、ユーザースペーススタックには触れません（clone特に）。
さらに、割り込みはプログラム内の任意の時点で発生する可能性があり、「赤い領域」の後ろに隠れているストーリーは、割り込みハンドラがRSP-128の外側の任意の広い領域に自由に書き込むことができ、潜在的に私のデータを破壊する可能性があることを示しているようです。この動作についてどのような保証がありますか？
ハードウェア割り込みも独自のスタックを使用するため、ユーザーも安全です。シグナルハンドラから自分自身を保護するには、次のようにプライベートスタックを設定できます。sigaltstack。