As Jerry Stevens wrote in his March 8 blog post, the IBM System z13™ and z13s™ introduced an exciting new technology called Internal Shared Memory (ISM) which allows one z/OS instance to directly access (share) virtual memory within another z/OS instance (e.g. LPAR or guest virtual machine) within the same physical machine via DMA. At the same time, z/OS Communications Server introduced Shared Memory Communications – Direct Memory Access (SMC-D), which uses ISM so that TCP sockets applications can directly and transparently communicate with applications executing in other z/OS instances running in other Logical Partitions on the same physical z13 System. Put simply, SMC-D provides SMC-R semantics within a CPC, essentially by substituting RDMA and RoCE with DMA using ISM. (Check out Jerry's blog post for a more complete description.)
Both of the SMC technologies can provide some serious CPU reduction and equally serious throughput boosts. But what about security? How do SMC-D and SMC-R fit in with existing security domains like VLANs? What sort of isolation is available across different RoCE and ISM interfaces? And what happens to all of those security features in Communications Server when the vast majority of the application data is being passed between the communication peers using some form of DMA? We're talking about features like:
- SAF-based access controls like PORTACCESS and NETACCESS
- IP packet filtering
- Cryptographic security protocols like TLS/SSL, SSH and IPsec
- Intrusion Detection Services
How do those security features play (or not play) together with SMC-R and SMC-D?
The short answer is generally "just fine." The main reason for this happy coexistence is that SMC technologies preserve the TCP semantics for managing the sessions -- again, SMC is completely transparent to the TCP applications programs. Since many of the Communications Server's security features operate on or within some aspect of the TCP session semantics, they can continue to operate as usual. Of course, the TCP/IP stack has a little more to keep track of, and has to ensure that when a significant change occurs in the state of the TCP session (for example, access controls change on the fly, preventing access to a port that was previously permitted), the stack needs to reflect that same change on the related SMC-R or SMC-D session. But again, all of this is transparent to the applications.
For a the complete security story around Shared Memory Communications, check out this newly revised white paper . Originally published after V2R1 to explain the SMC-R security considerations, this paper is now expanded to cover SMC-D as well.
So remember, colocation, colocation, colocation, but also make sure you lock the doors and engage that security system!