On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev <s...@list.ru> wrote: > 14.08.2015 01:29, Andy Lutomirski пишет: >> >> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <s...@list.ru> wrote: >>> >>> 14.08.2015 01:11, Andy Lutomirski пишет: >>> >>>> Now suppose you set some magic flag and jump (via sigreturn, >>>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS >>>> and then gets #GP. You land in a signal handler. As far as the >>>> kernel's concerned, the FS base register is whatever the base of LDT >>>> entry 0 is. What else is the kernel supposed to shove in there? >>> >>> The same as what happens when you do in userspace: >>> --- >>> asm ("mov $0,%%fs\n"); >>> prctl(ARCH_SET_FS, my_tls_base); >>> --- >>> >>> This was the trick I did before gcc started to use FS in prolog, >>> now I have to do this in asm. >>> But how simpler for the kernel is to do the same? >>> >>>> I think that making this work fully in the kernel would require a >>>> full-blown FS equivalent of sigaltstack, and that seems like overkill. >>> >>> Setting selector and base is what you call an "equivalent of >>> sigaltstack"? >> >> Yes. sigaltstack says "hey, kernel! here's my SP for signal >> handling." I think we'd need something similar to tell the kernel >> what my_tls_base is. Using the most recent thing passed to >> ARCH_SET_FS is no good because WRFSBASE systems might not use >> ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon >> as we enable WRFSBASE. > > If someone uses WRFSBASE and wants things to be preserved > in a sighandler, he'll just not set the aforementioned flag. No regression. > Whoever wants to use that flag properly, will not use WRFSBASE, > and will use ARCH_SET_FS or set_thread_area(). > What exactly breakage do you have in mind?
DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's threading library starts using WRFSBASE instead of arch_prctl. --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/