Add emulation for Exynos4210 Pseudo Random Number Generator which could
work on fixed seeds or with seeds provided by True Random Number
Generator block inside the SoC.

Implement only the fixed seeds part of it in polling mode (no
interrupts).  Simple testing:
    # echo "exynos" > /sys/class/misc/hw_random/rng_current
    # dd if=/dev/hwrng of=/dev/null bs=1 count=16

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>

---

Changes since v1:
1. Use GRand-like functions to fix build on MingW32 (this adds also
   finalize).
2. Add DPRINTF macro.
3. Use HWADDR_PRIx and family for printing values.
---
 hw/arm/exynos4210.c      |   4 +
 hw/misc/Makefile.objs    |   2 +-
 hw/misc/exynos4210_rng.c | 303 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 308 insertions(+), 1 deletion(-)
 create mode 100644 hw/misc/exynos4210_rng.c

diff --git a/hw/arm/exynos4210.c b/hw/arm/exynos4210.c
index 1d2b50cc4eea..0ec4250f0c05 100644
--- a/hw/arm/exynos4210.c
+++ b/hw/arm/exynos4210.c
@@ -78,6 +78,9 @@
 /* Clock controller SFR base address */
 #define EXYNOS4210_CLK_BASE_ADDR            0x10030000
 
+/* PRNG/HASH SFR base address */
+#define EXYNOS4210_RNG_BASE_ADDR            0x10830400
+
 /* Display controllers (FIMD) */
 #define EXYNOS4210_FIMD0_BASE_ADDR          0x11C00000
 
@@ -314,6 +317,7 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem,
     sysbus_create_simple("exynos4210.pmu", EXYNOS4210_PMU_BASE_ADDR, NULL);
 
     sysbus_create_simple("exynos4210.clk", EXYNOS4210_CLK_BASE_ADDR, NULL);
