The Meltdown and Spectre vulnerabilities are proving difficult to fix, and initial experiments suggest security patches will cause significant performance penalties to HPC applications. Even as these patches are rolled out to current HPC platforms, it might be helpful to explore how future HPC systems could be better insulated from CPU or operating system security flaws that could cause massive disruptions. Surprisingly, most of the core concepts to build supercomputers that are resistant to a wide range of threats have already been invented and deployed in HPC systems over the past 20 years. Combining these technologies, concepts, and approaches not only would improve cybersecurity but also would have broader benefits for improving HPC performance, developing scientific software, adopting advanced hardware such as neuromorphic chips, and building easy-to-deploy data and analysis services. This new form of “Fluid HPC” would do more than solve current vulnerabilities. As an enabling technology, Fluid HPC would be transformative, dramatically improving extreme-scale code development in the same way that virtual machine and container technologies made cloud computing possible and built a new industry.

In today’s extreme-scale platforms, compute nodes are essentially embedded computing devices that are given to a specific user during a job and then cleaned up and provided to the next user and job. This “space-sharing” model, where the supercomputer is divided up and shared by doling out whole nodes to users, has been common for decades. Several non-HPC research projects over the years have explored providing whole nodes, as raw hardware, to applications. In fact, the cloud computing industry uses software stacks to support this “bare-metal provisioning” model, and Ethernet switch vendors have also embraced the functionality required to support this model. Several classic supercomputers, such as the Cray T3D and the IBM Blue Gene/P, provided nodes to users in a lightweight and fluid manner. By carefully separating the management of compute node hardware from the software executed on those nodes, an out-of-band control system can provide many benefits, from improved cybersecurity to shorter Exascale Computing Project (ECP) software development cycles.

Updating HPC architectures and system software to provide Fluid HPC must be done carefully. In some places, changes to the core management infrastructure are needed. However, many of the component technologies were invented more than a decade ago or simply need updating. Three key architectural modifications are required.

1. HPC storage services and parallel I/O systems must be updated to use modern, token-based authentication. For many years, web-based services have used standardized technologies like OAuth to provide safe access to sensitive data, such as medical and financial records. Such technologies are at the core of many single-sign-on services that we use for official business processes. These token-based methods allow clients to connect to storage services and read and write data by presenting the appropriate token, rather than, for example, relying on client-side credentials and access from restricted network ports. Some data services, such as Globus, MongoDB, and Spark, have already shifted to allow token-based authentication. As a side effect, this update to HPC infrastructure would permit DOE research teams to fluidly and easily configure new storage and data services, both locally or remotely, without needing special administration privileges. In the same way that a website such as OpenTable.com can accept Facebook or Google user credentials, an ECP data team could create a new service that easily accepted NERSC or ALCF credentials. Moving to modern token-based authentication will improve cybersecurity, too; compromised compute nodes would not be able to read another user’s data. Rather, they would have access only to the areas for which an authentication token had been provided by the out-of-band system management layer.
2. HPC interconnects must be updated to integrate technology from software-defined networking (SDN). OpenFlow, an SDN standard, is already implemented in many commercial Ethernet switches. SDN allows massive data cloud computing providers such as Google, Facebook, Amazon, and Microsoft to manage and separate traffic within a data center, preventing proprietary data from flowing past nodes that could be maliciously snooping. A compromised node must be prevented from snooping other traffic or spoofing other nodes. Essentially, SDN decouples the control plane and data movement from the physical and logical configuration. Updating the HPC interconnect technology to use SDN technologies would provide improved cybersecurity and also isolate errant HPC programs from interfering or conflicting with other jobs. With SDN technology, a confused MPI process would not be able to send data to another user’s node, because the software-defined network for the user, configured by the external system management layer, would not route the traffic to unconfirmed destinations.
3. Compute nodes must be efficiently reinitialized, clearing local state between user jobs. Many HPC platforms were designed to support rebooting and recycling compute nodes between jobs. Decades ago, netbooting Beowulf clusters was common. By quickly reinitializing a node and carefully clearing previous memory state, data from one job cannot be leaked to another. Without this technique, a security vulnerability that escalates privilege permits a user to look at data left on the node from the previous job and leave behind malware to watch future jobs. Restarting nodes before each job improves system reliability, too. While rebooting sounds simple, however, guaranteeing that RAM and even NVRAM is clean between reboots might require advanced techniques. Fortunately, several CPU companies have been adding memory encryption engines, and NVRAM producers have added similar features; purging the ephemeral encryption key is equivalent to clearing memory. This feature is used to instantly wipe modern smartphones, such as Apple’s iPhone. Wiping state between users can provide significant improvements to security and productivity.

These three foundational architectural improvements to create a Fluid HPC system must be connected into an improved external system management layer. That layer would “wire up” the software-defined network for the user’s job, hand out storage system authentication tokens, and push a customized operating system or software stack onto the bare-metal provisioned hardware. Modern cloud-based data centers and their software communities have engineered a wide range of technologies to fluidly manage and deploy platforms and applications. The concepts and technologies in projects such as OpenStack, Kubernetes, Mesos, and Docker Swarm can be leveraged for extreme-scale computing without hindering performance. In fact, experimental testbeds such as the Chameleon cluster at the University of Chicago and the Texas Advanced Computing Center have already put some of these concepts into practice and would be an ideal location to test and develop a prototype of Fluid HPC.

