I'm pretty sure that /dev/random has not required a card since ICSF HCR77A0. I believe that this was the release that introduced RNG caching.
I'm not sure if I understand...you say that ICSF will "start making RNG calls to the CEX card" but later that "on current technology, the CEX does not play a role in generating random numbers". What about pre-z14? Did having a CEX improve /dev/random? Most apps only take small sips, so it seems unlikely to me that it makes much difference. On Tue, Jan 22, 2019 at 4:33 PM Greg Boyd <gregb...@mainframecrypto.com> wrote: > I started to send you an offline note to ask about /dev/random ... > > First, the way I understood it, was that the really old /dev/random > drivers generated random numbers in software, and it was really slow. > > Going back to the PCICC and PCIXCC cards, there was a RNG function on the > card. I don't think customers installed a crypto card to do RNG, but if > they had one for other reasons it certainly made sense to use the card and > /dev/random was updated to use the card if it was installed and ICSF was > active, and if so, ask ICSF for a random number. (ICSF must be active to > send work to the cards.) > > If you needed more than a few random numbers, that was highly recommended. > > Then ICSF implemented the RNG Cache where it would, during initialization, > start making RNG calls to the CEX card and build a cache of values that > would be provided to applications when they executed the RNG. So you > avoided the async operation in the application and RNG performance got > significantly better. > > Note that ICSF implemented the RNG Cache in one version, and in the very > next version, gave you an option RNGCACHE(NO) to disable it. The default > is Yes. > > Now, with the z14, the RNG is available on the CPACF hardware, via an > instruction. The ICSF SPG says in several places that specifying RNGCACHE > will provide better performance for applications that use a lot of random > numbers. And it makes sense that retrieving the random number from a cache > is faster than generating it using an instruction. > > The question I wanted to ask you: Why doesn't /dev/random use the > instruction directly to get it's random number? as opposed to going thru > the overhead of using the API? > > To answer your specific question, on current technology, the CEX does not > play a role in generating random numbers. More generally, your performance > depends on: > What hardware you are running on (both CEC and CEX card) > What version of ICSF you are using, and how you have it configured > Which /dev/random driver you are using > > Greg Boyd > Mainframe Crypto > www.mainframecrypto.com > > > On Tue, 22 Jan 2019 14:16:10 -0600, Kirk Wolf <k...@wolf-associates.com> > wrote: > > >Greg - > >/dev/random use does require ICSF to be started, but is it affected > >(improved) by the presence of a crypto card? That was not my > >understanding, but I could be wrong. > > > >On Tue, Jan 22, 2019 at 7:27 AM Greg Boyd <gregb...@mainframecrypto.com> > >wrote: > > > >> There may have been changes to Connect Direct since the last time I > worked > >> with it, but I suspect ICSF is required if you want to leverage the > >> hardware technology, and specifically the CEX cards. As Kirk points > out, > >> if you want to use the random number generation on hardware then you > need > >> ICSF active. (And you probably do want the performance of RNG in > >> hardware.) Similarly, for System SSL, if you want to use the Crypto > >> Express cards for authentication (public/private key operations), then > ICSF > >> needs to be active. Enabling the cards and having ICSF active can make > a > >> big difference in throughput and capacity (CPU savings), but strictly > >> speaking it's probably not required unless you configure the > environment to > >> use the crypto hardware. > >> > >> Greg Boyd > >> Mainframe Crypto > >> www.mainframecrypto.com > >> > >> > >> On Fri, 18 Jan 2019 17:55:51 -0600, Steve beaver <st...@stevebeaver.com > > > >> wrote: > >> > >> >Also it’s required for Connect Direct > >> > > >> >Sent from my iPhone > >> > > >> >Sorry for the finger checks > >> > > >> >> On Jan 18, 2019, at 17:29, Kirk Wolf <k...@wolf-associates.com> > wrote: > >> >> > >> >> ICSF is currently required if you want to use the Unix /dev/random > and > >> >> /dev/urandom devices. > >> >> These might be required by Unix apps (or jobs/stcs that use z/OS Unix > >> >> System services). > >> >> > >> >> For exampe: IBM OpenSSH server will not work without ICSF and > >> /dev/random > >> >> available. > >> >> > >> >> On Fri, Jan 18, 2019 at 5:24 PM Greg Boyd < > gregb...@mainframecrypto.com > >> > > >> >> wrote: > >> >> > >> >>> ICSF is only required if you want to use the ICSF APIs, so it > depends > >> on > >> >>> what, if anything in your shop might be using the APIs. System SSL > >> (TLS) > >> >>> will certainly leverage the APIs if you have Crypto Express cards > >> available > >> >>> and that might provide some CPU relief. The Guardium Database > >> Encryption > >> >>> Tool requires it if you want to encrypt IMS segments or DB2 tables > at > >> the > >> >>> row level. > >> >>> > >> >>> Pervasive is getting a lot of attention and if you're going that > >> route, I > >> >>> would highly recommend that ICSF be active everywhere. You don't > want > >> one > >> >>> system writing ciphertext to a file and another system thinking that > >> the > >> >>> file is cleartext. IBM is also recommending that ICSF be 'always > up'. > >> >>> They have made a number of changes to the component so that it will > >> come up > >> >>> earlier in the IPL and it should be one of the last tasks running. > >> >>> > >> >>> Given the growth in crypto workload, I take 'always up' to also mean > >> >>> 'running everywhere'. There are simply more things that can > leverage > >> ICSF, > >> >>> some optionally and some require it. > >> >>> > >> >>> I'm not sure why DFSMShsm would need ICSF active, unless they were > >> using > >> >>> the Encryption Facility for z/OS with the DFSMSdss feature. > >> >>> > >> >>> Greg Boyd > >> >>> Mainframe Crypto > >> >>> www.mainframecrypto.com > >> >>> > >> >>> > >> >>> > >> >>> On Fri, 18 Jan 2019 18:16:37 +0000, Mary Kay Tubello < > >> mtube...@humana.com> > >> >>> wrote: > >> >>> > >> >>>> Hello all, > >> >>>> > >> >>>> Does anyone know if z/os 2.3 requires ICSF to be installed on each > >> LPAR? > >> >>>> > >> >>>> Thanks, > >> >>>> Mary Kay > >> >>>> > >> >>>> Large Systems Engineering > >> >>>> IT Infrastructure > >> >>>> Humana > >> >>>> 123 E. Main St. 40202 (CT6) > >> >>>> 502-476-2772 > >> >>>> mtube...@humana.com<mailto:mtube...@humana.com> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > ---------------------------------------------------------------------- > >> >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >> >>>> send email to lists...@listserv.ua.edu with the message: INFO > >> IBM-MAIN > >> >>> > >> >>> > ---------------------------------------------------------------------- > >> >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >> >>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >> >>> > >> >> > >> >> > ---------------------------------------------------------------------- > >> >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> >> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >> > > >> >---------------------------------------------------------------------- > >> >For IBM-MAIN subscribe / signoff / archive access instructions, > >> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
