Dmitry Vyukov

@dvyukov

I tweet about fuzzing, bugs, sanitizers, security, hardening, kernels, Go, performance, concurrency, lock-free algorithms.

Joined April 2009

Tweets

You blocked @dvyukov

Are you sure you want to view these Tweets? Viewing Tweets won't unblock @dvyukov

  1. Retweeted
    Feb 1

    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!

    Show this thread
    Undo
  2. Retweeted

    We are working hard on the next edition . You can sponsor it and be part of our supporters. Have a look on the flyer!

    Undo
  3. Retweeted
    Jan 31

    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

    Show this thread
    Undo
  4. Retweeted
    Jan 31

    We expect to be already covered for most if not all of these Spectre v1/L1TF issues: Part of the work we do involves comparing manual upstream fixes to our verbose Respectre instrumentation logs.

    Show this thread
    Undo
  5. Jan 31

    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

    Undo
  6. Jan 28

    Though, the code base is clean of compiler warnings and _some_ static analysis warnings. Which makes sense.

    Show this thread
    Undo
  7. Jan 28

    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"

    Show this thread
    Undo
  8. Jan 28

    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")

    Show this thread
    Undo
  9. Jan 28

    Their fault injection approach is similar to systematic fault injection we use in syzkaller for kernel: That's the way for testing error paths. Lots of different fuzzers +1 Just one is never enough. Also continuous fuzzing on OSS-Fuzz.

    Show this thread
    Undo
  10. Jan 28

    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

    Show this thread
    Undo
  11. Jan 28

    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 ...

    Show this thread
    Undo
  12. Jan 28

    I am impressed by testing approach, breadth, methodology and investment: 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

    Show this thread
    Undo
  13. Retweeted
    Jan 27

    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?

    Undo
  14. Jan 27

    Throw in with 692 more repros for kernel bugs: 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)

    Undo
  15. Jan 27

    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!

    Undo
  16. Jan 27

    Absence of context (no expand btn) in changes only exacerbates the problem. If you look at actual proposed change No mention of rcu, so why would reviewer even start thinking about the potential problem? There are known solutions to this problem as well...

    Show this thread
    Undo
  17. Jan 27

    That is no way to make it part of process and scale it. That would not just immediately prevent the bug, but prevent the whole class of bugs in all 20 MLOC with guarantees, cheaply and scalably. But that can't be bolted onto the project on the side, by few volunteers...

    Show this thread
    Undo
  18. Jan 27

    Coverity detects these, Clang ThreadSafetyAnalysis too. But tools are smaller part of solution. Integration into process is more important. But again kernel doesn't have real notion of changes, no infra to run analysis, no way to make anybody use it, no way to block submit, etc..

    Show this thread
    Undo
  19. Jan 27

    What I'm thinking reading this sad story of crit remote vuln introduced into all LTS kernels and still unfixed (now in your kernel)- this "forgot to release lock" is mostly solved problem today with static analysis. Kernel absolutely needs it as part of the dev process 1/n

    Show this thread
    Undo
  20. Retweeted
    Jan 16
    Undo

Loading seems to be taking a while.

Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.

    You may also like

    ·