+    sysbus_create_simple("exynos4210.rng", EXYNOS4210_RNG_BASE_ADDR, NULL);
 
     /* PWM */
     sysbus_create_varargs("exynos4210.pwm", EXYNOS4210_PWM_BASE_ADDR,
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index c8b489390f7e..e0699ea11155 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -26,7 +26,7 @@ obj-$(CONFIG_IVSHMEM) += ivshmem.o
 obj-$(CONFIG_REALVIEW) += arm_sysctl.o
 obj-$(CONFIG_NSERIES) += cbus.o
 obj-$(CONFIG_ECCMEMCTL) += eccmemctl.o
-obj-$(CONFIG_EXYNOS4) += exynos4210_pmu.o exynos4210_clk.o
+obj-$(CONFIG_EXYNOS4) += exynos4210_pmu.o exynos4210_clk.o exynos4210_rng.o
 obj-$(CONFIG_IMX) += imx_ccm.o
 obj-$(CONFIG_IMX) += imx31_ccm.o
 obj-$(CONFIG_IMX) += imx25_ccm.o
diff --git a/hw/misc/exynos4210_rng.c b/hw/misc/exynos4210_rng.c
new file mode 100644
index 000000000000..09b3751fe76a
--- /dev/null
+++ b/hw/misc/exynos4210_rng.c
@@ -0,0 +1,303 @@
+/*
+ *  Exynos4210 Pseudo Random Nubmer Generator Emulation
+ *
+ *  Copyright (c) 2017 Krzysztof Kozlowski <krzk@kernel.org>
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License as published by the
+ *  Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful, but WITHOUT
+ *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ *  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ *  for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/sysbus.h"
+#include "qemu/log.h"
+
+#define DEBUG_EXYNOS_RNG 0
+
+#define DPRINTF(fmt, ...) \
+    do { \
+        if (DEBUG_EXYNOS_RNG) { \
+            printf("exynos4210_rng: " fmt, ## __VA_ARGS__); \
+        } \
+    } while (0)
+
+#define TYPE_EXYNOS4210_RNG             "exynos4210.rng"
+#define EXYNOS4210_RNG(obj) \
+    OBJECT_CHECK(Exynos4210RngState, (obj), TYPE_EXYNOS4210_RNG)
+
+/*
+ * Exynos4220, PRNG, only polling mode is supported.
+ */
+
+/* RNG_CONTROL_1 register bitfields, reset value: 0x0 */
+#define EXYNOS4210_RNG_CONTROL_1_PRNG           0x8
+#define EXYNOS4210_RNG_CONTROL_1_START_INIT     BIT(4)
+/* RNG_STATUS register bitfields, reset value: 0x1 */
+#define EXYNOS4210_RNG_STATUS_PRNG_ERROR        BIT(7)
+#define EXYNOS4210_RNG_STATUS_PRNG_DONE         BIT(5)
+#define EXYNOS4210_RNG_STATUS_MSG_DONE          BIT(4)
+#define EXYNOS4210_RNG_STATUS_PARTIAL_DONE      BIT(3)
+#define EXYNOS4210_RNG_STATUS_PRNG_BUSY         BIT(2)
+#define EXYNOS4210_RNG_STATUS_SEED_SETTING_DONE BIT(1)
+#define EXYNOS4210_RNG_STATUS_BUFFER_READY      BIT(0)
+#define EXYNOS4210_RNG_STATUS_WRITE_MASK        (EXYNOS4210_RNG_STATUS_PRNG_DONE \
+                                                    | EXYNOS4210_RNG_STATUS_MSG_DONE \
+                                                    | EXYNOS4210_RNG_STATUS_PARTIAL_DONE)
+
+#define EXYNOS4210_RNG_CONTROL_1                  0x0
+#define EXYNOS4210_RNG_STATUS                    0x10
+#define EXYNOS4210_RNG_SEED_IN                  0x140
+#define EXYNOS4210_RNG_SEED_IN_OFFSET(n)        (EXYNOS4210_RNG_SEED_IN + (n * 0x4))
+#define EXYNOS4210_RNG_PRNG                     0x160
+#define EXYNOS4210_RNG_PRNG_OFFSET(n)           (EXYNOS4210_RNG_PRNG + (n * 0x4))
+
+#define EXYNOS4210_RNG_PRNG_NUM                 5
+
+#define EXYNOS4210_RNG_REGS_MEM_SIZE            0x200
+
+typedef struct Exynos4210RngState {
+    SysBusDevice parent_obj;
+    MemoryRegion iomem;
+
+    GRand *grand[EXYNOS4210_RNG_PRNG_NUM];
+    int32_t randr_value[EXYNOS4210_RNG_PRNG_NUM];
+    uint32_t seeds[EXYNOS4210_RNG_PRNG_NUM];
+
+    /* Register values */
+    uint32_t reg_control;
+    uint32_t reg_status;
+} Exynos4210RngState;
+
+static bool exynos4210_rng_seed_ready(const Exynos4210RngState *s)
+{
+    unsigned int i;
+
+    for (i = 0; i < EXYNOS4210_RNG_PRNG_NUM; i++) {
+        /*
+         * Assuming 0 as invalid (uninitialized) seed value.
+         * This also matches the reset value for SEED registers.
+         */
+        if (!s->seeds[i]) {
+            return false;
+        }
+    }
+
+    return true;
+}
+
+static void exynos4210_rng_set_seed(Exynos4210RngState *s, unsigned int i,
+                                    uint64_t val)
+{
+    s->seeds[i] = val & UINT32_MAX;
+    if (s->grand[i]) {
+        g_rand_free(s->grand[i]);
+    }
+    s->grand[i] = g_rand_new_with_seed(s->seeds[i]);
+
+    /* If all seeds were written, update the status to reflect it */
+    if (exynos4210_rng_seed_ready(s)) {
+        s->reg_status |= EXYNOS4210_RNG_STATUS_SEED_SETTING_DONE;
+    } else {
+        s->reg_status &= ~EXYNOS4210_RNG_STATUS_SEED_SETTING_DONE;
+    }
+}
+
+static void exynos4210_rng_run_engine(Exynos4210RngState *s)
+{
+    unsigned int i;
+
+    /* Seed set? */
+    if ((s->reg_status & EXYNOS4210_RNG_STATUS_SEED_SETTING_DONE) == 0) {
+        goto out;
+    }
+
+    /* PRNG engine chosen? */
+    if ((s->reg_control & EXYNOS4210_RNG_CONTROL_1_PRNG) == 0) {
+        goto out;
+    }
+
+    /* PRNG engine started? */
+    if ((s->reg_control & EXYNOS4210_RNG_CONTROL_1_START_INIT) == 0) {
+        goto out;
+    }
+
+    /* Get randoms */
+    for (i = 0; i < EXYNOS4210_RNG_PRNG_NUM; i++) {
+        s->randr_value[i] = g_rand_int(s->grand[i]);
+    }
+
+    /* Notify that PRNG is ready */
+    s->reg_status |= EXYNOS4210_RNG_STATUS_PRNG_DONE;
+
+out:
+    /* Always clear start engine bit */
+    s->reg_control &= ~EXYNOS4210_RNG_CONTROL_1_START_INIT;
+}
+
+static uint64_t exynos4210_rng_read(void *opaque, hwaddr offset,
+                                    unsigned size)
+{
+    Exynos4210RngState *s = (Exynos4210RngState *)opaque;
+    uint32_t val = 0;
+
+    assert(size == 4);
+
+    switch (offset) {
+    case EXYNOS4210_RNG_CONTROL_1:
+        val = s->reg_control;
+        break;
+
+    case EXYNOS4210_RNG_STATUS:
+        val = s->reg_status;
+        break;
+
+    case EXYNOS4210_RNG_PRNG_OFFSET(0):
+    case EXYNOS4210_RNG_PRNG_OFFSET(1):
+    case EXYNOS4210_RNG_PRNG_OFFSET(2):
+    case EXYNOS4210_RNG_PRNG_OFFSET(3):
+    case EXYNOS4210_RNG_PRNG_OFFSET(4):
+        val = s->randr_value[(offset - EXYNOS4210_RNG_PRNG_OFFSET(0)) / 4];
+        DPRINTF("returning random @0x%" HWADDR_PRIx ": 0x%" PRIx32 "\n",
+                offset, val);
+        break;
+
+    default:
+        qemu_log_mask(LOG_GUEST_ERROR,
+                      "%s: bad read offset 0x%" HWADDR_PRIx "\n",
+                      __func__, offset);
+    }
+
+    return val;
+}
+
+static void exynos4210_rng_write(void *opaque, hwaddr offset,
+                                 uint64_t val, unsigned size)
+{
+    Exynos4210RngState *s = (Exynos4210RngState *)opaque;
+
+    assert(size == 4);
+
+    switch (offset) {
+    case EXYNOS4210_RNG_CONTROL_1:
+        DPRINTF("RNG_CONTROL_1 = 0x%" PRIx64 "\n", val);
+        s->reg_control = val;
+        exynos4210_rng_run_engine(s);
+        break;
+
+    case EXYNOS4210_RNG_STATUS:
+        /* For clearing status fields */
+        s->reg_status &= ~EXYNOS4210_RNG_STATUS_WRITE_MASK;
+        s->reg_status |= val & EXYNOS4210_RNG_STATUS_WRITE_MASK;
+        break;
+
+    case EXYNOS4210_RNG_SEED_IN_OFFSET(0):
+    case EXYNOS4210_RNG_SEED_IN_OFFSET(1):
+    case EXYNOS4210_RNG_SEED_IN_OFFSET(2):
+    case EXYNOS4210_RNG_SEED_IN_OFFSET(3):
+    case EXYNOS4210_RNG_SEED_IN_OFFSET(4):
+        exynos4210_rng_set_seed(s,
+                                (offset - EXYNOS4210_RNG_SEED_IN_OFFSET(0)) / 4,
+                                val);
+        break;
+
+    default:
+        qemu_log_mask(LOG_GUEST_ERROR,
+                      "%s: bad write offset 0x%" HWADDR_PRIx "\n",
+                      __func__, offset);
+    }
+}
+
+static const MemoryRegionOps exynos4210_rng_ops = {
+    .read = exynos4210_rng_read,
+    .write = exynos4210_rng_write,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void exynos4210_rng_free_grand(Exynos4210RngState *s)
+{
+    unsigned int i;
+
+    for (i = 0; i < EXYNOS4210_RNG_PRNG_NUM; i++) {
+        if (s->grand[i]) {
+            g_rand_free(s->grand[i]);
+            s->grand[i] = NULL;
+        }
+    }
+}
+
+static void exynos4210_rng_reset(DeviceState *dev)
+{
+    Exynos4210RngState *s = EXYNOS4210_RNG(dev);
+
+    s->reg_control = 0;
+    s->reg_status = EXYNOS4210_RNG_STATUS_BUFFER_READY;
+    memset(s->seeds, 0, EXYNOS4210_RNG_PRNG_NUM * sizeof(*(s->seeds)));
+    memset(s->seeds, 0, EXYNOS4210_RNG_PRNG_NUM * sizeof(*(s->randr_value)));
+
+    exynos4210_rng_free_grand(s);
+}
+
+static void exynos4210_rng_init(Object *obj)
+{
+    Exynos4210RngState *s = EXYNOS4210_RNG(obj);
+    SysBusDevice *dev = SYS_BUS_DEVICE(obj);
+
+    memory_region_init_io(&s->iomem, obj, &exynos4210_rng_ops, s,
+                          TYPE_EXYNOS4210_RNG, EXYNOS4210_RNG_REGS_MEM_SIZE);
+    sysbus_init_mmio(dev, &s->iomem);
+}
+
+static void exynos4210_rng_finalize(Object *obj)
+{
+    Exynos4210RngState *s = EXYNOS4210_RNG(obj);
+
+    exynos4210_rng_free_grand(s);
+}
+
+static const VMStateDescription exynos4210_rng_vmstate = {
+    .name = TYPE_EXYNOS4210_RNG,
+    .version_id = 1,
+    .minimum_version_id = 1,
+    .fields = (VMStateField[]) {
+        VMSTATE_INT32_ARRAY(randr_value, Exynos4210RngState,
+                            EXYNOS4210_RNG_PRNG_NUM),
+        VMSTATE_UINT32_ARRAY(seeds, Exynos4210RngState,
+                             EXYNOS4210_RNG_PRNG_NUM),
+        VMSTATE_UINT32(reg_status, Exynos4210RngState),
+        VMSTATE_UINT32(reg_control, Exynos4210RngState),
+        VMSTATE_END_OF_LIST()
+    }
+};
+
+static void exynos4210_rng_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+
+    dc->reset = exynos4210_rng_reset;
+    dc->vmsd = &exynos4210_rng_vmstate;
+}
+
+static const TypeInfo exynos4210_rng_info = {
+    .name          = TYPE_EXYNOS4210_RNG,
+    .parent        = TYPE_SYS_BUS_DEVICE,
+    .instance_size = sizeof(Exynos4210RngState),
+    .instance_init = exynos4210_rng_init,
+    .instance_finalize  = exynos4210_rng_finalize,
+    .class_init    = exynos4210_rng_class_init,
+};
+
+static void exynos4210_rng_register(void)
+{
+    type_register_static(&exynos4210_rng_info);
+}
+
+type_init(exynos4210_rng_register)
-- 
2.9.3

