Beyond Spectre: Confronting New Technical and Policy Challenges Proceedings of a Workshop (2019) / Chapter Skim
Currently Skimming:
1 Workshop Context and the Story of Spectre
1 Workshop Context and the Story of Spectre
Pages 1-12
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 1... ...
And second, the vulnerable hardware is deployed in millions of devices manufactured by multiple companies worldwide. The discovery upends a number of common assumptions about cybersecurity and draws attention to the complexities of the global supply chain and global customer base for the vast range of devices and cloud capabilities that all computer users rely on.
|
From page 2... ...
OPENING REMARKS Fred B Schneider, Cornell University, a member of the National Academy of Engineering and chair of the Forum on Cyber Resilience, opened the meeting with a brief introduction to the Forum on Cyber Resilience and a framing discussion for the day.
|
From page 3... ...
Mitigating the attack risk in this case could reduce computing speed, might not be 100 percent effective, and might even cause the hardware to become nonfunctional. Fixing the vulnerability would require completely redesigning processors and disseminating the fix through a highly complex supply chain that includes producers of the chips, device manufacturers who put those chips in devices, and ultimately product users.
|
From page 4... ...
treat data in ways Schneider described the general problem. Security of a given layer is that violate the usual typically achieved by making assumptions assumptions software about what behaviors lower layers allow and forbid.
|
From page 5... ...
THE STORY OF SPECTRE Paul Kocher, independent researcher and member of the forum, was one of the researchers that discovered the Spectre vulnerability. He delivered a keynote address describing the process of Spectre's discovery and disclosure, and he offered insights on its implications.
|
From page 6... ...
Because of Speculative this huge performance gain, most existing execution opens devices have very complex memory caches. Other optimizations to improve a serious security performance include multitasking, performing instructions in a more efficient vulnerability.
|
From page 7... ...
The speculative memory read modifies the state of the memory cache, allowing an attacker to determine sensitive data values even after the actual read operation is unwound. This occurs because, if the attacker subsequently performs a memory read at each potential address for the second memory read, the address actually read during speculative execution will return much more quickly, while reads from other locations will be much slower because that data are uncached.1 The situation with Spectre resulted from three fundamental gaps, Kocher said.
|
From page 8... ...
The third problem Kocher pointed to is an expertise gap: few security experts specialize in hardware details, and few hardware designers specialize in security. This has created a situation in which vulnerabilities involving hardware or the hardware software interface can slip through unnoticed.
|
From page 9... ...
Software-only approaches have also been challenging, Kocher explained, due to issues including differences in processor architectures, lack of information about The hardware- proprietary hardware designs, lack of suitable development tools, performance based nature of the impact, testing/verification challenges, and Spectre vulnerability the difficulty of fixing legacy code. After discovering the vulnerability, makes reducing its Kocher described how he followed the severity particularly standard industry practice for responsible disclosure.
|
From page 10... ...
data disclosure attacks due to differential power usage and power glitches, and low probability errors due to race conditions in distributed systems; (4) lack of availability as serious as complete hardware destruction due to nonvolatile memory write exhaustion, overheating, or electromigration; (5)
|
From page 11... ...
In a brief question-and-answer session, Butler Lampson, Microsoft, asked how reverting to a prespeculative execution and precaching operational model would affect performance speeds. Noting that speculative execution has been around for almost 30 Beyond Spectre 11
|
From page 12... ...
Kocher added that fixing or mitigating for Spectre could create a modest performance hit while still leaving systems vulnerable to attack from new variants. Even without speculative execution, processors would not be truly secure.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.