プロセスとLinuxカーネルの間の相互作用に関する質問です。これは正式な証明のコンテキストであるため、設定が少し奇妙に見えることがあります。一般的な方法として、ELFファイルからロードされたプログラムがあり、「承認されていない」方法で独自のコードセグメントまたはデータセグメントを書き込めず、不正なシステムコールを実行することはできませんが、別の場所に書き込むことができるとします。メモリ（つまり、すべての場所への書き込みを許可する）これは安全ですか？プログラムがマップされていないページにアクセスするかどうかは重要ではありません。これは、分割エラーが発生し、プログラムが明らかなエラーで終了するためです。 （関心はプログラムですいいえやめて承認されていないことをしてください。 )
セグフォルトに加えて、メモリ内の任意の場所に書き込むとどのような影響がありますか？たとえば、プロセス表示ページにMMIOまたは秘密の代替システムコール/カーネル通信メカニズムがありますか？
私が本当であることを望むのは次のとおりです。メモリアドレス[xy]（プログラムのコードとデータ）にV値が含まれていて[xy]以外の場所に書き込みが実行されると、プロセスはエラーコードで終了します。または、[xy]のメモリにはまだVが含まれています（他のすべてのプロセスの不変性はまだ保持されています。プロセスはまだユーザーモードにあり、カーネルはMMIOマッピングを作成していません）。
- ページマップに[xy]外部のミラーが含まれていると、[xy]外部書き込みが成功し、[xy]のデータが変更されることがあります。しかし、ユーザーが要求しない限り、カーネルは通常この種のページを生成しないと思います。
- 仮想メモリのどこかにマップされたvDSOページがありますが、これらの機能は必要ないので、ここに書くことは大丈夫です。
私がメモリに書き込もうとしている主な理由は、スタック処理を簡素化するためです。ほとんどのコンパイラはスタック境界チェックを生成せず、Linuxはガードページを使用してスタックオーバーフローを不完全に防止します。私はスタックに非常に大きな配列を割り当て、その中で慎重に選択されたインデックスにアクセスすることで保護をバイパスできると信じています。アプリケーションのデータページにアクセスすると、プログラムが確実にダウンするため、これだけは保護する必要がありますが、何を保護すべきかわかりません。スタックからヒープ割り当て（mmappedページと）がどのくらい離れていますか？sbrk
抽象セマンティクスに違反するために、このような「スタックマッシング」技術を使用して標準に準拠したCプログラムを取得することが可能になるようです（大きな定数サイズの配列を使用したり、カーネルに知らせずに大量のallocaメモリを割り当てたり、mallocカーネルはメモリが割り当てられたかどうかを知らないので、配列への書き込みは「mallocd領域の内容を変更できます」を使用して大きな配列内のメモリを取得します。