On 18 March 2017 at 19:25, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Add emulation for Exynos4210 Pseudo Random Number Generator which could
> work on fixed seeds or with seeds provided by True Random Number
> Generator block inside the SoC.
>
> Implement only the fixed seeds part of it in polling mode (no
> interrupts).  Simple testing:
>     # echo "exynos" > /sys/class/misc/hw_random/rng_current
>     # dd if=/dev/hwrng of=/dev/null bs=1 count=16
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Changes since v1:
> 1. Use GRand-like functions to fix build on MingW32 (this adds also
>    finalize).
> 2. Add DPRINTF macro.
> 3. Use HWADDR_PRIx and family for printing values.

Is there a data sheet that describes this RNG? I had a quick google
but couldn't find anything in the 4210 manual you can get from Samsung.

In particular I'm not sure we want to use GRand here.

thanks
-- PMM

On Tue, Apr 04, 2017 at 01:09:08PM +0100, Peter Maydell wrote:
> On 18 March 2017 at 19:25, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > Add emulation for Exynos4210 Pseudo Random Number Generator which could
> > work on fixed seeds or with seeds provided by True Random Number
> > Generator block inside the SoC.
> >
> > Implement only the fixed seeds part of it in polling mode (no
> > interrupts).  Simple testing:
> >     # echo "exynos" > /sys/class/misc/hw_random/rng_current
> >     # dd if=/dev/hwrng of=/dev/null bs=1 count=16
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > ---
> >
> > Changes since v1:
> > 1. Use GRand-like functions to fix build on MingW32 (this adds also
> >    finalize).
> > 2. Add DPRINTF macro.
> > 3. Use HWADDR_PRIx and family for printing values.
> 
> Is there a data sheet that describes this RNG? I had a quick google
> but couldn't find anything in the 4210 manual you can get from Samsung.

