5 ms·
An example that needs to be in the textbooks. A detailed explanation and a timeline along with the code snippets. It succinctly shows you the complexities invol
by sublimefire 5y ago
An example that needs to be in the textbooks. A detailed explanation and a timeline along with the code snippets. It succinctly shows you the complexities involved. Kudos to Max for putting it all into the post.
> Blaming the Linux kernel (i.e. somebody else’s code) for data corruption must be the last resort.
^^^ I can only image the stress levels at this point.
- xcambar 5y agoThe magic for me was the two little C programs that demonstrated the bug. Circa 10 lines of C. Beautiful.
- rmetzler 5y agoYes, being able to replicate the issue in a small piece of code is a very good thing. First it helps to triage whether the bug is in your own code or in other code. You also then can use it like the author and find the commit which introduced the bug. And you can use it as a test case to verify if the bug is closed.
- moltke 5y agoI've personally found bugs in unpopular kernel APIs. I spent days thinking it was my code until I went and read the Linux implementation.
- girvo 5y agoESP-IDF has so many bugs that it’s often the first thing to blame when we hit issues, even if it is our code after all haha
- misnome 5y agoYes, this is an extremely well written and to the point writeup.
- deutschew 5y agousually I dont read too deeply into CVE because they are too complex but this article made me go holy sh- wish more would be written like this
- healsjnr1 5y agoThis reminds if some time direct working on crypto toolkits. Every few months, someone would always come up with a reason why "bad entropy" was the cause of a bug. It never was, but it felt like a thing we had to go through, to get to the real cause.