Redesigning hardware from the ground up
Even though impacted vendors had been working on patches since June 2017, at the end of the
embargo in January 2018 there was only a patchwork of fixes and alternative methods to mitigate the
exploits. And security executives will be managing these vulnerabilities until the next generation of
“speculative-execution proofed” hardware arrives. Unlike the software development lifecycle, which is
relatively quick with rapid update or patch cycles, hardware architecture design for the next generation
of CPUs is a much longer process. Severe hardware vulnerabilities like Spectre require replacement,
which is very costly and creates business disruption.
In short, the technology industry robbed security to get payout in processing performance. The
pressure to improve performance on existing chipsets came at the cost of security. New methods
to increase the experienced performance of the microprocessor cached sensitive code into an
unprotected area of the CPU—clearly a usage of this space that was never anticipated by the hardware
designers. A more holistic view is needed from now on, as the race for performance must be tempered
with an understanding of how systems are exploited and how systems fail.
Fortunately, there may be some software design learnings that can be applied to hardware. Software
security has long relied on the concept of least privileges and enforces segregation of data, role
and security perimeter. Beyond the classic memory corruption vulnerabilities (e.g., buffer overflow,
null pointers), most recent exploits rely on the instructions within the software’s binary to mount
sophisticated attacks known as return-oriented attacks. Recent prevention techniques against this class of
attacks are known as control flow integrity (CFI) in which the software execution path is enforced, and
the attack is detected if a violation of the excepted flow occurs with minimal performance overhead.
Businesses that moved to the cloud experienced much less disruption as large-scale cloud vendors—
including Google, Microsoft, Amazon Web Services (AWS) and Oracle—who were informed during the
embargo of Meltdown and Spectre. They were at the forefront of the solution with six months of lead
time to prepare and execute patching windows on their managed servers.
Companies relying on the cloud were left with fewer devices to patch on their own and freed from dayto-day patch management, whereas those businesses with a larger footprint/investment in proprietary
physical data centers did not have this head-start and were only notified when the embargo lifted.
When disclosure of critical vulnerabilities is a cascade effect and not a firehose, businesses with early
exposure may prove the most secure.
Companies also should not underestimate the value of hardware diversity. While CPUs were largely
affected by Meltdown and Spectre, GPU/GPGPU hardware accelerators were not affected due to the
fundamentally different way in which they manage processing. The same is true of other hardware
accelerators like field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs)
and custom hardware accelerators built by enterprises to run emerging technologies, such as virtual
reality and augmented reality applications. While this does not mean these technologies are impervious
to future attacks, the variety could provide an invaluable cross-defense in future hardware architectures.
The overarching takeaway for hardware and software developers is that they must rethink design and
protection of core functionality and features across all product sets to contain these and other types
of security issues in the future. In the meantime, security executives must dismantle some of their
foundational beliefs about hardware, software, cloud and security overall—and take a harder line on