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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Aug 2015 07:58:30 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Brian Gerst <brgerst@...il.com>,
	Borislav Petkov <bp@...en8.de>,
	Stas Sergeev <stsp@...rs.sourceforge.net>
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered
 to 64-bit programs breaks dosemu

On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev <stsp@...t.ru> wrote:
> 13.08.2015 11:39, Ingo Molnar пишет:
>>
>> * Andy Lutomirski <luto@...capital.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/