As I said, the option of doing feed from hwrng directly via a kernel thread
seems the most logical thing to me, assuming you can convince Ted & co. rngd
doesn't really add much value for a whitened source.
Torsten Duwe wrote:
>
>
>On Thu, 12 Sep 2013, H. Peter Anvin wrote:
>
>> From what I
By the way, haveged is... worthy of suspicion (I doubt it is malicious, but
still). Its self-tests are completely useless (replace the entropy source with
a constant "1" and they still pass) and there is as far as I know no analysis
about the randomness other than "it passes some tests."
On Thu, 12 Sep 2013, H. Peter Anvin wrote:
> From what I can gather from the patch this is too heavyweight (need
> locks and so on) to use as arch_get_random*(). There has been a lot of
Alas, I can see there's only x86 that currently has this implemented?
> discussion about the pros and cons
On Thu, 12 Sep 2013, H. Peter Anvin wrote:
From what I can gather from the patch this is too heavyweight (need
locks and so on) to use as arch_get_random*(). There has been a lot of
Alas, I can see there's only x86 that currently has this implemented?
discussion about the pros and cons of
By the way, haveged is... worthy of suspicion (I doubt it is malicious, but
still). Its self-tests are completely useless (replace the entropy source with
a constant 1 and they still pass) and there is as far as I know no analysis
about the randomness other than it passes some tests.
As I said, the option of doing feed from hwrng directly via a kernel thread
seems the most logical thing to me, assuming you can convince Ted co. rngd
doesn't really add much value for a whitened source.
Torsten Duwe d...@lst.de wrote:
On Thu, 12 Sep 2013, H. Peter Anvin wrote:
From what
On 09/12/2013 02:41 AM, Torsten Duwe wrote:
>
> Running completely virtualised, system Z severely lacks good true random
> sources.
> Gathering entropy in a virtual environment is difficult. To compensate, there
> is
> specialised crypto hardware which includes a source for hardware randomness;
Running completely virtualised, system Z severely lacks good true random
sources.
Gathering entropy in a virtual environment is difficult. To compensate, there is
specialised crypto hardware which includes a source for hardware randomness;
the zcrypt driver is able to access this random source.
Running completely virtualised, system Z severely lacks good true random
sources.
Gathering entropy in a virtual environment is difficult. To compensate, there is
specialised crypto hardware which includes a source for hardware randomness;
the zcrypt driver is able to access this random source.
On 09/12/2013 02:41 AM, Torsten Duwe wrote:
Running completely virtualised, system Z severely lacks good true random
sources.
Gathering entropy in a virtual environment is difficult. To compensate, there
is
specialised crypto hardware which includes a source for hardware randomness;
the
On Wed, 2013-09-04 at 10:48 +0200, Torsten Duwe wrote:
[]
> +++ b/drivers/s390/crypto/zcrypt_api.c
> @@ -1141,6 +1144,36 @@ static struct hwrng zcrypt_rng_dev = {
][
> +static int zcrypt_hwrng_fillfn(void *unused)
> +{
> + long rc;
> +
> + while (!kthread_should_stop()) {
> +
On Wed, 2013-09-04 at 10:48 +0200, Torsten Duwe wrote:
[]
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -1141,6 +1144,36 @@ static struct hwrng zcrypt_rng_dev = {
][
+static int zcrypt_hwrng_fillfn(void *unused)
+{
+ long rc;
+
+ while (!kthread_should_stop()) {
+ rc
[Checkpatch'ed, IBM folks Cc'ed]
Running completely virtualised, system Z severely lacks good true random
sources.
Gathering entropy in a virtual environment is difficult. To compensate, there is
specialised crypto hardware which includes a source for hardware randomness;
the zcrypt driver is
[Checkpatch'ed, IBM folks Cc'ed]
Running completely virtualised, system Z severely lacks good true random
sources.
Gathering entropy in a virtual environment is difficult. To compensate, there is
specialised crypto hardware which includes a source for hardware randomness;
the zcrypt driver is
14 matches
Mail list logo
