linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@list.ru>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: sigaltstack breaks swapcontext()
Date: Tue, 8 Mar 2016 00:20:55 +0300	[thread overview]
Message-ID: <56DDF0B7.1070600@list.ru> (raw)
In-Reply-To: <CALCETrVtuxhYO0LTM-Vtx9f1Q9bHtZhd+9YihNNqzRci13+eoA@mail.gmail.com>

08.03.2016 00:10, Andy Lutomirski пишет:
> On Mon, Mar 7, 2016 at 12:02 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 09.01.2016 04:48, Andy Lutomirski пишет:
>>> On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev <stsp@list.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?

  reply	other threads:[~2016-03-07 21:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06 15:45 sigaltstack breaks swapcontext() Stas Sergeev
2016-01-06 18:05 ` Andy Lutomirski
2016-01-06 18:42   ` Stas Sergeev
2016-01-06 19:14     ` Andy Lutomirski
2016-01-06 19:31       ` Stas Sergeev
2016-01-06 19:53         ` Andy Lutomirski
2016-01-07 15:33           ` Stas Sergeev
2016-01-07 17:23             ` Andy Lutomirski
2016-01-07 19:10               ` Stas Sergeev
2016-01-08 13:49   ` Stas Sergeev
2016-01-08 23:24     ` Andy Lutomirski
2016-01-08 23:40       ` Stas Sergeev
2016-01-09  1:43       ` Stas Sergeev
2016-01-09  1:48         ` Andy Lutomirski
2016-03-07 20:02           ` Stas Sergeev
2016-03-07 21:10             ` Andy Lutomirski
2016-03-07 21:20               ` Stas Sergeev [this message]
2016-03-07 21:32                 ` Andy Lutomirski
2016-03-07 21:38                   ` One Thousand Gnomes
2016-03-07 21:45                   ` Stas Sergeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56DDF0B7.1070600@list.ru \
    --to=stsp@list.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).