[Interest] [Development] QRandomGenerator and boot times

[Christian Gagneraud]

[adding back to the mailing list]



On 18/09/2017 7:59 pm, "Christian Gagneraud" <chgans at gmail.com> wrote:



On 18/09/2017 7:34 pm, "Sami Nurmenniemi" <sami.nurmenniemi at qt.io> wrote:

On 15.09.2017 18:21, Thiago Macieira wrote:

> On Friday, 15 September 2017 00:31:36 PDT Sami Nurmenniemi wrote:
>
>> I think we'll just have to accept blocking for the devices without
>> hwrng. I don't know if we really support any such devices. If we do and
>> boot time is essential for those, we'll have to figure out some way
>> (probably saving entropy over reboot).
>>
> And that would be a non-Qt job. I wasn't worried about Qt on real devices
> because I don't expect it to be run early enough to matter.  On VMs, that's
> another story, and if you don't trust your undercloud-provided /dev/hwrng,
> why
> are you using that cloud? (Though I'll say there's an Intel team working on
> figuring out how a VM can get trust from the actual hardware, skipping the
> hypervisor trust)
>
We have made some safety critical customer demos where fast boot time of Qt
framework is essential. It was demoing boot time of 1.2s for a Qt
application to start after powering on the device. I suppose that demo (and
real safety critical use cases) is going to have problems with the
QRandomGenerator even with hwrng in use.



So basically, you have artificially "optimised" boot time by ignoring
entropy management and now you're blaming QRandomGenerator. You can do one
or the other, not both.

Me too I can make a device boot in less than a second, but then don't be
surprised if some features are missing/buggy....

This sound very much like a beginner mistake, where boot time takes over
functionality. Every one can boot an unfunctional device in less than a
second. This is nothing new.

Respectfully yours,
Chris




> Anyway, I've read the entire Python thread to figure out what their
> conclusion
> was. Turns out, after spending hours reading everything, the bug ends
> without
> a conclusion. It must have been concluded, but it's not recorded in the bug
> report!
>
>
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20170918/fd715019/attachment.html>