Official and public datasheet - I never heard about it... AFAIK, Samsung
never released any datasheet... But recently I found a copy of
Exynos4412 datasheet published on FriendlyArm website:
http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T1
(at the bottom in "Resources").

Some blocks in Exynos4412, including the RNG, are the same as in
Exynos4210. However, you should not expect too much data about the RNG
in the datasheet...

> In particular I'm not sure we want to use GRand here.

Now, I am not sure neither. :) Let me describe the background:

Recently I started also improving the Linux kernel driver for RNG module
which ended in writing a new driver followed by discussions
from which I learnt a lot. See [1][2][3]

The datasheet is not saying too much how the RNG module works inside...
so it is all a guessing. I must admit that I wrote the QEMU RNG part mostly
looking at behavior of kernel driver and combining the knowledge with
information obtained from datasheet. Thus I used GRand to have
repeatable sequences for same seed.

During the discussions about new kernel driver, I found that this RNG
module (at least on Exynos4412 board) requires seeding but it is not
following the Pseudo RNG behavior - seeding with the same value produces
different results. This means that GRand would not be needed here.

The new driver (not merged yet) took this into account and it behaves
differently than previous one. Most notably it tries to be a better pseudo
random number generator in terms of randomness.

I did not test the new kernel driver with this QEMU RNG driver because
it uses different user-space API and I still did not configure full
Linux box in QEMU (mounting root, having some distro in the image). I am
booting the QEMU kernel to initramfs with some toolset included.

