Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1247207

Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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