On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev <s...@list.ru> wrote: > 03.09.2015 00:39, Andy Lutomirski пишет: > >> On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev <s...@list.ru> wrote: >>> >>> 02.09.2015 22:06, Andy Lutomirski пишет: >>> >>>> On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev <s...@list.ru> wrote: >>>>> >>>>> 02.09.2015 21:17, Andy Lutomirski пишет: >>>>>> >>>>>> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev <s...@list.ru> wrote: >>>>>>> >>>>>>> 02.09.2015 17:21, Andy Lutomirski пишет: >>>>>>>>>> >>>>>>>>>> This should work for old DOSEMU. It's a bit gross, but it has the >>>>>>>>>> nice benefit that everyone (even things that aren't DOSEMU) gain >>>>>>>>>> the >>>>>>>>>> ability to catch signals thrown from bogus SS contexts, which >>>>>>>>>> probably >>>>>>>>>> improves debugability. It's also nice to not have the SA flag. >>>>>>>>> >>>>>>>>> Pros: >>>>>>>>> - No new SA flag >>>>>>>>> - May improve debugability in some unknown scenario where people >>>>>>>>> do not want to just use the new flag to get their things improved >>>>>>>>> >>>>>>>>> Cons: >>>>>>>>> - Does not allow to cleanly use siglongjmp(), as then there is a >>>>>>>>> risk >>>>>>>>> to jump to 64bit code with bad SS >>>>>>>> >>>>>>>> What's the issue here? I don't understand. >>>>>>>> >>>>>>>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so >>>>>>>> it >>>>>>>> won't be affected. AFAIK all implementations of siglongjmp are >>>>>>>> likely >>>>>>>> to call sigprocmask or similar, and that will clobber SS. I'm not >>>>>>>> aware of an implementation of siglongjmp that uses sigreturn. >>>>>>> >>>>>>> I am not saying siglongjmp() will be affected. >>>>>>> Quite the opposite: it won't, which is bad. :) >>>>>>> If you have always correct SS, you can use siglongjmp(). If you have >>>>>>> broken SS at times, siglongjmp() will be an asking for troubles, as >>>>>>> it exactly does not restore SS. >>>>>>> dosemu could do a good use of siglongjmp() to get back to 64bit code >>>>>>> from its sighandler. >>>>>> >>>>>> This seems like it would be relying unpleasantly heavily on libc >>>>>> internals. >>>>> >>>>> Could you please clarify? >>>>> If kernel always passes the right SS to the sighandler, then what's >>>>> the problem? >>>> >>>> What's the exact siglongjmp usage you have in mind? Signal context >>>> isn't normally involved AFAIK. >>> >>> dosemu needs 2 return pathes: >>> 1. to DOS code >>> 2. to 64bit code (dosemu is not all in a sighandler, right?) >>> >>> How it is currently achieved: >>> dosemu1: >>> 1. sigreturn() + iret (to DOS) >>> 2. modify sigcontext -> sigreturn() (to 64bit asm helper) >>> >>> dosemu2: >>> 1. sigreturn() + iret (to DOS) >>> 2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded) >> >> So you're modifying sigcontext such that it returns to a C function >> that calls longjmp? > > Yes. > >>> How dosemu2 is supposed to do this: >>> 1. sigreturn() (to DOS) >>> 2. siglongjmp() (to 64bit C-coded) >> >> This should work fine on any kernel, right? > > 1 - not. > 2 - maybe. > If, as you say, siglongjmp() restores SS, I need to try it out. > (there is also a problem that most siglongjmp() implementations > are incompatible with sigaltstack(), but this is not what you can fix). >
1 - definitely needs kernel changes. I was referring to #2. 2 - siglongjmp probably varies in its behavior across different libc implementations. My point is that siglongjmp isn't a kernel-provided thing. >> For backwards compat, we either need the default behavior to be >> unchanged, or we need the default behavior to be something that works >> with existing dosemu. For existing dosemu, the only interesting cases >> (I think) are signal delivery from *valid* 16-bit context, in which >> case we need to preserve SS so that the signal handler can read it out >> with mov ..., %ss, and sigreturn to 64-bit mode for the IRET >> trampoline. For sigreturn, IIUC old dosemu will replace the saved CS >> with a 64-bit code segment selector and won't touch the saved SS >> because it doesn't know about the saved SS. Those dosemu versions >> don't care what SS actually contains after sigreturn, because they're >> immediately going to change it again using IRET. So we just need to >> make sure we return without faulting. >> >> New dosemu2 would like to sigreturn directly back to 16-bit mode, so >> it needs the kernel to honor the saved ss value and restore it, >> possibly changed by dosemu. >> >> We obviously can't require old dosemu to set an SA flag to keep >> working. But, if we can get away with it, I think it's somewhat >> preferable not to require new DOSEMU to set an SA flag either. >> >> This has one major benefit at least: if new dosemu loads some random >> library that installs some async signal handler (SIGALRM for example), >> everything will work with regard to CS and SS. > > This case is covered if we do both things together: use > your heuristic when SA_hyz is not set, and don't use it > when its set. In this case dosemu2 will be able to request > the proper SS delivery for its sighandlers, but the 3rd-party > sighandlers will work too. > I think we have never discussed the possibility of doing > both things together, even though I have proposed it many > times. > After discussing this full-blown solution, we can think about > reducing it, either by removing the heuristic or by removing > SA_hyz, but discussing the full one would be nice too. > Your opinion is likely that no one will use this SA_hyz in > presence of the heuristic that "seems to work anyway". > But in the light of extending it for TLS (with a new flag), > I wouldn't be so sure. You can also document it as a > needed flag when user code touches SS, and then it will > be used. dosemu1 code that doesn't use it, will eventually > be forgotten. So IMHO whether it will be used, is fully up > to how will you market it. :) I'll think about it. I'll think about FS and GS, too, although that's still a longer-term thing. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/