Message-ID: <CALCETrV0X2tiyxbgjvWWxRGSrxr1usoseSLEdbCoioTQ+M9_Uw@mail.gmail.com>
Date:	Mon, 7 Mar 2016 13:32:10 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Stas Sergeev <stsp@...t.ru>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	X86 ML <x86@...nel.org>
Cc:	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: sigaltstack breaks swapcontext()

On Mon, Mar 7, 2016 at 1:20 PM, Stas Sergeev <stsp@...t.ru> wrote:
> 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?

It fits in with your series, and you're welcome to do it.  You can
also poke me and get me to do it.

>
>>> 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.

ABI is that which existing programs rely on, which may or may not be
related to any docs.  If there are AC users and they want their signal
handlers to be protected by AC, then this change would break them.

>
>>    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?

I meant SA_ flag, not SS_.  Whoops.

>
>> 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?

Userspace could handle the SIGBUS and clear AC from regs->flags if
they were so inclined.

Anyway, maybe Linus or the x86 maintainers have some idea of how AC is
used.  If there are people who use it for a whole program and if libc
can survive the experience, then they might expect even signal
handlers to run with AC set.  But if they're sane and protect just
critical pieces of code being tested with AC, we could be polite and
clear AC on signal handler entry.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Powered by blists - more mailing lists