On Thu, Feb 11, 2016 at 11:49 AM, Borislav Petkov <[email protected]> wrote: > On Mon, Jan 25, 2016 at 01:34:14PM -0800, Andy Lutomirski wrote: > >> + * with a flat 32-bit selector.
How about: Sigreturn restores SS as follows: if (saved SS is valid || UC_STRICT_RESTORE_SS is set || saved CS is not 64-bit) new SS = saved SS else new SS = a flat 32-bit data segment >> + >> + * This behavior serves two purposes. It ensures that older programs >> + * that are unaware of the signal context's SS slot and either construct >> + * a signal context from scratch or that catch signals from segmented >> + * contexts and change CS to a 64-bit selector won't crash due to a bad >> + * SS value. > > I'm having hard time parsing that sentence and especially placing all > those "either", "or", "and" connectors at the proper levels. Would it be > more understandable as pseudocode? > >> It also ensures that signal handlers that do not modify >> + * the signal context at all return back to the exact CS and SS state >> + * that they came from. > > So my brain is reliably in a knot after this text. How about: --- cut here --- This behavior serves three purposes: - Legacy programs that construct a 64-bit sigcontext from scratch with zero or garbage in the SS slot (e.g. old CRIU) and call sigreturn will still work. - Old DOSEMU versions sometimes catch a signal from a segmented context, delete the old SS segment (with modify_ldt), and change the saved CS to a 64-bit segment. These DOSEMU versions expect sigreturn to send them back to 64-bit mode without killing them, despite the fact that the SS selector when the signal was raised is no longer valid. With UC_STRICT_RESTORE_SS clear, the kernel will fix up SS for these DOSEMU versions. - Old and new programs that catch a signal and return without modifying the saved context will end up in exactly the state they started in. Old kernels would lose track of the previous SS value. --- cut here --- FWIW, I have a DOSEMU patch that makes it use UC_STRICT_RESTORE_SS to get the behavior it actually wants on new kernels. It should make it faster and more reliable than was possible before. --Andy
