Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1352011
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: sigaltstack breaks swapcontext() |
| Date | 2016-03-07 22:50 +0100 |
| Message-ID | <rabcl-8ob-9@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <qOQPf-6LO-1@gated-at.bofh.it> <ra9Dz-7xE-3@gated-at.bofh.it> <raaJl-8cF-35@gated-at.bofh.it> <raaT0-8gx-13@gated-at.bofh.it> <rab2F-8kT-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
08.03.2016 00:32, Andy Lutomirski пишет: > On Mon, Mar 7, 2016 at 1:20 PM, Stas Sergeev <stsp@list.ru> wrote: >> 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? > 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. But aren't such users (I am sure there are none who use AC in a sighandler) supposed to set the AC flag explicitly in a sighandler? I just thought this is a bug, not an ABI feature at all. So no one should rely on that IMHO. >>> 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. But you said "yet another", and we haven't yet added any SA_ flag here. :) >>> 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. Oh, no, I'd better leave popf in the beginning of a sighandler, as it is now done in dosemu. :) > 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. I wonder how do they get such an expectation. It is likely a bug, unexpected behaviour. I wonder if someone could expect this, and I really doubt someone needs AC in a sighandler. So I agree, lets see what other people think, and if there are no couter arguments, lets just force eflags to the default.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-03-07 21:10 +0100
Re: sigaltstack breaks swapcontext() Andy Lutomirski <luto@amacapital.net> - 2016-03-07 22:20 +0100
Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-03-07 22:30 +0100
Re: sigaltstack breaks swapcontext() One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-03-07 22:40 +0100
Re: sigaltstack breaks swapcontext() Andy Lutomirski <luto@amacapital.net> - 2016-03-07 22:40 +0100
Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-03-07 22:50 +0100
csiph-web