[1] https://www.spinics.net/lists/kernel/msg2474154.html
[2] https://www.spinics.net/lists/arm-kernel/msg571653.html
[3] https://www.spinics.net/lists/arm-kernel/msg571516.html


Best regards,
Krzysztof

On 4 April 2017 at 14:44, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Apr 04, 2017 at 01:09:08PM +0100, Peter Maydell wrote:
>> On 18 March 2017 at 19:25, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > Add emulation for Exynos4210 Pseudo Random Number Generator which could
>> > work on fixed seeds or with seeds provided by True Random Number
>> > Generator block inside the SoC.
>> >
>> > Implement only the fixed seeds part of it in polling mode (no
>> > interrupts).  Simple testing:
>> >     # echo "exynos" > /sys/class/misc/hw_random/rng_current
>> >     # dd if=/dev/hwrng of=/dev/null bs=1 count=16
>> >
>> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>> >
>> > ---
>> >
>> > Changes since v1:
>> > 1. Use GRand-like functions to fix build on MingW32 (this adds also
>> >    finalize).
>> > 2. Add DPRINTF macro.
>> > 3. Use HWADDR_PRIx and family for printing values.
>>
>> Is there a data sheet that describes this RNG? I had a quick google
>> but couldn't find anything in the 4210 manual you can get from Samsung.
>
> Official and public datasheet - I never heard about it... AFAIK, Samsung
> never released any datasheet... But recently I found a copy of
> Exynos4412 datasheet published on FriendlyArm website:
> http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T1
> (at the bottom in "Resources").
>
> Some blocks in Exynos4412, including the RNG, are the same as in
> Exynos4210. However, you should not expect too much data about the RNG
> in the datasheet...
>
>> In particular I'm not sure we want to use GRand here.
>
> Now, I am not sure neither. :)

The last RNG we added was hw/misc/bcm2835_rng.c, which uses
qcrypto_random_bytes() to get cryptographically-random bytes
from the host. On the other hand it sounds like this Exynos
hardware is a PRNG without true-random input...

> During the discussions about new kernel driver, I found that this RNG
> module (at least on Exynos4412 board) requires seeding but it is not
> following the Pseudo RNG behavior - seeding with the same value produces
> different results. This means that GRand would not be needed here.

That's rather odd. You're right that the datasheet is hopelessly
uninformative about what's actually going on.

