[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] hw/misc: Add Exynos4210 Pseudo Random Number
Re: [Qemu-devel] [PATCH v2] hw/misc: Add Exynos4210 Pseudo Random Number Generator
Mon, 10 Apr 2017 16:15:42 +0100
On 4 April 2017 at 15:31, Krzysztof Kozlowski <address@hidden> wrote:
> On Tue, Apr 04, 2017 at 03:05:09PM +0100, Peter Maydell wrote:
>> On 4 April 2017 at 14:44, Krzysztof Kozlowski <address@hidden> 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 :-)