Hardware-software interfaces for security

In today’s security-first era, what new hardware-software interfaces are required?

Hardware-software layers with lock

Security has become a first-order design constraint. The software development community has already recognized this, and it is now clear computer architecture must also design systems with security in mind. However, this requires revisiting decades-old hardware development patterns.

Many of the architectural innovations that have driven the increase in compute capability for the past 50 years were designed ignoring their security implications. It is time for us to revisit many of these microarchitectural optimizations with security in mind.

Secure High-performance computing

Scientific data today is at risk due to how it is collected, stored, and analyzed in highly disparate computing systems. How can we make claims about the integrity of data as it traverses open, international networks and via instruments and systems with widely varying reliability and provenance? Numerous causes for integrity loss are possible, including bugs in existing computational pipelines, network events, user error, unintentional system effects or even intentional attack by outsiders (e.g., scientific competitors), insiders (e.g., disgruntled employees), or in the hardware/software supply chain, without any trace of the modification. Given these gaps and shortcomings in existing HPC solutions, how can we make claims about the integrity of the scientific data as it traverses those systems and networks?

We believe that in order to solve the problems described above that future HPC hardware and software solutions should be co-designed together with security and scientific computing integrity concepts designed and built into as much of the stack from the outset as possible. Given the risk of data loss due to software and hardware, this should take into account hardware elements, operating systems, compilers, application software, and the networking stack, all the way down to the way in which software developers write software and users interact with systems in a way that can affect scientific computing integrity. However, prior to laying out the research roadmap to design and construct such an architecture, we believe that several important aspects first need to be understood more clearly.

This project takes a broad look at several aspects of security and scientific integrity issues in HPC systems. Using several case studies as exemplars, and working closely with both domain scientists as well as facility staff, we propose to test and validate several initial concepts in existing scientific computing workflows at NERSC DOE HPC facility, and analyze those models better characterize integrity-related computational behavior.

This project is in collaboration with Sean Peisert at Lawrence Berkeley National Labs. See also the LBL project page.


Prior work

We published a paper arguing that traditional ISAs’ architectural state is no longer adequate in the security-first era. Instead of defining how instructions change the architectural state, we argue that the ISA should also formally define how instructions will affect the extra-architectural state. The extra-architectural state is any state in the processor for which changes can be perceived by others in the system (e.g., the addresses currently cached in the L1 cache).

More details can be found in our HASP paper.

Future projects

We’re looking for motivate students to work on new projects in this space. Specifically, we’re looking for students with experience using Chisel and implementing RISC-V cores so we can add new security instructions and test out new hardware-software interfaces.

If you are interested in working on this contact Prof. Jason Lowe-Power.