On 18/09/2017 7:59 pm, "Christian Gagneraud" <chg...@gmail.com <mailto:chg...@gmail.com>> wrote:



    On 18/09/2017 7:34 pm, "Sami Nurmenniemi" <sami.nurmenni...@qt.io
    <mailto:sami.nurmenni...@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.


The point of mentioning the 1.2s demo was an answer to the statement "I wasn't worried about Qt on real devices because I don't expect it to be run early enough to matter." Maybe the demo application (being the only user space process) needs to make the connection between hwrng + random pool or preserve entropy over reboots.

_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to