Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1247207
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context |
| Date | 2015-10-14 23:40 +0200 |
| Message-ID | <qjBWa-2yn-17@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <qjxpv-4ki-5@gated-at.bofh.it> <qjylB-5Hm-27@gated-at.bofh.it> <qjyEV-6jb-3@gated-at.bofh.it> <qjz7Y-6RL-19@gated-at.bofh.it> <qjzrj-7fk-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
14.10.2015 21:52, Andy Lutomirski пишет: > On Wed, Oct 14, 2015 at 11:34 AM, Stas Sergeev <stsp@list.ru> wrote: >> 14.10.2015 21:06, Andy Lutomirski пишет: >>>> Also it doesn't seem to be saying what happens if CS is 32-bit >>>> and SS is invalid (the flag is not set). >>> A new signal will be delivered. sigreturn doesn't modify its behavior >>> in this case -- it does the default thing, which is to honor the SS in >>> the saved context. >> Hmm, no, it didn't do this in the past for sure. >> It simply ignored SS, no matter to what mode it returns. >> > What I mean is: it has the behavior it would have normally on a new > kernel, which is to honor the saved SS. I'll try to improve the > comment. > >>> So it will actually try to use that saved SS >>> value, which will fail, causing SIGSEGV. >> So it seems this logic assumes that when dosemu returns to 32bit, >> the previous SS is always still valid, am I right with the understanding? >> I.e. the one that kernel have saved on a signal delivery (because >> old dosemu does not overwrite it). >> If it is so, I'd say this assumption is very risky and will likely >> not hold. But maybe I am missing the point. >> > That's the assumption. If I understand correctly, though, old DOSEMU > never actually returns to 32-bit using sigreturn in the first place, > since old kernels gave no control over SS. Doesn't old DOSEMU always > return to the 64-bit IRET trampoline? Ah, so the old progs simply never return to 32bit, so you implement the "Right Thing" (tm) for them, thanks. So the whole point of UC_STRICT_RESTORE_SS flag is not for the software to control it, but just for the kernel itself, so that it knows from whether 32 or 64 bit the signal came. This is probably quite undocumented in both the comments and the patch description, and I was confused because the approaches we discussed before, were targeted on the flag that is written by user-space. If this my understanding is correct and the flag is just an indication rather than a requested action, perhaps the name should be different, e.g. UC_SIG_FROM_32BIT or the like? Anyway, this is minor. :) I'll try to test the patch within a few days, thanks for you time! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC 0/4] x86: sigcontext SS fixes, take 2 Andy Lutomirski <luto@kernel.org> - 2015-10-13 03:10 +0200
[RFC 4/4] selftests/x86: Add tests for UC_SIGCONTEXT_SS and UC_STRICT_RESTORE_SS Andy Lutomirski <luto@kernel.org> - 2015-10-13 03:10 +0200
[RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Andy Lutomirski <luto@kernel.org> - 2015-10-13 03:10 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Stas Sergeev <stsp@list.ru> - 2015-10-13 18:10 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Ingo Molnar <mingo@kernel.org> - 2015-10-14 17:10 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Stas Sergeev <stsp@list.ru> - 2015-10-14 17:20 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Andy Lutomirski <luto@amacapital.net> - 2015-10-14 18:50 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Stas Sergeev <stsp@list.ru> - 2015-10-14 19:50 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Andy Lutomirski <luto@amacapital.net> - 2015-10-14 20:10 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Stas Sergeev <stsp@list.ru> - 2015-10-14 20:40 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Andy Lutomirski <luto@amacapital.net> - 2015-10-14 21:00 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Stas Sergeev <stsp@list.ru> - 2015-10-14 23:40 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Andy Lutomirski <luto@amacapital.net> - 2015-10-14 23:50 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Cyrill Gorcunov <gorcunov@gmail.com> - 2015-10-14 18:50 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Andy Lutomirski <luto@amacapital.net> - 2015-10-14 18:50 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Cyrill Gorcunov <gorcunov@gmail.com> - 2015-10-14 19:00 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Stas Sergeev <stsp@list.ru> - 2015-10-14 19:00 +0200
Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context Cyrill Gorcunov <gorcunov@gmail.com> - 2015-10-14 19:10 +0200
[RFC 2/4] x86/signal/64: Fix SS if needed when delivering a 64-bit signal Andy Lutomirski <luto@kernel.org> - 2015-10-13 03:10 +0200
csiph-web