Il 31/10/2012 15:15, H. Peter Anvin ha scritto:
>>
>> Related to this, rdrand's "entropy content" in the worst case will be
>> only 1/255th of the data it produces: Intel documents that one 256-bit
>> seed will result in up to 1022 64-bit random numbers. Yet, it is good
>> enough to drive rngd. W
On 10/31/2012 12:29 AM, Paolo Bonzini wrote:
Related to this, rdrand's "entropy content" in the worst case will be
only 1/255th of the data it produces: Intel documents that one 256-bit
seed will result in up to 1022 64-bit random numbers. Yet, it is good
enough to drive rngd. Would it make se
Il 30/10/2012 22:11, H. Peter Anvin ha scritto:
>> What I said that passing /dev/hwrng or rdrand would:
>>
>> - not make /dev/random with virtio-rng-pci worse than without
>
> It wouldn't, but it would make virtio-rng-pci a potential noop on a
> system where it could genuinely do better.
True, bu
On 10/30/2012 02:05 AM, Paolo Bonzini wrote:
> Either you're not reading what I wrote, or you're confusing me with
> someone else.
My apologies, you are indeed correct. I misinterpreted your emails,
probably because I got you confused with someone else.
> I *never* mentioned passing /dev/urandom
Il 30/10/2012 05:43, H. Peter Anvin ha scritto:
> Let me be more specific.
>
> First of all, feeding /dev/urandom to the guest is dangerous -- you are
> feeding it PRNG contents but telling it that it is real entropy. This
> is a security hole.
>
> Second of all, you're doing something pointless
On 10/29/2012 01:45 AM, Paolo Bonzini wrote:
Il 26/10/2012 22:29, H. Peter Anvin ha scritto:
This is surreal. Output from /dev/hwrng turns into output for /dev/random...
it us guaranteed worse; period, end of story.
Isn't that exactly what happens in bare-metal? hwrng -> rngd -> random.
In
On 10/29/2012 01:45 AM, Paolo Bonzini wrote:
First, hwrng is only one of the sources used by rngd. It can also
(currently) use RDRAND or TPM; additional sources are likely to be added
in the future.
Second, the harvesting of environmental noise -- timings -- is not as
good in a VM as on plain h
On 10/28/2012 11:23 PM, Amit Shah wrote:
One solution could be to feed host's /dev/urandom to readers of
guests' /dev/urandom. We could then pass the rare true entropy bits
from host's /dev/hwrng or /dev/random to the guest via
virtio-rng-pci's /dev/hwrng interface in the guest.
If this is a va
Il 26/10/2012 22:29, H. Peter Anvin ha scritto:
>>> This is surreal. Output from /dev/hwrng turns into output for
>>> /dev/random... it us guaranteed worse; period, end of story.
>> >
>> > Isn't that exactly what happens in bare-metal? hwrng -> rngd -> random.
>> > Instead here
>> > we'd have
On (Fri) 26 Oct 2012 [09:43:34], Anthony Liguori wrote:
> Hi,
>
> This series implements the backend and frontend infrastructure for virtio-rng.
> This is similar to previous series sent out by both Amit and myself although
> it
> has been trimmed down considerably.
>
> In terms of backends, a f
On (Fri) 26 Oct 2012 [13:24:06], Anthony Liguori wrote:
> "H. Peter Anvin" writes:
>
> > On 10/26/2012 08:42 AM, Anthony Liguori wrote:
> >>>
> >>> Is /dev/random even appropriate to feed rngd?
> >>>
> >>> rngd needs _a lot_ of entropy to even start working. Its randomness
> >>> test works in gr
On 10/26/2012 12:51 PM, Paolo Bonzini wrote:
> Il 26/10/2012 21:07, H. Peter Anvin ha scritto:
>> This is surreal. Output from /dev/hwrng turns into output for
>> /dev/random... it us guaranteed worse; period, end of story.
>
> Isn't that exactly what happens in bare-metal? hwrng -> rngd -> ran
That statement is pretty toxic... I wonder where it came from. It is at best
horribly misleading and actively encourages dangerous behaviours even for the
cases where it isn't actively wrong.
Paolo Bonzini wrote:
>Il 26/10/2012 21:07, H. Peter Anvin ha scritto:
>> This is surreal. Output fro
Il 26/10/2012 21:07, H. Peter Anvin ha scritto:
> This is surreal. Output from /dev/hwrng turns into output for /dev/random...
> it us guaranteed worse; period, end of story.
Isn't that exactly what happens in bare-metal? hwrng -> rngd -> random.
Instead here
we'd have, host hwrng -> virtio-r
This is surreal. Output from /dev/hwrng turns into output for /dev/random...
it us guaranteed worse; period, end of story.
I don't know who the "agreement" is with, but it is ridiculous in this case.
As far as the need whitening issue, I discussed that with Ted at Kernel Summit
and we came up
Il 26/10/2012 18:09, H. Peter Anvin ha scritto:
> a) it means that the guest *has* to run rngd or a similar engine; if you
> have control over the guests it might be more efficient to run rngd in
> skip-test mode (I don't think that is currently implemented but it
> could/should be) and centralize
Il 26/10/2012 17:42, Anthony Liguori ha scritto:
>> Maybe rdrand, but that's just a chardev---so why isn't this enough:
>>
>> -chardev file,source=on,path=/dev/hwrng,id=chr0 -device
>> virtio-rng-pci,file=chr0
>> -chardev rdrand,id=chr0 -device
>> virtio-rng-pci,file
PRNGs don't "create entropy." Period.
The guest will run its own PRNG.
Anthony Liguori wrote:
>"H. Peter Anvin" writes:
>
>> On 10/26/2012 08:42 AM, Anthony Liguori wrote:
Is /dev/random even appropriate to feed rngd?
rngd needs _a lot_ of entropy to even start working. I
"H. Peter Anvin" writes:
> On 10/26/2012 08:42 AM, Anthony Liguori wrote:
>>>
>>> Is /dev/random even appropriate to feed rngd?
>>>
>>> rngd needs _a lot_ of entropy to even start working. Its randomness
>>> test works in groups of 2 bits. On a system without an hardware
>>> RNG, /dev/random
On 10/26/2012 08:42 AM, Anthony Liguori wrote:
Is /dev/random even appropriate to feed rngd?
rngd needs _a lot_ of entropy to even start working. Its randomness
test works in groups of 2 bits. On a system without an hardware
RNG, /dev/random can hardly produce 4000 bits/minute. This means
Paolo Bonzini writes:
>> This series implements the backend and frontend infrastructure for
>> virtio-rng.
>> This is similar to previous series sent out by both Amit and myself
>> although it has been trimmed down considerably.
>>
>> In terms of backends, a file and EGD backend are supported.
> This series implements the backend and frontend infrastructure for virtio-rng.
> This is similar to previous series sent out by both Amit and myself
> although it has been trimmed down considerably.
>
> In terms of backends, a file and EGD backend are supported. The file defaults
> to /dev/rand
22 matches
Mail list logo
