linux-kernel - Re: sigaltstack breaks swapcontext()

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 for Android: free password hash cracker in your pocket

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

Message-ID: <56DDF0B7.1070600@list.ru>
Date:	Tue, 8 Mar 2016 00:20:55 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: sigaltstack breaks swapcontext()

08.03.2016 00:10, Andy Lutomirski пишет:
> On Mon, Mar 7, 2016 at 12:02 PM, Stas Sergeev <stsp@...t.ru> wrote:
>> 09.01.2016 04:48, Andy Lutomirski пишет:
>>> On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>>> 09.01.2016 02:24, Andy Lutomirski пишет:
>>>>> It's not sigaltstack that I'm thinking about.  It's signal delivery.
>>>>> If you end up in DOS mode with SP coincidentally pointing to the
>>>>> sigaltstack (but with different SS so it's not really the
>>>>> sigaltstack), then the signal delivery will malfunction.
>>>> Will you take care of this one?
>>>> Looks quite dangerous for dosemu! And absolutely
>>>> undebuggable: you never know when you hit it.
>>> I'll try to remember to tack it on to the sigcontext series.
>> How is this one going?
So what do you think about checking SS when
evaluating the on_sig_stack condition? Will you
fix this, or should I try?

>> There seem to be one more bug in sigcontext handling.
>> dosemu have this code:
>> ---
>>    /*
>>     * FIRST thing to do in signal handlers - to avoid being trapped into
>> int0x11
>>     * forever, we must restore the eflags.
>>     */
>>    loadflags(eflags_fs_gs.eflags);
>> ---
>>
>> I quickly checked the kernel code, and it seems the
>> flags are indeed forgotten, even on ia32! I think the
>> most dangerous flags are AC and NT. But most of
>> others are important too. IMHO the safe defaults
>> should be forced when entering the sighandler.
>> Would you mind taking a look at this problem too?
> Clearing NT seems sane.
>
> Clearing AC seems like an ABI break, so I'd be a bit nervous about
> clearing AC unconditionally.
What exactly do you mean? Is this a documented part of ABI?
Where can I find out how the flags are supposed to be set on
entering a sighandler, any docs on that?
I thought they should just be forced to some default value, the
same as the segregs are handled.

>    We could add yet another SS flag (sigh),
But this is not a sigreturn() problem and not sigaltstack() problem,
so what exactly flag do you mean?

> or we could make the change.  As a more conservative option, we could
> make it so that AC is cleared on entry to an alignment check signal.
Hmm. But if we deliver such signal, the userspace will still
crash, so what's the use?