These architectural changes make HPC platforms programmable again. The software-defined everything movement is fundamentally about programmable infrastructure. Retooling our systems to enable Fluid HPC with what is essentially a collection of previously discovered concepts, rebuilt with today’s technology, will make our supercomputers programmable in new ways and have a dramatic impact on HPC software development.

1. Meltdown and Spectre would cause no performance degradation on Fluid HPC systems. In Fluid HPC, compute nodes are managed as embedded systems. Nodes are given completely to users, in exactly the way many hero programmers have been begging for years. The security perimeter around an embedded system leverages different cybersecurity techniques. The CPU flaws that gave us Meltdown and Spectre can be isolated by using the surrounding control system, rather than adding performance- squandering patches to the node. Overall cybersecurity will improve by discarding the weak protections in compute nodes and building security into the infrastructure instead.
2. Extreme-scale platforms would immediately become the world’s largest software testbeds. Currently, testing new memory management techniques or advanced data and analysis services is nearly impossible on today’s large DOE platforms. Without the advanced controls and out-of-band management provided by Fluid HPC, system operators have no practical method to manage experimental software on production systems. Furthermore, without token-based authentication to storage systems and careful network management to prevent accidental or mischievous malformed network data, new low-level components can cause system instability. By addressing these issues with Fluid HPC, the world’s largest platforms could be immediately used to test and develop novel computer science research and completely new software stacks on a per job basis.
3. Extreme-scale software development would be easier and faster. For the same reason that the broader software development world is clamoring to use container technologies such as Docker to make writing software easier and more deployable, giving HPC code developers Fluid HPC systems would be a disruptive improvement to software development. Coders could quickly test deploy any change to the software stack on a per-job basis. They could even use machine learning to automatically explore and tune software stacks and parameters. They could ship those software stack modifications across the ocean in an instant, to be tried by collaborators running code on other Fluid HPC systems. Easy performance regression testing would be possible. The ECP community could package software simply. We can even imagine running Amazon-style lambda functions on HPC infrastructure. In short, the HPC community would develop software just as the rest of the world does.
4. The HPC community could easily develop and deploy new experimental data and analysis services. Deploying an experimental data service or file system is extremely difficult. Currently, there are no common, practical methods for developers to submit a job to a set of file servers with attached storage in order to create a new parallel I/O system, and then give permission to compute jobs to connect and use the service. Likewise, HPC operators cannot easily test deploy new versions of storage services against particular user applications. With the Fluid HPC model, however, a user could instantly create a memcached-based storage service, MongoDB, or Spark cluster on a few thousand compute nodes. Fluid HPC would make the infrastructure programmable; the impediments users now face deploying big data applications on big iron would be eliminated.
5. Fluid HPC would enable novel, improved HPC architectures. With intelligent and programmable system management layers, modern authentication, software-defined networks, and dynamic software stacks provided by the basic platform, new types of accelerators—from neuromorphic to FPGAs—could be quickly added to Fluid HPC platforms. These new devices could be integrated as a set of disaggregated network-attached resources or attached to CPUs without needing to support multiuser and kernel protections. For example, neuromorphic accelerators could be quickly added without the need to support memory protection or multiuser interfaces. Furthermore, the low-level software stack could jettison the unneeded protection layers, permission checks, and security policies in the node operating system.

It is time for the HPC community to redesign how we manage and deploy software and operate extreme-scale platforms. Computer science concepts are often rediscovered or modernized years after being initially prototyped. Many classic concepts can be recombined and improved with technologies already deployed in the world’s largest data centers to enable Fluid HPC. In exchange, users would receive improved flexibility and faster software development—a supercomputer that not only runs programs but is programmable. Users would have choices and could adapt their code to any software stack or big data service that meets their needs. System operators would be able to improve security, isolation, and the rollout of new software components. Fluid HPC would enable the convergence of HPC and big data infrastructures and radically improve the environments for HPC software development. Furthermore, if Moore’s law is indeed slowing and a technology to replace CMOS is not ready, the extreme flexibility of Fluid HPC would speed the integration of novel architectures while also improving cybersecurity.

It’s hard to thank Meltdown and Spectre for kicking the HPC community into action, but we should nevertheless take the opportunity to aggressively pursue Fluid HPC and reshape our software tools and management strategies.

*Acknowledgments: I thank Micah Beck, Andrew Chien, Ian Foster, Bill Gropp, Kamil Iskra, Kate Keahey, Arthur Barney Maccabe, Marc Snir, Swann Peranau, Dan Reed, and Rob Ross for providing feedback and brainstorming on this topic.

About the Author

Pete Beckman is the co-director of the Northwestern University / Argonne Institute for Science and Engineering and designs, builds, and deploys software and hardware for advanced computing systems. When Pete was the director of the Argonne Leadership Computing Facility he led the team that deployed the world’s largest supercomputer for open science research. He has also designed and built massive distributed computing systems. As chief architect for the TeraGrid, Pete oversaw the team that built the world’s most powerful Grid computing system for linking production HPC centers for the National Science Foundation. He coordinates the collaborative research activities in extreme-scale computing between the US Department of Energy (DOE) and Japan’s ministry of education, science, and technology and leads the operating system and run-time software research project for Argo, a DOE Exascale Computing Project. As founder and leader of the Waggle project for smart sensors and edge computing, he is designing the hardware platform and software architecture used by the Chicago Array of Things project to deploy hundreds of sensors in cities, including Chicago, Portland, Seattle, Syracuse, and Detroit. Dr. Beckman has a Ph.D. in computer science from Indiana University (1993) and a BA in Computer Science, Physics, and Math from Anderson University (1985).