Git Product home page Git Product logo

sca-fuzzer's Introduction

Revizor

GitHub PyPI GitHub all releases GitHub contributors

Revizor is a security-oriented fuzzer for detecting information leaks in CPUs, such as Spectre and Meltdown. It tests CPUs against Leakage Contracts and searches for unexpected leaks.

For more details, see our Paper (open access here), and the follow-up papers (1, 2).

Getting Started and Documentation

You can find a quick start guide at Quick Start.

For information on how to use Revizor, see User Documentation.

For information on how to contribute to Revizor, see CONTRIBUTING.md.

Need Help with Revizor?

If you find a bug in Revizor, don't hesitate to open an issue.

If something is confusing or you need help in using Revizor, we have a discussion page.

Citing Revizor

To cite this project, you can use the following references:

  1. Original paper that introduced the concept of Model-based Relation Testing as well as the Revizor tool:

    Oleksii Oleksenko, Christof Fetzer, Boris Köpf, Mark Silberstein. "Revizor: Testing Black-box CPUs against Speculation Contracts" in Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), 2022.

  2. Theoretical foundations of leakage contract:

    Marco Guarnieri, Boris Köpf, Jan Reineke, and Pepe Vila. "Hardware-software contracts for secure speculation" in Proceedings of the 2021 IEEE Symposium on Security and Privacy (SP), 2021.

  3. Accessible summary of the two papers above, in a journal format:

    Oleksii Oleksenko, Christof Fetzer, Boris Köpf, Mark Silberstein. "Revizor: Testing Black-box CPUs against Speculation Contracts". In IEEE Micro, 2023.

  4. Paper that introduced speculation filtering, observation filtering, and contract-based input generation:

    Oleksii Oleksenko, Marco Guarnieri, Boris Köpf, and Mark Silberstein. "Hide and Seek with Spectres: Efficient discovery of speculative information leaks with random testing" in Proceedings of the 2023 IEEE Symposium on Security and Privacy (SP), 2022.

  5. Paper that introduced exception-based testing (i.e., focus on Meltdown, Foreshadow) into Revizor:

    Jana Hofmann, Emanuele Vannacci, Cédric Fournet, Boris Köpf, and Oleksii Oleksenko. "Speculation at Fault: Modeling and Testing Microarchitectural Leakage of CPU Exceptions." in Proceedings of 32nd USENIX Security Symposium (USENIX Security), 2023.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

sca-fuzzer's People

Contributors

aidan5806 avatar bkoepf avatar brianfu avatar cwshugg avatar flaviens avatar janahofmann avatar mguarnieri avatar microsoftopensource avatar oleksiioleksenko avatar van-ema avatar

sca-fuzzer's Issues

Allowing arch fuzzer minimizations causes regular fuzzer issues

548dbd1

Cannot pass arch fuzzer acceptance tests when dummy measurement enabled.

Failing tests (in acceptance.bats):

Architectural Test: Model and Executor are initialized with the same values (memory)
Architectural Test: Model and Executor are initialized with the same values (flags)
Architectural Test: Model and Executor are initialized with the same values (SIMD registers)

Run to test:

./revizor.py fuzz -s base.json --save-violations f -I tests/x86_tests/configs -t tests/x86_tests/asm/model_flags_match.asm -c tests/x86_tests/configs/arch.yaml -i 20
./revizor.py fuzz -s base.json --save-violations f -I tests/x86_tests/configs -t tests/x86_tests/asm/model_match_memory.asm -c tests/x86_tests/configs/arch.yaml -i 20

This is since any inst that moves r14 (i.e. mov rax, r14) into another register causes an architectural violation. This seems correct to me; Sandbox between the model and executor should be allowed to differ; It shows up as being placed at 0x0 for the model, whereas it's placed at some (non-deterministic) location in memory for the executor. Is this actually an issue? Or just a matter of removing the inst from the tests?

The arch fuzzer fuzzing pass always works. As well, when the violating inst is commented out (and test case changed to accommodate), the tests work fine.

Adding these will make regular fuzzing runs show arch violations when there are none. Example:

WARNING: [fuzzer] Architectural violation detected
Input 0:
  Model Registers:
  rax:0000000000000035 rbx:26441a3026441a30 rcx:00000000000000f8 rdx:0000000000001e9c rsi:0000000000001406 rdi:00000000000015da 
  HW Registers:   
  rax:0000000000000035 rbx:26441a3026441a30 rcx:00000000000000f8 rdx:0000000000001e9c rsi:0000000000001406 rdi:00000000000015da 
  • This is nonsensical; Ending reg values are same for both model and executor yet arch fuzzer shows a violation anyway?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.