Todd Arnold wrote: >Let me briefly explain the "coprocessor" vs. "accelerator" modes of the CEX >crypto cards. As far as the crypto card itself is concerned, there IS no >difference, and there are no separate "modes". The only difference is how the >host z machine chooses to use the card. Let me explain what I mean...
>The hardware of the CEX cards provides two different ways to get to the crypto >services. >* One is what is called the "normal path". With this, a request from the host >is formatted into a message block that is sent across the bus to the CEX, >where it ends up in the card's internal memory. The microprocessor on the >card sees that a request has arrived, and processes it - which generally >involves quite a bit of software (firmware) running on that microprocessor, >plus one or more operations on the card's crypto hardware chips. The >microprocessor has interfaces that let it perform operations using those >chips. Once everything is finished, the microprocessor builds a response >block in its memory, then kicks off a process that sends that response block >back to the host. In essence, you can think of "normal path" as if you were >sending a request across a network to another computer that has specialized >functions - but in this case, the "network" is the PCIe bus and the "other >computer" is the crypto card and its processing components. >* The other way is what is called "fast path", which you know as "accelerator >mode" in the System z. Using this approach, the host system has a way to >directly talk to the crypto chips on the CEX card - processing uses ONLY >hardware and does not involve the CEX microprocessor or any on-card firmware. >Thus, this is a much faster way of getting to the crypto hardware capability >of the CEX card - however, it is also very limited in what it can do. Those >hardware chips do not implement higher-level things like PIN operations, >financial key derivations, key management operations, digital signatures, or >any of the many, many other complex functions you can get through the "normal >path". It is a trade off - you gain a lot of speed, but lose most of the >functions the card can perform for you. Today on System z, "fast path" is >mainly used to accelerate the RSA operations that are used to initiate SSL/TLS >sessions. >The thing most people do not realize is that the CEX card has no problem >running a mix of "normal path" and "fast path" operations - it has hardware >arbitration logic that lets the host system send any mixture of the two. >Thus, there are no separate "modes" on the CEX itself - as far as it's >concerned, you can use both modes at the same time. However, the System z >architecture makes a distinction between the two modes and only lets you use >one of them on a given CEX card, according to how you have configured that >card into the system. And not that anyone was likely to wonder, Todd is the man in CEX-land-he's the father of the IBM crypto architecture. Thanks for this, Todd. VERY interesting. The fact that System z adds this restriction seems odd. I'm sure you would have commented on it if you were able to; I can only speculate from here that it's either (a) a conservative approach, to keep mixed use from causing unsatisfactory performance for one camp or the other (e.g., a ton of SSL handshakes causes PIN operations to be slow, or vice versa) or (b) a desire to sell more cards! Any other ideas, folks? ...phsiii ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
