Re: amd64: kernel aslr support

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Oct 5,  8:30pm, Thor Lancelot Simon wrote:
}
} >  * The RNG is not really strong. Help in this area would be greatly
} >    appreciated.
} 
} This is tricky mostly because once you start probing for hardware
} devices or even CPU features, you're going to find yourself wanting
} more and more of the support you'd get from the "real kernel".
} 
} For example, to probe for RDRAND support on the CPU, you need a
} whole pile of CPU feature decoding.  To probe for environmental
} sensors or an audio device you may need to know a whole pile about
} ACPI and/or PCI.  And so forth.
} 
} EFI has a RNG API, but I think it's usually just stubbed out and
} besides, you can't rely on having EFI...

     It does, but it isn't listed as a runtime service, so likely
isn't available after ExitBootServices() is called, which would be
called by efiboot.

} I think I'd suggest some combination of:
} 
} 	* Just enough CPU-feature support to find/use RDRAND
} 	  (Intel's sample code is not that big and I think it's
} 	   suitably-licensed)
} 
} 	* Hash the contents of the "CMOS RAM" and/or EFI boot variables

     We currently have no support, of which I'm aware, for accessing
EFI bot variables.

} 	* Maybe poke around for an IPMI BMC (has environmental sensors),
} 	  or a TPM (has a RNG) on the LPC bus
} 
} 	* Maybe poke around for on-die temperature/voltage sensors
} 	  (will again require some CPU identification support).
} 
} 	* Rather than just using rdtsc once, consider using rdtsc to
} 	  "time" multiple hardware oscillators against one another;
} 	  at the very least, you've always got the hardware clock.
} 
} 	* Also, you can use rdtsc to time memory accesses.
} 
} For quick and dirty "entropy extraction", you can crunch as much of this
} data as you're able to connect together using SHA512.
} 
} I know, little or none of this is easy.
} 
} Thor
}-- End of excerpt from Thor Lancelot Simon