Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 18 Mar 2015 21:45:45 +0300 | From | Cyrill Gorcunov <> | Subject | Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs |
| |
On Wed, Mar 18, 2015 at 11:20:08AM -0700, Andy Lutomirski wrote: > > > > Basically the initial registers values are fetched with ptrace > > when program is been dumped, then on restore we copy them back > > into sigcontext. That said we don't mangle fs/gs anyhow simply > > restore the values back from dump. > > Wouldn't it be a little safer to have the kernel make you a sane > sigcontext by raising a signal and catching it rather than writing a > new one from scratch? Grr, maybe the kernel should version its > sigcontext structures.
I think it would, thanks for the point! I'll tune up our code.
> Getting fs from ptrace and restoring it to sigcontext is useless -- > ptrace handles fs correctly, but that sigcontext field is just > padding. > > Is CRIU at least reliably putting zero in the ss field? If so, we > could add a special case to translate zero to __USER_DS on restore. > (And then I'll update my test case, and we'll have to document it, > etc.)
Well, it should but need to check (we are tryin to not zeroify things until really needed in a sake of speed).
| ![\](/images/icornerr.gif) |