On Mon, Mar 7, 2016 at 12:02 PM, Stas Sergeev <stsp@xxxxxxx> wrote:So what do you think about checking SS when
09.01.2016 04:48, Andy Lutomirski ÐÐÑÐÑ:
On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev <stsp@xxxxxxx> wrote:How is this one going?
09.01.2016 02:24, Andy Lutomirski ÐÐÑÐÑ:I'll try to remember to tack it on to the sigcontext series.
It's not sigaltstack that I'm thinking about. It's signal delivery.Will you take care of this one?
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.
Looks quite dangerous for dosemu! And absolutely
undebuggable: you never know when you hit it.
What exactly do you mean? Is this a documented part of ABI?There seem to be one more bug in sigcontext handling.Clearing NT seems sane.
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 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),But this is not a sigreturn() problem and not sigaltstack() problem,
or we could make the change. As a more conservative option, we couldHmm. But if we deliver such signal, the userspace will still
make it so that AC is cleared on entry to an alignment check signal.