thanks
-- PMM

On Tue, Apr 04, 2017 at 03:05:09PM +0100, Peter Maydell wrote:
> On 4 April 2017 at 14:44, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Tue, Apr 04, 2017 at 01:09:08PM +0100, Peter Maydell wrote:
> >> On 18 March 2017 at 19:25, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> > Add emulation for Exynos4210 Pseudo Random Number Generator which could
> >> > work on fixed seeds or with seeds provided by True Random Number
> >> > Generator block inside the SoC.
> >> >
> >> > Implement only the fixed seeds part of it in polling mode (no
> >> > interrupts).  Simple testing:
> >> >     # echo "exynos" > /sys/class/misc/hw_random/rng_current
> >> >     # dd if=/dev/hwrng of=/dev/null bs=1 count=16
> >> >
> >> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >> >
> >> > ---
> >> >
> >> > Changes since v1:
> >> > 1. Use GRand-like functions to fix build on MingW32 (this adds also
> >> >    finalize).
> >> > 2. Add DPRINTF macro.
> >> > 3. Use HWADDR_PRIx and family for printing values.
> >>
> >> Is there a data sheet that describes this RNG? I had a quick google
> >> but couldn't find anything in the 4210 manual you can get from Samsung.
> >
> > Official and public datasheet - I never heard about it... AFAIK, Samsung
> > never released any datasheet... But recently I found a copy of
> > Exynos4412 datasheet published on FriendlyArm website:
> > http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T1
> > (at the bottom in "Resources").
> >
> > Some blocks in Exynos4412, including the RNG, are the same as in
> > Exynos4210. However, you should not expect too much data about the RNG
> > in the datasheet...
> >
> >> In particular I'm not sure we want to use GRand here.
> >
> > Now, I am not sure neither. :)
> 
> The last RNG we added was hw/misc/bcm2835_rng.c, which uses
> qcrypto_random_bytes() to get cryptographically-random bytes
> from the host. On the other hand it sounds like this Exynos
> hardware is a PRNG without true-random input...

Yes, I think that is the case. The PRNG block looks the same on all
Exynos SoCs. At least from datasheet perspective and registers.
The difference came with Exynos5420 with introducing another block -
True RNG - which could be chained to PRNG as seed. However the PRNG
stays the same (according to datasheet).

Unfortunately I could not verify too much of this because on Exynos5420
apparently the PRNG block is locked by SecureMonitor.

At some point I will probably get back to Exynos5420 (and True RNG) but
till then, the choice of GRand repeatable random sequences makes some
sense to me.

The remaining issue with this QEMU patch, brought to light during
discussions on LKML, is that it does not accept multiple seeds. From
what I understood, a good PRNG should be able to consume more seeds
at one pass (into same registers) thus. In other words these cases
should produce different results:
1. Seed(a), random
2. Seed(b), Seed(a), random

As of now, I think GRand will not allow this.

The hardware on Exynos4412 behaves like this plus it generates random
numbers even for the same seed after reboot (which could mean that it
was seeded by bootloader or Secure OS).

Best regards,
Krzysztof

On 4 April 2017 at 15:31, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Apr 04, 2017 at 03:05:09PM +0100, Peter Maydell wrote:
>> On 4 April 2017 at 14:44, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > On Tue, Apr 04, 2017 at 01:09:08PM +0100, Peter Maydell wrote:
>> >> Is there a data sheet that describes this RNG? I had a quick google
>> >> but couldn't find anything in the 4210 manual you can get from Samsung.
>> >
>> > Official and public datasheet - I never heard about it... AFAIK, Samsung
>> > never released any datasheet... But recently I found a copy of
>> > Exynos4412 datasheet published on FriendlyArm website:
>> > http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T1
>> > (at the bottom in "Resources").
>> >
>> > Some blocks in Exynos4412, including the RNG, are the same as in
>> > Exynos4210. However, you should not expect too much data about the RNG
>> > in the datasheet...
>> >
>> >> In particular I'm not sure we want to use GRand here.
>> >
>> > Now, I am not sure neither. :)
>>
>> The last RNG we added was hw/misc/bcm2835_rng.c, which uses
>> qcrypto_random_bytes() to get cryptographically-random bytes
>> from the host. On the other hand it sounds like this Exynos
>> hardware is a PRNG without true-random input...
>
> Yes, I think that is the case. The PRNG block looks the same on all
> Exynos SoCs. At least from datasheet perspective and registers.
> The difference came with Exynos5420 with introducing another block -
> True RNG - which could be chained to PRNG as seed. However the PRNG
> stays the same (according to datasheet).
>
> Unfortunately I could not verify too much of this because on Exynos5420
> apparently the PRNG block is locked by SecureMonitor.
>
> At some point I will probably get back to Exynos5420 (and True RNG) but
> till then, the choice of GRand repeatable random sequences makes some
> sense to me.

