On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev <s...@list.ru> wrote:
> 13.08.2015 11:39, Ingo Molnar пишет:
>>
>> * Andy Lutomirski <l...@amacapital.net> wrote:
>>
>>
>>>> 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...
>>>
>>> That feature is so specialized that I think you should just probe it.
>>>
>>> void foo(...) {
>>> sigcontext->ss = 7;
>>> }
>>>
>>> modify_ldt(initialize descriptor 0);
>>> sigaction(SIGUSR1, foo, SA_SIGINFO);
>>> if (ss == 7)
>>> yay;
>>>
>>> Fortunately, all kernels that restore ss also have espfix64, so you
>>> don't need to worry about esp[31:16] corruption on those kernels
>>> either.
>>>
>>> I suppose we could add a new uc_flag to indicate that ss is saved and
>>> restored,
>>> though. Ingo, hpa: any thoughts on that? There will always be some
>>> kernel
>>> versions that save and restore ss but don't set the flag, though.
>>
>> So this new flag would essentially be a 'the ss save/restore bug is fixed
>> for
>> sure' flag, not covering old kernels that happen to have the correct
>> behavior,
>> right?
>>
>> Could you please map out the range of kernel versions involved - which
>> ones:
>>
>> - 'never do the right thing'
>> - 'do the right thing sometimes'
>> - 'do the right thing always, but by accident'
>> - 'do the right thing always and intentionally'
>>
>> ?
>>
>> I'd hate to complicate a legacy ABI any more. My gut feeling is to let
>> apps either
>> assume that the kernel works right, or probe the actual behavior. Adding
>> the flag
>> just makes it easy to screw certain kernel versions that would still work
>> fine if
>> the app used actual probing. So I don't see the flag as an improvement.
>>
>> If your patch fixes the regression that would be a good first step.
>
> I've tested the patch.
> It doesn't fix the problem.
> It allows dosemu to save the ss the old way, but,
> because dosemu doesn't save it to the sigreturn()'s-expected
> place (sigcontext.__pad0), it crashes on sigreturn().
>
> So the problem can't be fixed this way --> NACK to the patch.
>
> I may be unavailable for further testings till next week.
I'm still fighting with getting DOSEMU to run at all in my VM.
I must be missing something. What ends up in ss/__pad0? Wouldn't it
contain whatever signal delivery put there (i.e. some valid ss value)?
--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/
