Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 7 Mar 2016 13:10:04 -0800 | Subject | Re: sigaltstack breaks swapcontext() |
| |
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? > 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. We could add yet another SS flag (sigh), 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.
--Andy
-- Andy Lutomirski AMA Capital Management, LLC
| |