On Thu, Aug 13, 2015 at 5:08 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev <s...@list.ru> wrote: >> 14.08.2015 02:00, Andy Lutomirski пишет: >>> >>> DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's >>> threading library starts using WRFSBASE instead of arch_prctl. >> >> Hmm, how about the following: >> >> prctl(ARCH_SET_SIGNAL_FS, my_tls) >> If my_tls==NULL - use current fsbase (including one of WRFSBASE). >> If my_tls==(void)-1 - don't restore. >> >> Can this work? > > I'm really inclined to wonder whether we need the change and such a flag at > all. > > Basically, no _normal_ application will ever play with segments at all > on x86-64. So our current behavior of not touching any segments at all > for signal handling would seem to be the right thing to do - because > it handles all the sane cases optimally. > > And applications that *do* play with segments very much know they do > so, and we already put the onus on *them* to save/restore segments. > That's how dosemu clearly works today.
I agree for all but CS and SS, which are special. CS is fine already. The way that DOSEMU works around SS it is hideous: it just gives up on sigreturn working and fixes the segments with IRET. (Also, if DOSEMU ever wants to get ESP[31:16] right, it *can't*: only the kernel can usefully do espfix64, and DOSEMU can't get the kernel to return from 64-bit code to 16-bit code, because we zap SS. DOSEMU fudges it by forcibly zeroing ESP[31:16]), but that's not a full solution and I wouldn't be surprised if something breaks as a result. So yes, it mostly works. It also sucks, and it makes it extremely unpleasant for any other program to do this. I'd argue that keeping things like the sigreturn_64 test working is quite valuable, because it's a royal PITA to exercise this code cleanly without proper control of SS. Unfortunately, making it hard for sigreturn_64 to exercise this stuff doesn't mean that the bad guys can't do it, because they'll use malformed ELF files, or ptrace, or stupid modify_ldt races (except I hopefully fixed those), or x32, or compat, or some other hack I haven't thought of yet, and they'll hit the same bugs. I've lost count of the number of bugs of various severities that the sigreturn tests have shaken out *and* caught in patches that were emailed in. We could say "forget sigreturn_64, use sigreturn_32 instead", but that can't exercise !IA32_EMULATION kernels, and that code is a bit different. (BadIRET, for example, is nominally unreachable from 64-bit code without modify_ldt and the sigreturn fix, except that I think know of one really nasty way to do it. I have no intention of implementing that, so keeping selftests working nicely makes me *much* more confident.) Obviously, if we reintroduce SS restoration, we need to do it much more carefully. My RFC patches are an attempt to do that, but it needs a lot of care to make sure all the bases are covered. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/