
Ich begann mitkaslr.cund fand heraus, dass es kaslr_get_random_long() verwendet, definiert inkaslr.h und umgesetzt inlib/kaslr.cwo es möglicherweise RDRAND (Intels Hardware-PRNG), einen Zeitstempel und zumindest einen System-Timer verwendet, um mehr Entropie zu erzeugen.
unsigned long raw, random = get_boot_seed();
bool use_i8254 = true;
debug_putstr(purpose);
debug_putstr(" KASLR using");
if (has_cpuflag(X86_FEATURE_RDRAND)) {
debug_putstr(" RDRAND");
if (rdrand_long(&raw)) {
random ^= raw;
use_i8254 = false;
}
}
if (has_cpuflag(X86_FEATURE_TSC)) {
debug_putstr(" RDTSC");
raw = rdtsc();
random ^= raw;
use_i8254 = false;
}
if (use_i8254) {
debug_putstr(" i8254");
random ^= i8254();
}
Der zurückgegebene Wert wird durch eine zirkuläre ASM-Multiplikation etwas gestreut.
/* Circular multiply for better bit diffusion */
asm(_ASM_MUL "%3"
: "=a" (random), "=d" (raw)
: "a" (random), "rm" (mix_const));
random += raw;
get_boot_seed scheint ein sehr einfacher linearer XOR-PRNG auf einem Hash zu sein, der auf statisch 0 gesetzt ist. Es verwendet ein sehr einfaches XOR, das auf Kernel-Boot-Parametern basiert.
/* Attempt to create a simple but unpredictable starting entropy. */
static unsigned long get_boot_seed(void)
{
unsigned long hash = 0;
hash = rotate_xor(hash, build_str, sizeof(build_str));
hash = rotate_xor(hash, boot_params, sizeof(*boot_params));
return hash;
}
Dies scheint ein „gut genug“-Ansatz zu sein, und ich frage mich, ob eine andere Distribution ihn gepatcht hat, um einen stärkeren CSPRNG zu verwenden? Als Kompromiss zwischen Leistung und Sicherheit kann ich die Wahl verstehen. Ich bin mir jedoch ziemlich sicher, dass jemand dies bereits gepatcht haben muss, um mehr Optionen für gehärtete Kernel zu ermöglichen.