Examining IBM z/Architecture Security Features, Layer by Layer

IBM’s z/Architecture and z/OS provide a comprehensive and layered approach to enterprise-grade security, offering features designed to meet the substantial needs of the enterprise community, especially those in highly regulated industries. This article is the first in a two-part series focusing on system and application security across the hardware and software landscape. Here, I will concentrate on z/Architecture, which is a way of centering on hardware. In the second article, I will turn my attention to software, focusing on z/OS security.

What About the Firmware Stuff in the Middle?

It is common to talk about hardware and software, but in my experience, we don’t talk often about microcode and millicode. Some IT people don’t realize that a portion of IBM System Z hardware functionality is supported by microcode, particularly in the form of millicode, which is a specialized type of microcode used in System Z processors.

Microcode and Millicode in System Z

Microcode is a low-level layer of instructions that implements the machine’s instruction set. It also controls many hardware operations. Millicode is a System Z-specific form of microcode that allows complex instructions to be implemented more efficiently. It runs on the same processor as the main instruction set and is used to implement complex instructions. It also handles interrupt processing and provides backward compatibility. It can be used to apply patches for hardware bugs without physical changes. Its many uses come at an operational cost (hardwired versus instruction cycles), but the benefits far outweigh the costs.

Nearly all modern System Z hardware components, like processors, I/O subsystems and logical partitioning, rely on microcode for operation. Microcode enables hardware abstraction, for example, allowing different generations of hardware to support the same z/Architecture and z/OS software stack. IBM provides microcode updates (often called MCLs—Microcode Control Levels) to enhance functionality, fix bugs or support new features (without requiring hardware changes).

To understand the “for what” and “where” of microcode in IBM Z, see the illustration on page 7 in this 2018 presentation, “What is Millicode and why do I care?” by Brenton Belmar. The figure below explains the “for what” and “where” of microcode in IBM Z. Many other figures in the presentation make it easier to understand the various aspects of the firmware topic. I found myself thinking “I didn’t know that” frequently. It is just 26 pages long and well worth a read.

Let’s move on to z/Architecture security features.

What Are Some of the Main IBM z/Architecture Security Features?

IBM z/Architecture is the hardware foundation for IBM Z mainframes. It is an architecture that covers a vast computing domain involving instructions and the organization of main storage, expanded storage and CPUs. I want to focus on four specific security feature areas—cryptography, boot and firmware protection, logical partitioning and trusted execution environment. However, if you are interested in reading more about the  z/Architecture, independent of the security topic, look at the z/Architecture Principles of Operation document. 

Hardware-Based Cryptography

IBM Z systems include dedicated cryptographic hardware components including the Central Processor Assist for Cryptographic Function (CPACF), which is integrated into every processor core. It accelerates symmetric key algorithms like AES, DES, hashing (SHA) and random number generation. It is also ideal for high-speed, bulk encryption. IBM Z also has Crypto Express (CEX) Adapters. These are optional, pluggable hardware security modules (HSMs) that support secure key management, digital signatures and public key cryptography like RSA and ECC. They can operate in Common Cryptographic Architecture (CCA) or PKCS#11 mode.

There are significant benefits of Hardware-Based Cryptography on IBM Z—in the areas of performance, security, scalability and compliance. Regarding performance improvement, this happens when the hardware offloads cryptographic processing from the CPU. Security is improved as keys can be generated, stored and used entirely within secure hardware. Scalability is improved as the hardware supports large-scale, enterprise-grade workloads. Compliance is helped as well, and the implementation meets standards like FIPS 140-2 Level 4 (for Crypto Express). Hardware-based cryptography is a good fit for secure online banking and financial transactions. Also, encrypted databases and file systems, digital signatures and certificate management are good use cases.

Secure Boot and Firmware Protection

Secure Boot is a platform-level security feature that ensures only trusted, signed code is executed during the system’s Initial Program Load (IPL). IPL is the mainframe equivalent of booting that is performed on other computers. This protection has several important features.  During IPL, all components like the initial boot code must be digitally signed. If any component is unsigned or tampered with, the boot process fails.

This protection was first available with IBM z15 and continues to be enhanced. Secure Boot supports booting from various storage types like ECKD DASD, SCSI, and Non-Volatile Memory Express (NVMe). Certificate management requires that  public keys used to verify signatures must be uploaded to the Hardware Management Console (HMC).

