On Thu, Mar 14, 2019 at 09:23:12AM -0700, Richard Henderson wrote:
> On 3/14/19 9:15 AM, Daniel P. Berrangé wrote:
> > So far best alternative is 'qemu_traceable_random' / tracable-random.h
> > but its a bit of a verbose name.
>
> How about qemu_guest_getrandom / guest-random.h?
Yeah, that's ok w
On 3/14/19 9:15 AM, Daniel P. Berrangé wrote:
> So far best alternative is 'qemu_traceable_random' / tracable-random.h
> but its a bit of a verbose name.
How about qemu_guest_getrandom / guest-random.h?
r~
On Thu, Mar 14, 2019 at 09:06:42AM -0700, Richard Henderson wrote:
> On 3/14/19 2:54 AM, Daniel P. Berrangé wrote:
> > The random interfact is pluggable with different impls though they are
> > chosen at build time currently. I guess we could provide an impl that
> > is backed by a deterministic so
On 3/14/19 2:54 AM, Daniel P. Berrangé wrote:
> The random interfact is pluggable with different impls though they are
> chosen at build time currently. I guess we could provide an impl that
> is backed by a deterministic source and require a special CLI option or
> env var to switch to this insecu
On Wed, Mar 13, 2019 at 11:35:33AM -0700, Richard Henderson wrote:
> On 3/13/19 10:57 AM, Daniel P. Berrangé wrote:
> > We already have an internal API for providing strong random bytes in
> > QEMU qcrypto_random_bytes. It is preferentially backed by gnutls or
> > gcrypt, but if those aren't built-
On 3/13/19 11:49 AM, Richard Henderson wrote:
> On 3/13/19 10:38 AM, Markus Armbruster wrote:
>> Have you considered GLib's? Mersenne Twister under the hood.
>>
>> https://developer.gnome.org/glib/stable/glib-Random-Numbers.html
>
> I hadn't considered glib's, but I am considering MT19337-64.
Th
On 3/13/19 10:38 AM, Markus Armbruster wrote:
> Have you considered GLib's? Mersenne Twister under the hood.
>
> https://developer.gnome.org/glib/stable/glib-Random-Numbers.html
I hadn't considered glib's, but I am considering MT19337-64.
r~
On 3/13/19 10:57 AM, Daniel P. Berrangé wrote:
> We already have an internal API for providing strong random bytes in
> QEMU qcrypto_random_bytes. It is preferentially backed by gnutls or
> gcrypt, but if those aren't built-in it falls back to a platform
> native API like /dev/random. I've got a to
On Wed, Mar 13, 2019 at 08:25:45AM -0700, Richard Henderson wrote:
> On 3/12/19 11:41 PM, no-re...@patchew.org wrote:
> > time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
> > === TEST SCRIPT END ===
> >
> > CC hw/acpi/trace.o
> > CC hw/alpha/trace.o
> > /tmp/qemu-test/src
Richard Henderson writes:
> On 3/12/19 11:41 PM, no-re...@patchew.org wrote:
>> time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
>> === TEST SCRIPT END ===
>>
>> CC hw/acpi/trace.o
>> CC hw/alpha/trace.o
>> /tmp/qemu-test/src/util/random.c: In function 'do_jrand48':
>>
On 3/12/19 11:41 PM, no-re...@patchew.org wrote:
> time make docker-test-mingw@fedora SHOW_ENV=1 J=14 NETWORK=1
> === TEST SCRIPT END ===
>
> CC hw/acpi/trace.o
> CC hw/alpha/trace.o
> /tmp/qemu-test/src/util/random.c: In function 'do_jrand48':
> /tmp/qemu-test/src/util/random.c:41:1
Patchew URL:
https://patchew.org/QEMU/20190313062630.30568-1-richard.hender...@linaro.org/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
] [PATCH for-4.1 0/7] Add qemu_getrandom and ARMv8.5-RNG
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== T
While the comment for AT_RANDOM is still apropos, "not cryptically
secure but it's not the aim of QEMU", I think we can still do better
than N calls to rand(3).
The first patch sets up an interface that allows deterministic random
numbers across different threads, using jrand48. This function is:
14 matches
Mail list logo
