Sushi Roll: A CPU research kernel with minimal noise for microarch introspection | Hacker News Reader

Sushi Roll: A CPU research kernel with minimal noise for microarch introspection

gamozolabs.github.io

74 pointsmatt_d13 comments

Interesting comment from the author over on reddit[1] discussing using the research kernel to "find 0-day in software and hardware for about 2 years".

[1] https://old.reddit.com/r/programming/comments/csfj53/sushi_r...

https://xenproject.org/2012/06/13/the-intel-sysret-privilege...

I can only speculate as to the types of vulnerabilities not disclosed.

This kernel is just kind of a playground for projects I have. Specifically there were a few from this past year or so.

I used this kernel originally for my vectorized emulator, which is designed as a high-performance fuzzer/harness to find bugs (more info https://gamozolabs.github.io/fuzzing/2018/10/14/vectorized_e...). I used vectorized emulation on Windows DHCP to find multiple RCEs (which were disclosed earlier this year), as well as one of the Intel MDS vulnerabilities (such as RIDL and Fallout) disclosed earlier this year (specifically I found "MLPDS", https://nvd.nist.gov/vuln/detail/CVE-2018-12127).

I do most of my work in a personal kernel as it really gives me an edge with optimization. I'm able to use page tables directly (super fast fork()-like behavior), and write hypervisors that don't have to go through crazy call stacks to vmexit, use bleeding-edge CPU features, etc. Ultimately I just do it because it's fun, but I've found ways to justify it from time to time.

Is it a pure hobby project on the side, or do you work for a company / research lab ? That is really interesting btw.

I currently work at Microsoft, however my work and my hobby are pretty much the same at this point so I put a lot of time into it!

Thanks for posting this. This is a fascinating project and I hope you post more about it. I had a question about something under the Microcode section which stated:

>"These are often complex operations, like switching operating modes, reading/writing internal CPU registers, etc."

Is a switch from ring 3 to ring 0 handled by microcode then? If so why is this?

The exact URL/title was posted one hour earlier. https://news.ycombinator.com/item?id=20743260

No, matt_d's was earlier. The IDs tell all: 20736713 < 20743260.

The reason this was confusing is that we put the earlier post in the second-chance queue (described at https://news.ycombinator.com/item?id=11662380), which temporarily modifies the timestamps on re-up as explained here: https://news.ycombinator.com/item?id=19774614. This confusion comes up periodically but I don't know a globally better solution than how we currently do it.

Would marking second chance submissions as such help?

Maybe, but how would we do that in a minimal way that would still be self-explanatory?

The alt-text/hover text of the timestamp would be the perfect place for it. That way it wouldn't bias anyone who doesn't go looking for it explicitly.

But then the vast majority of users will never know about it, which is not self-explanatory.

Also, out of curiosity, how does that work on mobile? I know it's a naive question but I've never figured that out.

If you stick a title attribute on an image, it will show up when you long press on it in Mobile Safari. This doesn't work with links, though, because it'll show the destination instead. Might I suggest just putting the submission time in parentheses, like "1 day ago (resubmitted 3 hours ago)"?

Reply on news.ycombinator.com