Firmware protection ensures that the system firmware itself is secure and cannot be subject to tampering. IBM Z systems use digitally signed firmware that is verified at every boot. Think of this as immutable (does not change over time) firmware. If firmware is altered or corrupted, the system will detect it and halt the boot process. The entire boot process, from firmware to OS, is cryptographically verified, forming a chain of trust.

These features help to meet regularity compliance standards like Federal Information Processing Standards (FIPS), National Institute of Standards and Technology (NIST) and General Data Protection Regulation (GDPR). Their benefits include protecting against rootkits by preventing unauthorized low-level code from executing, while they also help with cloud and multi-tenant security, which is important for secure virtualization and containerization in enterprise environments.

Logical Partitioning

Logical Partitions (LPARs) are a key feature of IBM z/Architecture mainframes. LPARs are a form of hardware-level virtualization. They are built into the hardware and are highly secure due to hardware-level isolation. LPARs are not a security feature as such but rather leverage the security that is pervasive in the architecture.

LPARs allow a single physical mainframe to be divided into multiple independent logical systems, each running its own hypervisors and operating system as shown in Table 1 below. Each LPAR is allocated a portion of the system’s resource—CPU, memory and I/O subsystem.

Table 1. Systems that Run in an LPAR

Hypervisors
	z/VM	IBM z/VM is a security-rich and scalable hypervisor and virtualization product. It is designed to run guest servers such as Linux, z/OS and z/TPF as virtual machines. It also supports Red Hat OpenShift on IBM Z and LinuxONE servers. z/VM is also an OS that runs a wide variety of specialized applications. It has a rich built-in toolset that enterprise customers have leveraged for decades.
	KVM	Kernel-based Virtual Machine is an open-source virtualization technology for Linux operating systems.
Operating Systems
	z/OS	The flagship operating system for IBM Z mainframes.
	Linux on IBM Z	Linus on Z is a Linux distribution specifically compiled for the z/Architecture.
	z/TPF	Transaction Processing Facility (TPF) is a specialized operating system for high-volume, real-time transaction processing used by airlines, banking and finance companies. Other enterprises that benefit from high-volume transaction processing include those that handle hotel and car reservations.

Each LPAR is isolated from others, ensuring security and stability. Resources can be dynamically allocated or shared among LPARs. Multiple workloads can run simultaneously on different LPARs. There is a hypervisor built into IBM Z hardware that manages LPARs called Processor Resource/System Manager (PR/SM). PR/SM is certified under rigorous standards like Common Criteria EAL5+, one of the highest levels of assurance for commercial IT products. This certification confirms that PR/SM enforces strict security boundaries.

There are many practical implementations of LPARs, like running production and test environments on the same physical machine or hosting multiple operating systems for different applications. LPARs are also used to support high availability and disaster recovery setups and implementations.

Trusted Execution Environment

The z/Architecture Trusted Execution Environment (TEE) refers to a secure computing environment first implemented on IBM z13 systems and LinuxONE. It is designed to protect and isolate critical workloads from both internal and external threats, offering a higher level of security than standard software environments. The feature was later rebranded as IBM Secure Service Container (SSC) with the launch of the IBM z14 and LinuxONE Emperor II models in 2017. Further enhancements to TEE capabilities came with the introduction of IBM Secure Execution in the IBM z15 and LinuxONE III generation machines in 2020. Additionally, both the IBM z16 and z17 systems have prioritized robust security and TEEs.

IBM’s implementation is known as Secure Execution for Linux, which enables running Linux workloads in a hardware-isolated environment. TEE supports confidential computing principles, ensuring that data is encrypted not only at rest and in transit but also during processing. Each workload runs in its own isolated enclave, preventing unauthorized access even from privileged users or the host OS.

IBM’s Secure Execution for Linux allows Linux distributions like Ubuntu 20.04 LTS to run in this trusted environment on IBM Z systems. This setup is particularly useful for enterprises that require strong data protection and compliance with strict regulatory standards. There is an upgrade path with Ubuntu 20.04, at the Pro level, which provides support to 2030.

What is Next?

In the next article about z/OS security, I will focus on the software options and products that are part of z/OS, like Resource Access Control Facility, multifactor authentication, and auditing and compliance. This software layer adds to the security features already discussed in in this article.

---