Messages in this thread | | | Subject | Re: [RFC 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context | From | Stas Sergeev <> | Date | Wed, 14 Oct 2015 21:34:09 +0300 |
| |
14.10.2015 21:06, Andy Lutomirski пишет: >> Also it doesn't seem to be saying what happens if CS is 32-bit >> and SS is invalid (the flag is not set). > > A new signal will be delivered. sigreturn doesn't modify its behavior > in this case -- it does the default thing, which is to honor the SS in > the saved context. Hmm, no, it didn't do this in the past for sure. It simply ignored SS, no matter to what mode it returns.
> So it will actually try to use that saved SS > value, which will fail, causing SIGSEGV. So it seems this logic assumes that when dosemu returns to 32bit, the previous SS is always still valid, am I right with the understanding? I.e. the one that kernel have saved on a signal delivery (because old dosemu does not overwrite it). If it is so, I'd say this assumption is very risky and will likely not hold. But maybe I am missing the point.
>>>> - with siglongjmp() >>> >>> siglongjmp is a glibc thing. It should work the same way it always >>> did. If it internally does a syscall (sigprocmask or whatever), that >>> will override SS. >> IMHO this side-effect needs to be documented somewhere. >> I was scared about using it because I thought SS could be left bad. >> Why I think it IS the kernel's problem is because in an ideal world >> the sighandler should not run with LDT SS at all, so there will be no >> fear about a bad SS after siglongjmp(). > > I agree, but that ship sailed quite a few years ago :( Please, once again you are claiming there were no solutions proposed in that area. :( If you didn't repeatedly ignore the SA_hyz solution, there will be the chance to do exactly that. But whatever.
| |