| commit | a109221c6e66c040f054ca6db1969aa1b7d2fad4 | [log] [tgz] |
|---|---|---|
| author | Venkatesh Srinivas <venkateshs@chromium.org> | Thu Jun 18 21:07:33 2020 +0000 |
| committer | Venkatesh Srinivas <venkateshs@chromium.org> | Thu Jun 18 21:25:05 2020 +0000 |
| tree | 2efe1dd37920ba20f602be8f0eb8494236caf69d | |
| parent | a0a9c8ac2cea29c302350dfbbad90fb93a3847d7 [diff] |
Fuchsia: Add BUILD.gn for ret2spec_sa demo * ret2spec_sa is a demo of a Spectre V2 variant focused on attacking return address stacks / link stacks. * Add the demo as a binary to get started; next we will wire in our mitigations and test the building blocks (for example, x86_ras_fill) Bug: 12540 Speculative Execution Mitigations. Bug: 33667 Spectre mitigations? Change-Id: Icaca5cd77f553733172b4f828eacc1dd899b45fb
SafeSide is a project to understand and mitigate software-observable side-channels: information leaks between software domains caused by implementation details outside the software abstraction.
Unlike other side-channel attacks -- e.g. measuring power use or electromagnetic emissions -- software-observable side-channels don't require physical access or proximity.
Our early focus is on transient execution attacks and leaks from software cryptography implementations.
This repository provides a home for:
Practical demonstrations
Robust, portable examples that leak data through different side-channels under real-world conditions.
For more on building and running our examples, see the demos README.
Documentation
References to research that describes what causes side-channels and how they behave.
Docs are here.
Mitigation development
Ideas and prototypes for how to find and stop side-channel leaks.
This project is new and under active development. To start, we have a few examples of Spectre side-channel leaks and a collection of links we've found useful.
For more information on our plans and priorities, see our Roadmap.
This project is focused on defense. While we enthusiastically believe in the value of adversarial testing (e.g. red teaming) for securing software systems, this repository is not intended to advance the state of the art for attackers.
To that end, we have some ground rules:
No nonpublic attacks. This isn't the place to research new side-channels, discuss any embargoed or otherwise undisclosed vulnerabilities, or try to bypass currently-effective mitigations.
No exploits that leak interesting data. We want to show side-channels in action, but we will only leak synthetic data that we put there to be leaked.
These are the areas where we plan to spend our effort and where we think contributions will be most useful.
We‘re not satisfied with an archive of proof-of-concept apps. The examples in this repository should read like Knuth-style literate programs, making it abundantly clear how the infoleak functions end-to-end: what setup is strictly necessary; what implementation behaviors we’re relying on or working around; and what we've added to make the demonstration more robust.
This standard applies to our examples, the library code they share, and the support infrastructure we provide to get things running.
We're always on the lookout for ways we can make examples in this project simpler to understand. We expect that will most often mean better comments and better factoring of code. But sometimes it will mean step-function improvements through entirely new, more straightforward approaches.
These examples are each designed to exercise specific vulnerabilities, and they should produce consistent and useful results anywhere those leaks are present.
This could mean amplifying or cleaning up side-channel signal (on the producer or consumer side) or retrying on failure.
This project hopes to provide examples of every kind of software-observable side-channel. They should run in as many environments as they can to enable comprehensive testing of mitigations. We think we're off to a good start, but we hope to improve our coverage along several dimensions.
We should have examples embodying most or all known timing leak sources, including (non-exhaustively): Spectre (all variants), Meltdown, Speculative Store Bypass, L1 Terminal Fault (L1TF), and Microarchitectural Data Sampling (MDS).
Our examples should compile with GCC, Clang, and Microsoft Visual C++ (MSVC). (Stretch: ICC.)
Our examples should build and produce useful results on macOS, Windows, and Linux -- including, where possible, when those OSes are running virtualized. Eventually we also hope to provide something worth running on iOS and Android.
We intend to explore more virtualized scenarios over time, in which case we will want to cover a diversity of hypervisors and VMMs.
Our examples should cover known ways of establishing covert side-channels. Data or instruction cache timing are most popular, but we should also explore execution unit contention (SMoTherSpectre) or activation latency (NetSpectre).
We want to show information leaks across a variety of typical security boundaries. In what we think is roughly increasing order of difficulty:
We expect many of these examples will require turning off existing mitigations or security features that are widely deployed. When we want to demonstrate an attack that isn‘t possible on a modern, patched system, we’ll provide infrastructure to create an old, unpatched system.
We want examples that provide clear positive (or negative) results across a wide range of processor generations from different vendors across different architectures. That said, we'll also generally prioritize working examples for hardware with the broadest deployment.
We want to demonstrate timing leaks against analogues of different kinds of data-handling code: serialization, cryptographic algorithms, application business logic, etc.
We believe the robustness of our samples, and the usefulness of potential mitigations, can be evaluated by extracting metrics that can be compared across instances. Bandwidth -- correct bytes leaked per unit time -- seems like one obvious choice.
We want to make it easy to run many examples across many environments quickly and reproducibly. This supports our mission of enabling quantitative comparison, and should allow for a quick feedback loop for developers prototyping new software-based mitigations.
One of the goals of producing a broad set of examples is to be able to show the effectiveness of mitigations, so we also want to add infrastructure to build and test with existing mitigations enabled.
For example:
/Qspectre-mspeculative-load-hardening-mfunction-return and -mindirect-branchWe eagerly welcome contributions. Please take a look at our contributing guidelines for more on how to engage with the project.
If you‘ve found a bug or think something’s missing, please file an issue.
For general discussion about side-channels or for questions about the project's goals and roadmap, use our safeside-discuss group.
This is not an officially supported Google product.