3

process.cのarch_align_stack（）を変更して、モジュロの2番目の引数を次のように増やすことにより、自分のx8632ビットマシンでASLRを「改善」しようとしました。

if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
    sp -= get_random_int() % 8192;
return sp & ~0xf;

しかし、これを改ざんしすぎるとカーネルパニックが発生することにすぐに気付きました。そして、それを少し改ざんしただけでもシステムが不安定になるのではないかと思います（運が良ければしばらくは存続するでしょう？）。

これにより、なぜこれが発生するのかについて質問するようになりました（スタックをページ揃えする必要があるのはなぜですか？）。どうやらこれは、（ユーザー "mpe"が述べたように）8 kiBの場合のデフォルトのスタックサイズ（8192バイト）が原因です。それで、拡張によってカーネルのスタックサイズを増やすことによって、この引数（8192）を増やすことができるはずですか？また、スタック自体の場所をランダム化できることも言及されました。

Paxはこれを行いますか？そうでない場合は、なぜですか？

カーネルで指定されているスタックサイズはどのように/どこにありますか？これは32ビットと64ビットで異なりますか？

これについて、32ビットと64ビットの間に違いはありますか？64ビットはまだこのようなものにprocess.cを使用していますか？process_64.cには、このコードに相当するものは何もないようです。

4

1 に答える 1

3

バニラ カーネルでもスタックの場所はランダム化されます。スタックの場所をランダム化する関数load_elf_binary() が呼び出さ れることに注意してください。randomize_stack_top()この関数は、Linux スタック ASLR の主要部分です。

Linux カーネルでの ASLR の適切な説明は、ここにあります。おそらく主にセクションStack Randomizationに興味があるでしょう。

実際の主な目的はarch_align_stack()、HyperThreading または同様のテクノロジを使用して CPU のキャッシュ パフォーマンスを向上させることです。さらに、値 8129 が選択されたのは、スタック サイズ (カーネル スタック サイズは実際には 8K ですが、この関数はユーザー スタック アドレスをランダム化しています) のためではなく、Intel の推奨事項のためです。これとこれを参照してください。

THREAD_SIZEカーネル スタック サイズを指定します。ここで説明されているように、x86-32 と x86-64 の両方で 8Kです。ユーザーによって制限されない限り、スタックが大きくなる可能性があるため、ユーザースタックサイズは固定されていません。

arch/x86/kernel/process.c32 ビットと 64 ビットの両方に共通のコードが含まれています。arch/x86/kernel/process_64.cそのため、 (または)に同等のコードはありませんarch/x86/kernel/process_32.c。

于 2012-10-07T17:35:39.373 に答える