5 ms·

Couple of things. First, I don't think that's true nowadays. The discussion points that this (not restoring DF on signal return) is a kernel bug and should be

by majke 10y ago

Couple of things. First, I don't think that's true nowadays. The discussion points that this (not restoring DF on signal return) is a kernel bug and should be fixed: https://lkml.org/lkml/2008/3/5/531 https://lkml.org/lkml/2008/3/5/531 Second, the kernel tries to avoid doing too much work in the signal return code. It tries hard do _avoid_ heavy XSAVE and just preserve only the needed registers. This is the job of sigreturn(2) syscall btw. http://man7.org/linux/man-pages/man2/sigreturn.2.html http://man7.org/linux/man-pages/man2/sigreturn.2.html Third, there was a similar discussion about restoring SS (segment stack) register in x86-64 signal code. First patch proposed by Bryan Ford: https://lkml.org/lkml/2005/10/5/176 https://lkml.org/lkml/2005/10/5/176 . Then 10 years later by Andy Lutomirski: https://lkml.org/lkml/2014/7/11/564 https://lkml.org/lkml/2014/7/11/564 Last one was merged into mainline. Then reversed. Sadly. Then applied again: https://github.com/torvalds/linux/commit/6c25da5ad55d48c41b8909bc1f4e3cd5d85bb499 https://github.com/torvalds/linux/commit/6c25da5ad55d48c41b8... The gist: if you modify SS register in the signal handler you are screwed. The only way around it is to install a trampoline using "the famous dosemu iret hack" described here: http://www.x86-64.org/pipermail/discuss/2007-May/009913.html http://www.x86-64.org/pipermail/discuss/2007-May/009913.html (the site is down, can anyone find a mirror?) On Linux use signalfd(2) whenever you can http://man7.org/linux/man-pages/man2/signalfd.2.html http://man7.org/linux/man-pages/man2/signalfd.2.html (Ie: put signal handling back in event loop). That's the only sane way of dealing with signals.

hawkice 10y ago
I mean, kernel bug or no, if that's how it actually works, then it isn't actually safe to be handle signals while executing these functions. If people are still working to change the code and standards we hold the code to, then you can't push changes that rely on the new behavior without introducing some truly bizarre race conditions.
- majke 10y ago
  This comment suggests that #DF is rarely used anyway https://lkml.org/lkml/2008/3/6/50 https://lkml.org/lkml/2008/3/6/50 > The conclusion is that DF=1 in x86_64 64-bit code is extremely rare
- tedunangst 10y ago
  The bug is 8 years old. At some point you can assume it's been fixed.
  - hawkice 10y ago
    I mean, that's pretty optimistic, but perhaps: At some point you can assume that, if people get your updated code in 2017, they'll have an update from many years ago. Depends on how releases are managed, but that might be much much more practical an assumption.
caf 10y ago
The bug wasn't "not restoring DF on signal return" - it was always saved and restored correctly. The bug was not clearing DF on signal entry.
- majke 10y ago
  agreed
amluto 10y ago
> Last one was merged into mainline. Then reversed. Sadly. > Then applied again: https://github.com/torvalds/linux/commit/6c25da5ad55d48c41b8.. https://github.com/torvalds/linux/commit/6c25da5ad55d48c41b8.... > > The gist: if you modify SS register in the signal handler you are screwed. The only way around it is to install a trampoline using "the famous dosemu iret hack" described here: I'm not sure what you mean. This issue is fixed, so SS works exactly the way you would expect it to, unless you do very strange things indeed in which case you might need to fiddle with uc_flags.
- majke 10y ago
  Strange or not, linux did not restore SS on sigreturn in 64 bit mode. The point of explaining that is to emphasize that the issue described in the blog post is not the only one in this code (the code doing entering / exiting signal handlers). The issue is fixed indeed, as for Feb 17, 2016.
  - amluto 10y ago
    Okay, I read your post as meaning that it was still broken. FWIW, I don't consider it sad that my first attempt was reverted. I inadvertently broke some assumptions that a real program (DOSEMU) was making, and Linux takes backwards compatibility quite seriously. The second version was better.
eridius 10y ago
The site is down again? What's wrong with that site? A while back when I wanted to look something up in the x86_64 ABI the site was down too, for at least a week (I eventually gave up checking). At some point later it came back. I wonder how long it's been down this time. Interestingly, Xcode's OS X docs used to link to x86-64.org for the AMD64 ABI, but looking right now, the link is removed (but the text remains), I guess because the site was down for so long.

by majke 10y ago

hawkice 10y ago

I mean, kernel bug or no, if that's how it actually works, then it isn't actually safe to be handle signals while executing these functions. If people are still working to change the code and standards we hold the code to, then you can't push changes that rely on the new behavior without introducing some truly bizarre race conditions.

majke 10y ago
This comment suggests that #DF is rarely used anyway https://lkml.org/lkml/2008/3/6/50 https://lkml.org/lkml/2008/3/6/50 > The conclusion is that DF=1 in x86_64 64-bit code is extremely rare
tedunangst 10y ago
The bug is 8 years old. At some point you can assume it's been fixed.
- hawkice 10y ago
  I mean, that's pretty optimistic, but perhaps: At some point you can assume that, if people get your updated code in 2017, they'll have an update from many years ago. Depends on how releases are managed, but that might be much much more practical an assumption.

caf 10y ago

The bug wasn't "not restoring DF on signal return" - it was always saved and restored correctly. The bug was not clearing DF on signal entry.

majke 10y ago
agreed

amluto 10y ago

> Last one was merged into mainline. Then reversed. Sadly. > Then applied again: https://github.com/torvalds/linux/commit/6c25da5ad55d48c41b8.. https://github.com/torvalds/linux/commit/6c25da5ad55d48c41b8.... > > The gist: if you modify SS register in the signal handler you are screwed. The only way around it is to install a trampoline using "the famous dosemu iret hack" described here: I'm not sure what you mean. This issue is fixed, so SS works exactly the way you would expect it to, unless you do very strange things indeed in which case you might need to fiddle with uc_flags.

majke 10y ago
Strange or not, linux did not restore SS on sigreturn in 64 bit mode. The point of explaining that is to emphasize that the issue described in the blog post is not the only one in this code (the code doing entering / exiting signal handlers). The issue is fixed indeed, as for Feb 17, 2016.
- amluto 10y ago
  Okay, I read your post as meaning that it was still broken. FWIW, I don't consider it sad that my first attempt was reverted. I inadvertently broke some assumptions that a real program (DOSEMU) was making, and Linux takes backwards compatibility quite seriously. The second version was better.

eridius 10y ago

The site is down again? What's wrong with that site? A while back when I wanted to look something up in the x86_64 ABI the site was down too, for at least a week (I eventually gave up checking). At some point later it came back. I wonder how long it's been down this time. Interestingly, Xcode's OS X docs used to link to x86-64.org for the AMD64 ABI, but looking right now, the link is removed (but the text remains), I guess because the site was down for so long.