105
edits
Changes
Jump to navigation
Jump to search
About other approaches for 32-bit C/R
Line 28:
Line 28:
==== Bug with mmaping over 4Gb ====
==== Restore with exec() of 32-bit dummy binary vs from 64-bit CRIU ====
==== Restore with exec() of 32-bit dummy binary vs from 64-bit CRIU ====
−Restore of 32-bit application can be done with some daemon that runs in 32-bit mode and communicates with CRIU binary (or 32-bit CRIU subprocess).<br />
+Restore of 32-bit application can be done with some daemon that runs in 32-bit mode and communicates with CRIU binary (or 32-bit CRIU subprocess).
+'''Pros''':
'''Pros''':
* no kernel patches expected (not quite true: vDSO mremap() still needed support)
* no kernel patches expected (not quite true: vDSO mremap() still needed support)
Line 41:
Line 42:
==== Restore with a flag to sigreturn() or arch_prctl() ====
==== Restore with a flag to sigreturn() or arch_prctl() ====
+
+The initial attempt to do 32-bit C/R, was rejected by lkml community by many reasons. It should have swapped thread info flags (such as <code>TIF_ADDR32</code>/<code>TIF_IA32</code>/<code>TIF_X32</code>), unmap native 64-bit vDSO blob from process's address space and map compatible 32-bit vDSO - all according to some bit in sigframe in <code>rt_sigreturn()</code> call or some dedicated for it <code>arch_prctl()</code> call.
+
+'''Pros''':
+* Simple from the point of CRIU: just do sigreturn with a new bit set or call arch_prctl() and do sigreturn
+
+'''Cons''':
+* If 32-bit vDSO image on restored host differ from dumped (in image), need to catch task after sigreturn and make jump trampolines separately - in case of arch_prctl() simpler ([https://lkml.org/lkml/2016/6/1/425 that's why arch_prctl was in initial RFC])
+* Too many points of failure for one syscall, too complicated
+* Just adding a way to swap those thread info flags from userspace would result in a new races/bugs (as e.g., TASK_SIZE macro depends on TIF_ADDR32, the mmap code may do unexpected things)
+
+After discussion in lkml, conclusion was: separate changing personality (like thread info flags) from API to map vDSO blobs, remove TIF_IA32 flag that differs 32 from 64-bit tasks and look on syscall's nature: compat syscall, x32 syscall or native syscall.
==== Seizing with two 32-bit and 64-bit parasites ====
==== Seizing with two 32-bit and 64-bit parasites ====
+
+'''Pros''':
+* no 32-bit calls in 64-bit parasite and vice-versa
+* no need in exit in parasite: ptrace code doesn't allow to set 32-bit regset to 64-bit task and the reverse, running parasite the same nature as task bereaves us from those limits
+
+'''Cons''':
+* need to have two/three (for x32 also) blobs for seizing
+* macros in makefiles to build two parasites
+* serialization of parasite's answers: arguments to parasite differ in size - serialize them, which added not nice-looking and less readable C macros
==== Current approach ====
==== Current approach ====
+
=== Needs to be done (TODO) ===
=== Needs to be done (TODO) ===
+
+==== Bug with mmaping over 4Gb ====
==== List of failed tests ====
==== List of failed tests ====
Line 86:
Line 111:
| mmx00 || ?
| mmx00 || ?
|}
|}
−