I was talking to Dan on IRC and his suggestion was that we should just
use qcrypto_random_bytes() for everything. On the other hand I'm
not totally sure that's the right approach.

I think my core issue here is that we really don't understand what
the hardware is doing or what the properties of its randomness
actually are. To me that says "Linux should not trust this thing
at all and shouldn't use it" which in turn makes implementing a
model in QEMU less important :-)

thanks
-- PMM

On Mon, Apr 10, 2017 at 5:15 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 4 April 2017 at 15:31, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Apr 04, 2017 at 03:05:09PM +0100, Peter Maydell wrote:
>>> On 4 April 2017 at 14:44, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>> > On Tue, Apr 04, 2017 at 01:09:08PM +0100, Peter Maydell wrote:
>>> >> Is there a data sheet that describes this RNG? I had a quick google
>>> >> but couldn't find anything in the 4210 manual you can get from Samsung.
>>> >
>>> > Official and public datasheet - I never heard about it... AFAIK, Samsung
>>> > never released any datasheet... But recently I found a copy of
>>> > Exynos4412 datasheet published on FriendlyArm website:
>>> > http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T1
>>> > (at the bottom in "Resources").
>>> >
>>> > Some blocks in Exynos4412, including the RNG, are the same as in
>>> > Exynos4210. However, you should not expect too much data about the RNG
>>> > in the datasheet...
>>> >
>>> >> In particular I'm not sure we want to use GRand here.
>>> >
>>> > Now, I am not sure neither. :)
>>>
>>> The last RNG we added was hw/misc/bcm2835_rng.c, which uses
>>> qcrypto_random_bytes() to get cryptographically-random bytes
>>> from the host. On the other hand it sounds like this Exynos
>>> hardware is a PRNG without true-random input...
>>
>> Yes, I think that is the case. The PRNG block looks the same on all
>> Exynos SoCs. At least from datasheet perspective and registers.
>> The difference came with Exynos5420 with introducing another block -
>> True RNG - which could be chained to PRNG as seed. However the PRNG
>> stays the same (according to datasheet).
>>
>> Unfortunately I could not verify too much of this because on Exynos5420
>> apparently the PRNG block is locked by SecureMonitor.
>>
>> At some point I will probably get back to Exynos5420 (and True RNG) but
>> till then, the choice of GRand repeatable random sequences makes some
>> sense to me.
>
> I was talking to Dan on IRC and his suggestion was that we should just
> use qcrypto_random_bytes() for everything. On the other hand I'm
> not totally sure that's the right approach.
>
> I think my core issue here is that we really don't understand what
> the hardware is doing or what the properties of its randomness
> actually are. To me that says "Linux should not trust this thing
> at all and shouldn't use it" which in turn makes implementing a
> model in QEMU less important :-)

That makes sense. I can only guess by experiments how the hardware
really behaves. As I wrote, it seems it is not a reproducible PRNG so
using qcrypto_random_bytes() should be fine.

I'll switch to that interface.

But first I need to setup proper booting image + rootfs instead of
only initramfs. The sdhci node is failing (missing regulators or
capabilities) so essentially there is no storage now.

How do you access any kind of disk image in case of other boards?

Best regards,
Krzysztof

On 11 April 2017 at 13:02, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> But first I need to setup proper booting image + rootfs instead of
> only initramfs. The sdhci node is failing (missing regulators or
> capabilities) so essentially there is no storage now.
>
> How do you access any kind of disk image in case of other boards?

Depends on the board, some of them have SD controllers, a few
have PCI controllers that can take a virtio or scsi controller.

thanks
-- PMM