(unknown),

(unknown),

[Jeffrey Walton]

Please forgive my ignorance here...

I have test system with a VIA C7-M processor and PM-400 chipset. This
is one of those Thin Client/Internet of Things processor and chipsets
I test security libraries on (like OpenSSL, Cryptlib and Crypto++).

The processor includes the Padlock extensions. Padlock is similar to
Intel's RDRAND, RDSEED and AES-NI, and it predates Intel's
instructions by about a decade.

The Padlock Security Engine can produce a stream of random numbers at
megabits per socond, so I've been kind of surprised it has been
suffering entropy depletion. Here's what the audit trail looks like:

    Testing operating system provided blocking random number generator...
    FAILED:  it took 74 seconds to generate 5 bytes
    passed:  5 generated bytes compressed to 7 bytes by DEFLATE

Above, the blocking RNG is drained. Then, 16 bytes are requested. It
appears to take over one minute to gather five bytes when effectively
an endless stream is available.

My question is, is this system expected to suffer entropy depletion
out of the box? Or are users expected to do something special so the
system does not fail?

Thanks in advance.

Jeff

Re: (none)

[Herbert Xu]

Jeffrey Walton <noloader@gmail.com> wrote:
> Please forgive my ignorance here...
> 
> I have test system with a VIA C7-M processor and PM-400 chipset. This
> is one of those Thin Client/Internet of Things processor and chipsets
> I test security libraries on (like OpenSSL, Cryptlib and Crypto++).
> 
> The processor includes the Padlock extensions. Padlock is similar to
> Intel's RDRAND, RDSEED and AES-NI, and it predates Intel's
> instructions by about a decade.
> 
> The Padlock Security Engine can produce a stream of random numbers at
> megabits per socond, so I've been kind of surprised it has been
> suffering entropy depletion. Here's what the audit trail looks like:
> 
>    Testing operating system provided blocking random number generator...
>    FAILED:  it took 74 seconds to generate 5 bytes
>    passed:  5 generated bytes compressed to 7 bytes by DEFLATE
> 
> Above, the blocking RNG is drained. Then, 16 bytes are requested. It
> appears to take over one minute to gather five bytes when effectively
> an endless stream is available.
> 
> My question is, is this system expected to suffer entropy depletion
> out of the box? Or are users expected to do something special so the
> system does not fail?

I don't think anybody has written either an hwrng driver or a rdrand
hook for padlock.  Patches are welcome.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: (none)

[Stephan Mueller]

Am Mittwoch, 1. Juni 2016, 12:59:43 schrieb Herbert Xu:

Hi Herbert,

> Jeffrey Walton <noloader@gmail.com> wrote:
> > Please forgive my ignorance here...
> > 
> > I have test system with a VIA C7-M processor and PM-400 chipset. This
> > is one of those Thin Client/Internet of Things processor and chipsets
> > I test security libraries on (like OpenSSL, Cryptlib and Crypto++).
> > 
> > The processor includes the Padlock extensions. Padlock is similar to
> > Intel's RDRAND, RDSEED and AES-NI, and it predates Intel's
> > instructions by about a decade.
> > 
> > The Padlock Security Engine can produce a stream of random numbers at
> > megabits per socond, so I've been kind of surprised it has been
> > 
> > suffering entropy depletion. Here's what the audit trail looks like:
> >    Testing operating system provided blocking random number generator...
> >    FAILED:  it took 74 seconds to generate 5 bytes
> >    passed:  5 generated bytes compressed to 7 bytes by DEFLATE
> > 
> > Above, the blocking RNG is drained. Then, 16 bytes are requested. It
> > appears to take over one minute to gather five bytes when effectively
> > an endless stream is available.
> > 
> > My question is, is this system expected to suffer entropy depletion
> > out of the box? Or are users expected to do something special so the
> > system does not fail?
> 
> I don't think anybody has written either an hwrng driver or a rdrand
> hook for padlock.  Patches are welcome.

I thought via-rng.c covers the VIA Padlock RNG?

Ciao
Stephan

Re: (none)

[Herbert Xu]

On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
>
> I thought via-rng.c covers the VIA Padlock RNG?

Indeed, you're quite right.  In that case Jeffrey was the via-rng
driver loaded?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: (none)

