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
Signed-off-by: Jerome Forissier <jerome@forissier.org>
---
hw/arm/virt.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 7dc96abf72c..42a6f84086f 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -77,6 +77,7 @@
#include "hw/acpi/generic_event_device.h"
#include "hw/virtio/virtio-iommu.h"
#include "hw/char/pl011.h"
+#include "crypto/random.h"
#define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \
static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
@@ -1635,6 +1636,18 @@ static void finalize_gic_version(VirtMachineState *vms)
}
}
+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;
+ }
+ qemu_fdt_setprop_u64(vms->fdt, "/secure-chosen", "kaslr-seed", seed);
+}
+
static void machvirt_init(MachineState *machine)
{
VirtMachineState *vms = VIRT_MACHINE(machine);
@@ -1837,6 +1850,7 @@ static void machvirt_init(MachineState *machine)
if (vms->secure) {
create_secure_ram(vms, secure_sysmem);
create_uart(vms, VIRT_SECURE_UART, secure_sysmem, serial_hd(1));
+ create_secure_kaslr_seed(vms);
}
vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64);
--
2.20.1
On Fri, 10 Apr 2020 at 18:02, Jerome Forissier <jerome@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 <jerome@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? > + qemu_fdt_setprop_u64(vms->fdt, "/secure-chosen", "kaslr-seed", seed); > +} > + > static void machvirt_init(MachineState *machine) > { > VirtMachineState *vms = VIRT_MACHINE(machine); > @@ -1837,6 +1850,7 @@ static void machvirt_init(MachineState *machine) > if (vms->secure) { > create_secure_ram(vms, secure_sysmem); > create_uart(vms, VIRT_SECURE_UART, secure_sysmem, serial_hd(1)); > + create_secure_kaslr_seed(vms); This is implicitly relying on create_uart() having created the "/secure-chosen" node. I think it would be better now that we have multiple things we might want to put there if we just pulled the "create /secure-chosen" code out to the create_fdt() function so we do it at the same place we create "/chosen". (You can do that as a simple patch of its own that comes before this one in the patchseries.) > } > > vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64); thanks -- PMM
On 17.04.2020 13:18, Peter Maydell wrote: > On Fri, 10 Apr 2020 at 18:02, Jerome Forissier <jerome@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 <jerome@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. > >> + qemu_fdt_setprop_u64(vms->fdt, "/secure-chosen", "kaslr-seed", seed); >> +} >> + >> static void machvirt_init(MachineState *machine) >> { >> VirtMachineState *vms = VIRT_MACHINE(machine); >> @@ -1837,6 +1850,7 @@ static void machvirt_init(MachineState *machine) >> if (vms->secure) { >> create_secure_ram(vms, secure_sysmem); >> create_uart(vms, VIRT_SECURE_UART, secure_sysmem, serial_hd(1)); >> + create_secure_kaslr_seed(vms); > This is implicitly relying on create_uart() having created > the "/secure-chosen" node. I think it would be better now > that we have multiple things we might want to put there if we > just pulled the "create /secure-chosen" code out to the > create_fdt() function so we do it at the same place we > create "/chosen". (You can do that as a simple patch of its own > that comes before this one in the patchseries.) > >> } >> >> vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64); > thanks > -- PMM
On Fri, 17 Apr 2020 at 13:01, Pavel Dovgalyuk <dovgaluk@ispras.ru> wrote: > > > On 17.04.2020 13:18, Peter Maydell wrote: > > On Fri, 10 Apr 2020 at 18:02, Jerome Forissier <jerome@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 <jerome@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
© 2016 - 2024 Red Hat, Inc.