|
Dmitry Vyukov
@
dvyukov
Munich, Germany
|
|
I tweet about fuzzing, bugs, sanitizers, security, hardening, kernels, Go, performance, concurrency, lock-free algorithms.
|
|
|
2.292
Tweetovi
|
118
Pratim
|
5.702
Osobe koje vas prate
|
| Tweetovi |
| Dmitry Vyukov proslijedio/la je tweet | ||
|
Simon Weckert
@simon_deliver
|
1. velj |
|
99 smartphones are transported in a handcart to generate virtual traffic jam in Google Maps. Through this activity, it is possible to turn a green street red which has an impact in the physical world by navigating cars on another route! #googlemapshacks simonweckert.com/googlemapshack… pic.twitter.com/6KcMm1XgAF
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
31. sij |
|
Pre-declaring static helpers is probably the least evil. But still unnecessary boilerplate and duplication (need to change 2 places).
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
31. sij |
|
R u sure u r objective here? and not suffering Stockholm syndrome? :)
Orphan counts that need to be per-cpu is not how you start explaining TCP
elixir.bootlin.com/linux/latest/s…
You dont start explaining signals with the fact that you need isolated slab for sigqueue
elixir.bootlin.com/linux/v5.5/sou…
|
||
|
|
||
| Dmitry Vyukov proslijedio/la je tweet | ||
|
Kernel Recipes #kr2020
@KernelRecipes
|
31. sij |
|
We are working hard on the next edition #kr2020. You can sponsor it and be part of our supporters. Have a look on the flyer!
kernel-recipes.org/en/2019/2020-s…
|
||
|
|
||
| Dmitry Vyukov proslijedio/la je tweet | ||
|
grsecurity
@grsecurity
|
31. sij |
|
In the rare event where a manual fix wasn't already covered by Respectre, all such cases are investigated and the plugin's static analysis is improved to provide the necessary coverage
|
||
|
|
||
| Dmitry Vyukov proslijedio/la je tweet | ||
|
grsecurity
@grsecurity
|
31. sij |
|
We expect to be already covered for most if not all of these Spectre v1/L1TF issues: lore.kernel.org/lkml/158040844… Part of the work we do involves comparing manual upstream fixes to our verbose Respectre instrumentation logs.
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
31. sij |
|
I want strange: C/C++ editor to revert func order on load&revert back on save so that I dont start with least important noise, scroll down and then read backwards
You cant unsee how unnatural doing everything backwards once worked in lang with no "lets save 1 parsing pass" legacy
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
28. sij |
|
Though, the code base is clean of compiler warnings and _some_ static analysis warnings. Which makes sense.
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
28. sij |
|
Interesting note re static analysis (SA):
"SA hasn't been helpful in finding bugs in SQLite. SA has found a few bugs in SQLite, but those are the exceptions. More bugs have been introduced into SQLite while trying to get it to compile without warnings than have been found by SA"
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
28. sij |
|
Measuring and knowing your test coverage
+1
Lots of dynamic analysis
+1
(though I am surprised to see Valgrind but not ASAN)
Release checklists and tracking
+1
(no "our release is all broken, but we did not even know")
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
28. sij |
|
Their fault injection approach is similar to systematic fault injection we use in syzkaller for #linux kernel:
lore.kernel.org/patchwork/patc…
That's the way for testing error paths.
Lots of different fuzzers
+1
Just one is never enough. Also continuous fuzzing on OSS-Fuzz.
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
28. sij |
|
4.1.4.third-party fuzzers
4.2.Malformed DB Files
4.3.Boundary Value Tests
5.Regression Testing
6.Automatic Resource Leak Detection
7.Test Coverage
7.6.Mutation testing
8.Dynamic Analysis
8.2.Valgrind
8.4.Mutex Asserts
8.6.Undefined Behavior Checks
10.Checklists
11.Static Analysis
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
28. sij |
|
Just some excerpts:
2. Test Harnesses
3. Anomaly Testing
3.1. Out-Of-Memory
3.3. Crash Testing
4. Fuzz Testing
4.1. SQL Fuzz
4.1.1. AFL
4.1.2. OSS Fuzz
4.1.4. third-party fuzzers
...
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
28. sij |
|
I am impressed by #SQLite testing approach, breadth, methodology and investment:
sqlite.org/testing.html
It's very important that there are OSS projects that set such examples.
There is always something to improve, but I think nobody will object that that's good level of testing
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
28. sij |
|
Good Q. It needs explicit annotations for code regions in kernel threads with some ID that matches ID armed in the test process KCOV.
Eg USB code says "here I process request for USB bus 42", test process - "I am working with USB bus 42, gimme that coverage".
|
||
|
|
||
| Dmitry Vyukov proslijedio/la je tweet | ||
|
I Am Devloper
@iamdevloper
|
27. sij |
|
Every developer: we need to implement an email alert system to notify us if production crashes
Every developer after the first crash: how do we turn off these email alerts?
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
27. sij |
|
Throw in with 692 more repros for #linux kernel bugs:
github.com/dvyukov/syzkal…
Russian Roulette variation: you pick one of these, compile and run on your physical desktop/laptop; if it does not panic, your opponent picks one, and so on.
(say, an out-of-bounds read may not crash) twitter.com/dvyukov/status…
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
27. sij |
|
This KCOV extension by Andrey allows syzkaller to collect coverage from background kernel threads e.g. parsing incoming USB packets and unambiguously associate it with one of multiple parallel test processes running. To some degree unique for fuzzing coverage. Moar bugs coming! twitter.com/andreyknvl/sta…
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
27. sij |
|
And since we seem to be stable at N K bugs, throwing in 2x fixes/changes per unit of time does not really get us anywhere (fix one, introduce another).
The real change can come from killing classes of bugs as part of the process and scaling this to _every_ developer.
|
||
|
|
||
|
Dmitry Vyukov
@dvyukov
|
27. sij |
|
@davem_dokebi @grsecurity
Frankly, the situation reminds me a lot of "it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
Any single fix by a single person has very minimal impact...
|
||
|
|
||