3 ms·
Isn't there something important missing here? My understanding is that Go's non-standard ABI doesn't guarantee much available stack space or the existence of gu
by scottlamb 4y ago
Isn't there something important missing here? My understanding is that Go's non-standard ABI doesn't guarantee much available stack space or the existence of guard pages. IIUC, this places a standard-ABI-like stack frame on the Go stack for calling into Rust, but what guarantee is there that the Rust/libc code won't overflow the small stack? What happens if it does? AFAICT, the answer are "none" and "memory corruption".
- aviramha 4y agoWe actually address it in the post - https://metalbear.co/blog/hooking-go-from-rust-hitchhikers-guide-to-the-go-laxy/#why-did-this-goroutine-panic-with-our-hook https://metalbear.co/blog/hooking-go-from-rust-hitchhikers-g... > "Goroutine stack is dynamic, i.e. it is constantly expanding/shrinking depending on the current needs. This means any common code that runs in system stack assumes it can grow as it wishes (until it exceeds max stack size) while actually, it can’t unless using Go APIs for expanding. Our Rust code isn’t aware of it, so it uses parts of the stack that aren’t actually usable and causes stack overflow." tl;dr - yes, you're correct and we replace Go stack with system stack for the duration of the call, just like cgo does.
- scottlamb 4y agoThanks, I somehow missed that whole section!