The OpenCryptoki source package includes a driver testcase that can be run to verify a lot of the coprocessor/accelerator features. It'll test all of the library calls and verify that they're working. I've always interpreted it as if it doesn't fail, it means it's able to use the underlying hardware function properly.
Just install the SRPM from SUSE or go to sf.net/projects/opencryptoki and download the source tarball that's closest to the installed version. Just untar and then ./configure && make, cd testcases/driver (and `make` again if it didn't build the driver executable) and then run ./driver. Need to make sure pkcsslotd and up and running and you've set the SO & user PINs (I recommend using init_token.sh that's in the testcases directory to do that, as OpenCryptoki expects certain PINs in the testcase). ks On 4/26/07, Thomas Kern <[EMAIL PROTECTED]> wrote:
Is there a verification program that can be run in a SLES 9/10 guest to check the functionality of the CPACF / Coprocessor / Accelerator ? --- [email protected] <[EMAIL PROTECTED]> wrote: > > Kind of stuck on this one. Had the CE come out and enable the Crypto > > co-processor CPACF feature code for our z9-104 yesterday, then went to > > define and use the feature in a Linux LPAR, but it doesn't work. We > have > > the libica code installed, but whether it's used or not we get the > same > > throughput from the openssl speed tests. I didn't think it took a POR > to > > get the feature recognized - is there something I'm missing here? > > Enabling the crypto engine really might not help you much. How much help > you'll get depends a lot on what you're trying to do with it. > > There are two components to a SSL transaction: the initial asymmetric > crypto-ignition process at connection startup, and the ongoing symmetric > process after the connection is established. Pre z9 BC/EC, depending on > how you configured the crypto engine (as coprocessor or accelerator), > you get enhancement of one or the other function. The BC and EC models > can be configured in such a way to help somewhat with both tasks. > > If a majority of your transactions are short=lived connections, the > SSL > offload for the asymmetric step will help a lot. If you're doing > long-lived sessions (like tn3270 wrapping), then you won't get a lot out > of it, except after a network interruption when all the clients try to > renegotiate keys at once. If you're expecting it to help with SSH > sessions, it doesn't. Most of that is symmetric, or uses algorithms that > CPACF doesn't yet know how to accelerate. > > (AFAIS, the openssl speed tests don't really do enough connection volume > to show much of a difference even when the crypto engine is known to be > working. ) > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
