Interesting, a mysterious bug report I've been struggling to track down just got solved. It turns out, 32-bit getcontext() can return failure if run inside a docker container. Apparently the cause is the default docker seccomp policy doesn't allow sigprocmask() (wtf?). 
-
-
Replying to @taviso
Does it abort or silently fail? The latter is CVE-worthy.
2 replies 0 retweets 7 likes -
Replying to @RichFelker
Silently fail. The docs say no errors defined, and my mental model was just a wrapper around pushad, etc, etc. I didn't expect it to go wrong, so tracking down the bug was a nightmare
5 replies 0 retweets 15 likes -
Replying to @taviso @RichFelker
Have you traced the syscall to see if it is failing or if libc is discarding the error? The default profile *should* return EPERM for anything blocked. rt_sigprocmask is allowed but it looks like sigprocmask is still defined on 32bit and not...
1 reply 0 retweets 2 likes -
Replying to @crosbymichael @taviso
sigprocmask is an operation where there's likely to be no possibility of forward progress if it fails (assuming valid usage), so it doesn't make sense for libc or anything else to be checking for error. However..
1 reply 0 retweets 0 likes -
If it's the old non-"rt_" sigprocmask syscall that's failing, this whole thing is likely a non-issue on Docker's side, because that's from the libc5 days and not usable (not compatible with modern sigset_t ABI). It's a glibc bug if glibc is ever making that syscall.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @crosbymichael
It's the old sigprocmask, but I disagree it's okay to break getcontext(). I guess I need to detect docker and use my own implementation, even if glibc get's updated nobody is going to have the patch for years
https://github.com/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/i386/getcontext.S#L70 …2 replies 0 retweets 4 likes -
Replying to @taviso @crosbymichael
OK, fair enough. But if glibc's getcontext() is wrongly calling the old sigprocmask syscall, it can't be working right to begin with.
1 reply 0 retweets 1 like -
I just checked the source and indeed it is. This means it's leaving uninitialized junk in the upper 32 bits of the sigset_t, and this junk is possibly getting restored over the caller's signal mask later. Need to open a glibc bug for it.
2 replies 0 retweets 5 likes
I feel dirty just considering this, but it seems like it does all the work before the syscall.... so I can just ignore the return code and manage my own signal mask if I detect docker? 
-
-
Replying to @taviso @RichFelker
What about a patch to docker to enable sigprocmask on 32bit? Alt, if this is your own code, you can also provide a custom seccomp profile for your container.
1 reply 0 retweets 0 likes -
Replying to @crosbymichael @RichFelker
I'm not a docker user, other people were reporting my code wasn't working and I couldn't reproduce...turns our they were using docker. If you think a patch to enable on x86 would be accepted, I'll try that.
3 replies 0 retweets 0 likes - 1 more reply
New conversation -
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.