[Jeffrey Walton]

On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
>>
>> I thought via-rng.c covers the VIA Padlock RNG?
>
> Indeed, you're quite right.  In that case Jeffrey was the via-rng
> driver loaded?

$ cat /proc/modules | egrep -i '(via|padlock|rng)'
padlock_sha 16384 0 - Live 0x00000000
padlock_aes 16384 0 - Live 0x00000000
via_cputemp 16384 0 - Live 0x00000000
hwmon_vid 16384 1 via_cputemp, Live 0x00000000
via_rng 16384 0 - Live 0x00000000
i2c_viapro 16384 0 - Live 0x00000000
pata_via 16384 0 - Live 0x00000000
sata_via 16384 2 - Live 0x00000000

And:

$ lsmod | egrep -i '(via|padlock|rng)'
padlock_sha            16384  0
padlock_aes            16384  0
via_cputemp            16384  0
hwmon_vid              16384  1 via_cputemp
via_rng                16384  0
i2c_viapro             16384  0
pata_via               16384  0
sata_via               16384  2

And:

$ dmesg | egrep -i '(via|padlock|rng)'
[    0.124003] smpboot: CPU0: Centaur VIA C7-D Processor 1800MHz (fam:
06, model: 0d, stepping: 00)
[    0.263914] pci 0000:00:01.0: disabling DAC on VIA PCI bridge
[    2.290795] agpgart: Detected VIA P4M900 chipset
[    2.296875] agpgart-via 0000:00:00.0: AGP aperture is 128M @ 0xf0000000
[    2.934927] sata_via 0000:00:0f.0: version 2.6
[    2.935155] sata_via 0000:00:0f.0: routed to hard irq line 6
[    2.948457] scsi host0: sata_via
[    2.967744] scsi host1: sata_via
[    2.968167] pata_via 0000:00:0f.1: version 0.3.4
[    2.976090] scsi host2: pata_via
[    2.982777] scsi host3: pata_via
[    4.339291] systemd[1]: Set hostname to <via>.
[   10.415938] VIA RNG detected
[   11.257974] hwmon_vid: Using 6-bit VID table for VIA C7-D CPU
[   12.100845] padlock_aes: Using VIA PadLock ACE for AES algorithm.
[   12.149586] padlock_sha: Using VIA PadLock ACE for SHA1/SHA256 algorithms.
[   12.633495] input: HDA VIA VT82xx Rear Mic as
/devices/pci0000:80/0000:80:01.0/sound/card0/input9
[   12.633720] input: HDA VIA VT82xx Line as
/devices/pci0000:80/0000:80:01.0/sound/card0/input10
[   12.633927] input: HDA VIA VT82xx Headphone Front as
/devices/pci0000:80/0000:80:01.0/sound/card0/input11

Re: (none)

[Stephan Mueller]

Am Mittwoch, 1. Juni 2016, 02:59:21 schrieb Jeffrey Walton:

Hi Jeffrey,

> On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu <herbert@gondor.apana.org.au> 
wrote:
> > On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
> >> I thought via-rng.c covers the VIA Padlock RNG?
> > 
> > Indeed, you're quite right.  In that case Jeffrey was the via-rng
> > driver loaded?

[...]

Ok, it is loaded. Did you use /dev/hw_random for getting data?

Ciao
Stephan

Re: (none)

[Herbert Xu]

On Wed, Jun 01, 2016 at 02:59:21AM -0400, Jeffrey Walton wrote:
> 
> $ cat /proc/modules | egrep -i '(via|padlock|rng)'
> padlock_sha 16384 0 - Live 0x00000000
> padlock_aes 16384 0 - Live 0x00000000
> via_cputemp 16384 0 - Live 0x00000000
> hwmon_vid 16384 1 via_cputemp, Live 0x00000000
> via_rng 16384 0 - Live 0x00000000
> i2c_viapro 16384 0 - Live 0x00000000
> pata_via 16384 0 - Live 0x00000000
> sata_via 16384 2 - Live 0x00000000

OK, by default hwrng entropy is not fed into /dev/random.

You need to enable it by hand by setting default_quality on the
rng-core module to a non-zero value.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt