lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 11 Jul 2014 15:43:24 +0200
From:	Ingo Tuchscherer <ingo.tuchscherer@...ibm.com>
To:	"Theodore Ts'o" <tytso@....edu>, Torsten Duwe <duwe@...e.de>
Cc:	linux-kernel@...r.kernel.org, geralds@...ux.vnet.ibm.com,
	heicars2@...ux.vnet.ibm.com, mschwid2@...ux.vnet.ibm.com,
	Matt Mackall <mpm@...enic.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Harald Freudenberger <FREUDE@...ibm.com>
Subject: Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device


Hi @all,

First, sorry for the late feedback, I was busy with other topics.

In the meanwhile I had a look at this hwrng entropy feature related to s390
and the zcrypt hardware random generator.
I have a concern about the initial call to the hwrng device while trying to
register the same.

drivers/char/hw_random/core.c
...
int hwrng_register(struct hwrng *rng) {
   ...
   bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1);
        if (bytes_read > 0)
                add_device_randomness(bytes, bytes_read);
  ...
}

At this point in time the zcrypt hw device is not registered completely in
the internal zcrypt device list (ap_device_list). The crypto card itself is
initialized and ready to receive and service requests, but the tasklet that
retrieve the card response is not able to find the device because it's not
yet in the list. Finally the response would not be received and the thread
is still waiting for completion, hence the probing/registering procedure
for all the other crypto devices is blocked. No further devices could be
scanned, initialized and registered.
Therefore I would not recommend to trigger a hw device request before the
device register process has completed.

Anyway, when the kernel thread (hwrng_fillfn) starts, it take care about
the initial call to the zcrypt rng device to be triggered. Therefore I
don't see any reason to manually call rng_get_data() during the
registration or did I missed something?

Mit freundlichen Grüßen / Kind regards

Ingo Tuchscherer

Software Development - Linux on System z
IBM Systems &Technology Group
                                                                                                       
                                                                                                       
                                                                                                       
                                                                                                       
                                                                                                       
 Phone:            +49-7031-16-1986                 IBM Deutschland                          (Embedded 
                                                                                           image moved 
                                                                                              to file: 
                                                                                         pic60502.gif) 
                                                                                                       
 E-Mail:           ingo.tuchscherer@...ibm.com      Schoenaicher Str. 220                              
                                                                                                       
                                                    71032 Boeblingen                                   
                                                                                                       
                                                    Germany                                            
                                                                                                       
                                                                                                       
                                                                                                       
                                                                                                       
                                                                                                       
 IBM Deutschland                                                                                       
 Research &                                                                                            
 Development                                                                                           
 GmbH /                                                                                                
 Vorsitzender des                                                                                      
 Aufsichtsrats:                                                                                        
 Martina Koederitz                                                                                     
                                                                                                       
 Geschäftsführung:                                                                                     
 Dirk Wittkopp                                                                                         
 Sitz der                                                                                              
 Gesellschaft:                                                                                         
 Böblingen /                                                                                           
 Registergericht:                                                                                      
 Amtsgericht                                                                                           
 Stuttgart, HRB                                                                                        
 243294                                                                                                
                                                                                                       





From:	"Theodore Ts'o" <tytso@....edu>
To:	Torsten Duwe <duwe@...e.de>,
Cc:	Ingo Tuchscherer/Germany/IBM@...DE, Hans-Georg
            Markgraf/Germany/IBM@...DE, geralds@...ux.vnet.ibm.com,
            mschwid2@...ux.vnet.ibm.com, heicars2@...ux.vnet.ibm.com, Jörn
            Engel <joern@...fs.org>
Date:	16.06.2014 16:28
Subject:	Re: [Patch v5.1 03/03]: hwrng: khwrngd derating per device



On Mon, Jun 16, 2014 at 04:14:44PM +0200, Torsten Duwe wrote:
> Also, I added the patch below to our kernel. Who wants to take that
> one-liner upstream?

This will require sucking in the "master" branch of random.git.  So
either the s390 tree can merge in the master branch, or I can carry it
in the random.git tree.  I'm happy to do that unless their are any
objections.

(Note: if you want to base something on random.git, please use the
master branch.  The dev branch is sometimes rewound...  I've since
moved master up to the dev branch, which is my guarantee not to rewind
anything up to the master branch.)

> --- linux-3.12-SLE12/drivers/s390/crypto/zcrypt_api.c.orig
2014-06-16 14:23:27.726162185 +0200
> +++ linux-3.12-SLE12/drivers/s390/crypto/zcrypt_api.c
2014-06-16 14:46:31.869103924 +0200
> @@ -1374,6 +1374,7 @@ static int zcrypt_rng_data_read(struct h
>  static struct hwrng zcrypt_rng_dev = {
>  		 .name		 		 = "zcrypt",
>  		 .data_read		 = zcrypt_rng_data_read,
> +		 .quality		 = 990,
>  };
>
>  static int zcrypt_rng_device_add(void)

I assume the z-Series RNG is presumed to be high quality, yes?

  		      		       		      		       -
Ted


Download attachment "pic60502.gif" of type "image/gif" (1851 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