On Fri, 17 Apr 2020 at 13:01, Pavel Dovgalyuk <dovga...@ispras.ru> wrote: > > > On 17.04.2020 13:18, Peter Maydell wrote: > > On Fri, 10 Apr 2020 at 18:02, Jerome Forissier <jer...@forissier.org> wrote: > >> This commit generates a random seed to be used by the secure OS for > >> ASLR when the machine is secure. The seed is a 64-bit random value > >> exported via the DT in /secure-chosen/kaslr-seed. This interface is > >> used by OP-TEE [1]. > >> > >> [1] https://github.com/OP-TEE/optee_os/commit/ef262691fe0e > > The kernel devicetree documentation documents this as a generic > > property of /chosen -- should we be providing a /chosen/kaslr-seed > > too ? > > > >> Signed-off-by: Jerome Forissier <jer...@forissier.org> > >> --- > >> +static void create_secure_kaslr_seed(VirtMachineState *vms) > >> +{ > >> + Error *err = NULL; > >> + uint64_t seed; > >> + > >> + if (qcrypto_random_bytes(&seed, sizeof(seed), &err)) { > >> + error_free(err); > >> + return; > >> + } > > Since this is exposed to the guest I'm wondering if we should > > use qemu_guest_getrandom() (which lets you make the randomness > > deterministic for the benefit of record-and-replay). But I'm > > not sure if that function is usable before the guest has even > > started running. Pavel, could you answer that? > > Yes, usage of deterministic functions is possible before machine is running, > > because replay_configure is executed before machine initialization.
Great, thanks. Sonuds like we should use qemu_guest_getrandom() then. -- PMM
