sandsifter
sail-riscv
Our great sponsors
sandsifter | sail-riscv | |
---|---|---|
15 | 9 | |
4,826 | 390 | |
- | 4.1% | |
0.0 | 8.2 | |
2 months ago | 2 days ago | |
Python | Coq | |
BSD 3-clause "New" or "Revised" License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sandsifter
- Cascade: CPU Fuzzing via Intricate Program Generation
- Sandsifter: The x86 Processor Fuzzer
- How would undocummented, private ISA extensions work in Linux-based systems?
- I found a bug in Intel Skylake processors
-
Is there any opensource switch brand?
This has some background.
- Clever Hack Finds Mystery CPU Instructions
- Sandsifter – The x86 Processor Fuzzer
-
The Cursed Computer Iceberg Meme
sandsifter
-
Speculating the Entire x86-64 Instruction Set in Seconds with One Weird Trick
This is a really clever technique! I was impressed by sandsifter[1] when it originally came out, and this seems an awful lot faster and less prone to false negatives (since it's purely speculative and doesn't require sandsifter's `#PF` hack).
At the risk of unwarranted self-promotion: the other side of this equation is fidelity in software instruction set decoders. x86's massive size and layers of historical complexity make it among the most difficult instruction formats to accurately decode; I've spent a good part of the last two years working on a fuzzer that's discovered thousands of bugs in various popular x86 decoders[2][3].
[1]: https://github.com/xoreaxeaxeax/sandsifter
[2]: https://github.com/trailofbits/mishegos
[3]: https://ww.easychair.org/publications/preprint_download/1LHr
-
Capstone Disassembler Framework
Idea:
If any assembler/disassembler author/team out there wants to produce an assembler/disassembler which is authoritative (difficult to do on x86, because there are so many different possible combinations of instruction encoding, https://github.com/xoreaxeaxeax/sandsifter : "Typically, several million undocumented instructions on your processor will be found, but these generally fall into a small number of different groups.") -- then what they'd do is to create a third program -- which "pits" the output of Assembler A vs. Assembler B, Disassembler A vs. Disassembler B...
That is, between any two assemblers (for the same CPU architecture/instruction set), or any two disassemblers, where are the anomalies?
If we think about an assembler as a simple function, y=f(x), that is, I give it a string of ascii bytes as input (x), and I get a string (1..n) binary bytes as output (y),
sail-riscv
-
How to improve the RISC-V specification
I've been doing a lot of work with Sail (not SAIL btw) and I'm not sure I agree with the points about it.
There's already a way to extract functions into asciidoc as the author noted. I've used it. It works well.
The liquid types do take some getting used to but they aren't actually used in most of the code; mostly for utility function definitions like `zero_extend`. If you look at the definition for simple instructions they can be very readable and practically pseudocode:
https://github.com/riscv/sail-riscv/blob/0aae5bc7f57df4ebedd...
A lot of instructions are more complex or course but that's what you get if you want to precisely define them.
Overall Sail is a really fantastic language and the liquid types really help avoid bugs.
The biggest actual problems are:
1. The RISC-V spec is chock full of undefined / implementation defined behaviour. How do you capture that in code, where basically everything is defined. The biggest example is probably WARL fields which can do basically anything. Another example is decomposing misaligned accesses. You can decompose them into any number of atomic memory operations and do them in any order. E.g. Spike decomposes them into single byte accesses. (This problem isn't really unique to Sail tbf).
2. The RISC-V Sail model doesn't do a good job of letting you configure it currently. E.g. you can't even set the spec version at the moment. This is just an engineering problem though. We're hoping to fix it one day using riscv-config which is a YAML file that's supposed to specify all the configurable behaviour about a RISC-V chip.
I definitely agree about the often wooly language in the spec though. It doesn't even use RFC-style MUST/SHOULD/MAY terms.
-
RISC-V Vector benchmark results
The official formal specification of the Vector Extension has just been merged into the Golden RISC-V model:
https://github.com/riscv/sail-riscv/commit/c90cf2e6eff5fa4ef...
-
Cascade: CPU Fuzzing via Intricate Program Generation
the retired instruction counters when written by software.
Funnily enough the Sail model had this bug too! https://github.com/riscv/sail-riscv/issues/256
-
Arm’s Cortex A510: Two Kids in a Trench Coat
> loose specification of the RISC-V ISA.
This is being worked on with the Sail model [1]. In order for a RISC-V extension to be ratified it ought to be implemented in Sail. The understanding is also that the RISC-V ISA manual should be built with code snippets from the Sail model (similar to how the Arm Arm is build from ASL definition). The main issue is a lack of people willing and able to write Sail for RISC-V. But that is beginning to change, since RISC-V member companies are increasingly use Sail. As an example, the RISC-V exception type is defined in [2]. Is that precise enough for you?
[1] https://github.com/riscv/sail-riscv
[2] https://github.com/riscv/sail-riscv/blob/master/model/riscv_...
-
RISC-V CPU formal specification F# edition
>it allows to formally verify the correctness of a particular ISA
That must be hypothetical. Functionalness of the language doesn't make anything that is written in it automatically subject to formal verification. (mechanized or pen and paper). What kind of correctness properties does it actually allow to formally verify? I understand if it was the F* language, which is a full blown dependently typed proof checker, but with F#, which is defined by the implementation and 300 page English spec, I don't think you can verify anything interesting. As far as I know F# itself doesn't have mechanized formal semantics and its type system could be unsound.
https://github.com/mit-plv/riscv-coq and https://github.com/riscv/sail-riscv (don't know how complete they are) approaches actually allow to formally (mechanically) verify riscv properties.
- 64-bit Arm ∩ 64-bit RISC V
- C++17 RISC-V RV32/64/128 userspace emulator library
-
Starting up with RISC-V
I guess you will also use Spike and the Sail model for RISC-V.
-
Areas to contribute in RISC-V RTL verification
Doing something leveraging the SAIL model would be valuable, as that's the official formal model: https://github.com/rems-project/sail-riscv
What are some alternatives?
trapcc - Computing with traps
litmus-tests-riscv - RISC-V architecture concurrency model litmus tests
tatradas - Disassembler for x86 executables (16-bit and 32-bit) which supports PE, NE, MZ, COM and ELF file formats
riscv-isa-sim - Spike, a RISC-V ISA Simulator
fuzzing - Tutorials, examples, discussions, research proposals, and other resources related to fuzzing
riscv-dv - Random instruction generator for RISC-V processor verification
lazarus - Free Pascal Lazarus Project - Sync'ed with Lazarus SubVersion trunk every 15 minutes
riscv-coq - RISC-V Specification in Coq
capstone - Capstone disassembly/disassembler framework: Core (Arm, Arm64, BPF, EVM, M68K, M680X, MOS65xx, Mips, PPC, RISCV, Sparc, SystemZ, TMS320C64x, Web Assembly, X86, X86_64, XCore) + bindings. [Moved to: https://github.com/capstone-engine/capstone]
libriscv - C++20 RISC-V RV32/64/128 userspace emulator library
docs - Hardware and software docs / wiki
force-riscv - Instruction Set Generator initially contributed by Futurewei