Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev <stsp@list.ru>]

13.08.2015 00:37, Andy Lutomirski пишет:
> On Wed, Aug 12, 2015 at 1:55 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 12.08.2015 23:47, Andy Lutomirski пишет:
>>
>>> On Wed, Aug 12, 2015 at 1:45 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>> 12.08.2015 23:28, Andy Lutomirski пишет:
>>>>
>>>>> On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>> 12.08.2015 23:01, Andy Lutomirski пишет:
>>>>>>> On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev <stsp@list.ru> wrote:
>>>>>>>> 12.08.2015 22:20, Andy Lutomirski пишет:
>>>>>>>>> current kernels, it stays switched.  If we change this, it won't
>>>>>>>>> stay
>>>>>>>>> switched.  Even ignoring old ABI, it's not really clear to me what
>>>>>>>>> the
>>>>>>>>> right thing to do is.
>>>>>>>> There can be the following cases:
>>>>>>>> - switch_userspace_thread() switches fs to non-zero selector
>>>>>>>> - switch_userspace_thread() switches the fs base via syscall
>>>>>>>> - switch_userspace_thread() switches fs in sigcontext
>>>>>>>> - switch_userspace_thread() switches fs_base in sigcontext (???)
>>>>>>>> What exactly case do you have in mind?
>>>>>>>> I'd say, the way x86_32 is doing things - is good, but the
>>>>>>>> bases... perhaps, in ideal world, they should be a part of
>>>>>>>> the sigcontext as well?
>>>>>>> Any of the above.  What do you want the kernel to do, and how does the
>>>>>>> kernel know you want to do that?  The kernel has to pick *some*
>>>>>>> semantics here.
>>>>>> Assuming the bases are made the part of a sigcontext,
>>>>>> I'd say there would be no ambiguities remained at all:
>>>>>> whatever you change in a sigcontext, will be "applied" by
>>>>>> the sigreturn(). Whatever you put in the registers
>>>>>> (either segregs or MSRs), is valid until sigreturn(), then
>>>>>> forgotten forever.
>>>>>> The mess only comes in when some things are part of
>>>>>> sigcontext and some are not. But if you have _all_ things
>>>>>> accessable in sigcontext, then the user has a way of expressing
>>>>>> his needs very clearly: he'll either touch sigcontext or direct
>>>>>> values, depending on what he need.
>>>>>>
>>>>>> Is this right?
>>>>> Maybe, except that doing this might break existing code (Wine and Java
>>>>> come to mind).  I'm not really sure.
>>>> Yes, but that's why I was talking about some new
>>>> flag. Maybe a new sigaction() flag? Or something else that
>>>> will allow the user to request explicitly the new handling
>>>> where the things are all switched by the kernel. Then
>>>> the old programs that don't use that flag, will remain
>>>> unaffected. I realize this may be a lot of work... But please
>>>> note that there will be no more a chance like this one,
>>>> when things are already badly broken. :)
>>> I think that, with my patch, we get the best of both worlds.  We keep
>>> the old behavior in cases where it would work, and we switch to the
>>> new behavior in cases where the old behavior would result in killing
>>> the task.
>> But I mean also fs/TLS.
>> There is a chance now to fix things for good, all at once. :)
>> With such an ss patch applied to stable, there will be no more
>> such a chance ever. What's your opinion on the possibility of
>> fixing the TLS problem?
>> Also I am not sure about the sigreturn()'s detection: is it
>> a subject of the subsequent patch, or you dropped an idea?
> I think these things shouldn't be conflated.  If we can fix it
> transparently (i.e. if my patch works), then I think we should do
> something like my patch.
OK.
I'll try to test the patch tomorrow, but I think the sigreturn()'s
capability detection is still needed to easily replace the iret trampoline
in userspace (without generating a signal and testing by hands).
Can of course be done with a run-time kernel version check...