Why doesn't the vDSO code just use MOV in its stack probe probe rather than an OR?
Because gcc's -fstack-check is garbage. Gentoo Hardened should not be using it.
Debugging an evil Go runtime bug
11–20 of 51 posts
Re: Debugging an evil Go runtime bug
#12That is such as well written post, and showcases some serious diagnostic skills by an experienced person.
Btw, thanks about telling me about the badram Grub 2 feature, had no idea that exited.
Re: Debugging an evil Go runtime bug
#13Man I loved the approach to narrow down the offending object file using the regex on the SHA hash of the binaries. That would've saved me lots of time hunting and guessing bugs with cscope+kdb back in my kernel hacker days!
Re: Debugging an evil Go runtime bug
#14Earlier quoted context omitted.
Apparently, because it's shorter [0]. [0]: See https://lkml.org/lkml/2017/11/10/348
Why is it shorter? Both MOV and OR have one byte encodings, and with the OR you either have to use an immediate zero (which burns a byte) or materialize zero in some other way. As that email points out, the entire sequence would be shorter using a different addressing mode anyways. And a read-modify-write is definitely slower at runtime.
I wonder if it's because it's safer in that it doesn't change anything there if you've gone over the stack limit and into the heap? I know that -fstack-protect was designed a long time ago, possible before guard pages and before 64bit addressing.
Re: Debugging an evil Go runtime bug
#15Thanks for taking the time to do this writeup! Super fun to read and informative.
Re: Debugging an evil Go runtime bug
#16>Since the problem gets worse with temperature, what happens if I heat up the RAM?
Neat. I wonder if that makes Rowhammer more likely to occur.
Re: Debugging an evil Go runtime bug
#17Marcan's attitude is great; I know of a ton of people (myself included) who would've written that article with far more complaining interleaved. Super informative as well, I learned a ton from this article (GRUB 2 feature for marking off bad RAM? Wow!). Very well written, informative, humorous, etc. Love it
Agreed. Marcan's a chill dude. I saw him a few times in the Dolphin Emulator IRC and he always had interesting things to say.
From my perspective this approach was pretty unique; going all the way down to debugging the hardware first may seem obvious to some, but it's a totally opposite approach to how I'd go about it. My mind would jump directly to producing a minimal test case. Would've never thought to mark off bad RAM with an obscure(ish?) GRUB 2 feature. Would've never thought to selectively flip a kernel flag for some parts of the code.
It's great to get these perspectives from people who really know how to dig down and debug deep.
Re: Debugging an evil Go runtime bug
#18Such a thorough and well written write up.
To think that some experienced programmers I know declare that concurrency is easy.
Re: Debugging an evil Go runtime bug
#19Setting up for a 104 byte stack seems pretty crazy, wouldn't you risk overrunning the red zone even without all that stack probing? https://en.wikipedia.org/wiki/Red_zone_(computing)
Re: Debugging an evil Go runtime bug
#20>Since the problem gets worse with temperature, what happens if I heat up the RAM? Neat. I wonder if that makes Rowhammer more likely to occur.
[deleted]