syzkaller
CompCert
syzkaller | CompCert | |
---|---|---|
7 | 37 | |
5,166 | 1,793 | |
0.8% | 1.7% | |
9.8 | 7.5 | |
5 days ago | 11 days ago | |
Go | Coq | |
Apache License 2.0 | 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.
syzkaller
-
Automated Unit Test Improvement Using Large Language Models at Meta
https://arxiv.org/abs/2402.09171 :
> This paper describes Meta's TestGen-LLM tool, which uses LLMs to automatically improve existing human-written tests. TestGen-LLM verifies that its generated test classes successfully clear a set of filters that assure measurable improvement over the original test suite, thereby eliminating problems due to LLM hallucination. [...] We believe this is the first report on industrial scale deployment of LLM-generated code backed by such assurances of code improvement.
Coverage-guided unit test improvement might [with LLMs] be efficient too.
https://github.com/topics/coverage-guided-fuzzing :
- e.g. Google/syzkaller is a coverage-guided syscall fuzzer: https://github.com/google/syzkaller
- Gitlab CI supports coverage-guided fuzzing: https://docs.gitlab.com/ee/user/application_security/coverag...
- oss-fuzz, osv
Additional ways to improve tests:
Hypothesis and pynguin generate tests from type annotations.
There are various tools to generate type annotations for Python code;
> pytype (Google) [1], PyAnnotate (Dropbox) [2], and MonkeyType (Instagram) [3] all do dynamic / runtime PEP-484 type annotation type inference [4] to generate type annotations. https://news.ycombinator.com/item?id=39139198
icontract-hypothesis generates tests from icontract DbC Design by Contract type, value, and invariance constraints specified as precondition and postcondition @decorators:
-
Differ: Tool for testing and validating transformed programs
https://google.github.io/clusterfuzz/setting-up-fuzzing/libf...
> OSS-Fuzz runs CloudFuzz[Lite?] for many open source repos and feeds OSV OpenSSF Vulnerability Format: https://github.com/google/osv#current-data-sources
.
Google/syzkaller https://github.com/google/syzkaller :
>> syzkaller is an unsupervised coverage-guided kernel fuzzer. Supported OSes: Akaros, FreeBSD, Fuchsia, gVisor, Linux, NetBSD, OpenBSD, Windows
.
ghidra-patchdiff-correlator:
-
Fuzz Testing Is the Best Thing to Happen to Our Application Tests
The key to modern fuzzing is feedback, usually some kind of coverage testing of the program under test. This allows the fuzzer to be much smarter about how it finds new code paths, and makes fuzzing find bugs a lot quicker.
Google have a project to do fuzzing on Linux system calls using coverage feedback: https://github.com/google/syzkaller
-
Is there a Linux user-space program that causes execution through every kernel function path and context?
Utilities that try to exercise ("fuzz") an interface with the intent of discovering bugs are called "fuzzers". The tool that comes to mind is syzkaller.
-
Those scary warnings of juice jacking in airports and hotels? They’re nonsense
It's true that USB is probably a less desirable attack surface than modems, because it actually requires the user to physically connect their device to a malicious device, but I wouldn't discount it as impractical and unlikely to happen in the wild. There's a reason some of the more famous malware and spyware used to spread/attack over USB. Google actually does USB driver fuzzing and the amount of potentially devastating vulnerabilities is staggering.
- Linux System Call Table – Chromiumos
- Audit of Linux kernel code
CompCert
-
Differ: Tool for testing and validating transformed programs
A big problem is that proving that transformations preserve semantics is very hard. Formal methods has huge potential and I believe it will be a big part of the future, but it hasn't become mainstream yet. Probably a big reason why is that right now it's simply not practical: the things you can prove are much more limited than the things you can do, and it's a lot less work to just create a large testsuite.
Example: CompCert (https://compcert.org/), a formally-verified compiler AKA formally-verified sequence of semantics-preserving transformations from C code to Assembly. It's a great accomplishment, but few people are actually compiling their code with CompCert. Because GCC and LLVM are much faster[1], and have been used so widely that >99.9% of code is going to be compiled correctly, especially code which isn't doing anything extremely weird.
But as articles like this show, no matter how large a testsuite there may always be bugs, tests will never provide the kind of guarantees formal verification does.
[1] From CompCert, "Performance of the generated code is decent but not outstanding: on PowerPC, about 90% of the performance of GCC version 4 at optimization level 1"
- So you think you know C?
-
Can the language of proof assistants be used for general purpose programming?
Also a C compiler (https://compcert.org/). I did exaggerate bit in saying that anything non-trivial is "nearly impossible".
However, both CompCert and sel4 took a few years to develop, whereas it would only take months if not weeks to make versions of both which aren't formally verified but heavily tested.
-
A Guide to Undefined Behavior in C and C++
From my experience, while many MCUs have settled for the big compilers (GCC and Clang), DSPs and some FPGAs (not Intel and Xilinx, those have lately settled for Clang and a combination of Clang and GCC respectively) use some pretty bespoke compilers (just running ./ --version is enough to verify this, if the compiler even offers that option). That's not necessarily bad, since many of them offer some really useful features, but error messages can be really cryptic in some cases. Also some industries require use of verified compilers, like CompCert[1], and in such cases GCC and Clang just don't cut it.
[1]: https://compcert.org/
-
Recently I am having too much friction with the borrow checker... Would you recommend I rewrite the compiler in another language, or keep trying to implement it in rust?
CompCert sends its regards
- Rosenpass – formally verified post-quantum WireGuard
-
OpenAI might be training its AI technology to replace some software engineers, report says
But that's fine, because we can do even better with things like the CompCert C compiler, which is formally proven to produce correct asm output for ISO C 2011 source. It's designed for high-reliability, safety-critical applications; it's used for things like Airbus A380 avionics software, or control software for emergency generators at nuclear power plants. Software that's probably not overly sophisticated and doesn't need to be highly optimized, but does need to work ~100% correctly, ~100% of the time.
-
There is such thing called bugfree code.
For context, CompCert is a formally verified compiler. My former advisor helped with a fuzzer called CSmith which found plenty of bugs in GCC and LLVM but not in CompCert.
-
Checked C
Does anybody know how does this compare to https://compcert.org/ ?
-
Proofs about Programs
This is a common property for proof-oriented languages. Coq shares this property for instance, and you can write an optimizing C compiler in Coq: https://github.com/AbsInt/CompCert .
What are some alternatives?
AFLplusplus - The fuzzer afl++ is afl with community patches, qemu 5.1 upgrade, collision-free coverage, enhanced laf-intel & redqueen, AFLfast++ power schedules, MOpt mutators, unicorn_mode, and a lot more!
seL4 - The seL4 microkernel
vuls - Agent-less vulnerability scanner for Linux, FreeBSD, Container, WordPress, Programming language libraries, Network devices
coq - Coq is a formal proof management system. It provides a formal language to write mathematical definitions, executable algorithms and theorems together with an environment for semi-interactive development of machine-checked proofs.
wtf - wtf is a distributed, code-coverage guided, customizable, cross-platform snapshot-based fuzzer designed for attacking user and / or kernel-mode targets running on Microsoft Windows and Linux user-mode (experimental!).
unbound - Replib: generic programming & Unbound: generic treatment of binders
ipa-medit - Memory modification tool for re-signed ipa supports iOS apps running on iPhone and Apple Silicon Mac without jailbreaking.
gcc
gvisor - Application Kernel for Containers
corn - Coq Repository at Nijmegen [maintainers=@spitters,@VincentSe]
xpid - Linux Process Discovery. C Library, Go bindings, Runtime.
koika - A core language for rule-based hardware design 🦑