Gary: Thanks for the pointer to OA55437, I was not aware of that APAR. It
specifically says that /dev/random uses the TRNG (True Random Number Generator)
which is implemented on the CPACF.
Kirk: RNGCACHE was introduced with HCR77B0 (the first time I see it is in the
ICSF SPG is SC14-7507-03). But you may be right about HCR77A0, because the
ICSF APG for HCR77A0 (SA22-7522-16) was the first indication that the RNG can
be performed on the CPACF. Prior to that level of ICSF, CSNBRNG required a CEX
card. With HCR77A0, the CPACF is mentioned in the 'Required Hardware' section
of the document but I don't see any indication of how the API decides whether
to use the CEX card or the CPACF. The Usage Notes section implies, at least
for CNSBRNGL, that the API will
use the CEX card if it supports the CSNBRNGL verb
make multiple calls to the CEX card if it supports the CSNBRNG verb
use the CPACF if the feature level supports pseudo-random number generation
I suspect that if you had a CEX card, then it used it and if you didn't, it
would give you a pseudo-random number, from the CPACF.
Sorry for the confusion on the impact. What I was trying to point out was that
it depends on the environment whether a card will help or not. If you are
running on a z14, but an old level of /dev/random (i.e. without OA55437), then
you are still calling the API. If you are calling the API and you have
RNGCACHE enabled, you'll get your random number from the cache. But if
RNGCACHE is turned off, then the API call will go to the card.
And if you are running on a z13 or earlier, then the TRNG instruction is not
available and you would again be using the API. Using the RNGCACHE would be
better than making a call to the card.
So with z14 and OA55437 then having a CEX card does not matter for RNGs. With
a z13 and earlier, having a CEX card would help performance for RNGs, but how
much depends on other configuration settings.
And I agree that most apps take small sips, so for a single transaction or
call, you probably won't notice the difference.
Greg
On Tue, 22 Jan 2019 17:59:36 -0600, Kirk Wolf <k...@wolf-associates.com> wrote:
>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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
