Difference between revisions of "Code blobs"

From CRIU
Jump to: navigation, search
(Created page with "Pavel pointed ------------- One thing to do: LINK pie/parasite.built-in.o GEN pie/parasite.built-in.bin.o GEN pie/parasite.built-in.bin GEN pie/par...")
 
Line 1: Line 1:
Pavel pointed
+
== Summary ==
-------------
+
 
One thing to do:
+
There are two moments of time when crtools runs in somewhat strange environment
 +
 
 +
* Parasite code execution
 +
* Restore of page dumped contents and yield rt-sigreturn to continue execution of the original program
 +
 
 +
== Building PIE code blobs for crtools ==
 +
 
 +
Parasite code executes in dumpee process context thus it needs to be [http://en.wikipedia.org/wiki/Position-independent_code PIE]
 +
compiled and to have own stack. The same applies to restorer code, which takes place at the very end of restore procedure.
 +
 
 +
Thus we need to reserve stack place statically somewhere in crtools and use it at dump/checkpoint stages. To achieve
 +
this (and still have some human way to edit source code) we do the following tricks
 +
 
 +
* Parasite code has own bootstrap code laid in pure assembler file (parasite_head.S)
 +
* Restorer bootstrap code is done a bit simplier in restorer.c file.
 +
 
 +
For both cases we generate headers files which consist of
 +
 
 +
* Functions offsets for export
 +
* C array of binary data, for example
 +
 
 +
#define parasite_blob_offset____export_parasite_args 0x000000000000002c
 +
#define parasite_blob_offset____export_parasite_cmd 0x0000000000000028
 +
#define parasite_blob_offset____export_parasite_head_start 0x0000000000000000
 +
#define parasite_blob_offset____export_parasite_stack 0x0000000000006034
 +
 +
static char parasite_blob[] = {
 +
0x48, 0x8d, 0x25, 0x2d, 0x60, 0x00, 0x00, 0x48,
 +
0x83, 0xec, 0x10, 0x48, 0x83, 0xe4, 0xf0, 0x6a,
 +
0x00, 0x48, 0x89, 0xe5, 0x8b, 0x3d, 0x0e, 0x00,
 +
0x00, 0x00, 0x48, 0x8d, 0x35, 0x0b, 0x00, 0x00,
 +
...
 +
};
 +
 
 +
These headers we include in crtools compiled file and then use for checkpoint/restore.
 +
 
 +
Generation of this files is done in several steps
 +
 
 +
* All object files needed by are linked into 'built-in.o'
 +
* With help of ld script we move code and data to special layout, i.e. to sections with predefined names and addresses
 +
* With help of objcopy we move the section(s) we need to one binary file
 +
* With help of hexdump we generate C-styled array of data and put it into -blob.h header
 +
 
 +
== Example of building procedure ==
  
 
   LINK    pie/parasite.built-in.o
 
   LINK    pie/parasite.built-in.o
Line 7: Line 50:
 
   GEN      pie/parasite.built-in.bin
 
   GEN      pie/parasite.built-in.bin
 
   GEN      pie/parasite-blob.h
 
   GEN      pie/parasite-blob.h
 
+
 
 
   LINK    pie/restorer.built-in.o
 
   LINK    pie/restorer.built-in.o
 
   GEN      pie/restorer.built-in.bin.o
 
   GEN      pie/restorer.built-in.bin.o
 
   GEN      pie/restorer.built-in.bin
 
   GEN      pie/restorer.built-in.bin
 
   GEN      pie/restorer-blob.h
 
   GEN      pie/restorer-blob.h
 
need a doc (on wiki I suppose) explaining why we need 4 files
 
for each -- parasite and restorer blobs.
 

Revision as of 14:07, 19 February 2013

Summary

There are two moments of time when crtools runs in somewhat strange environment

  • Parasite code execution
  • Restore of page dumped contents and yield rt-sigreturn to continue execution of the original program

Building PIE code blobs for crtools

Parasite code executes in dumpee process context thus it needs to be PIE compiled and to have own stack. The same applies to restorer code, which takes place at the very end of restore procedure.

Thus we need to reserve stack place statically somewhere in crtools and use it at dump/checkpoint stages. To achieve this (and still have some human way to edit source code) we do the following tricks

  • Parasite code has own bootstrap code laid in pure assembler file (parasite_head.S)
  • Restorer bootstrap code is done a bit simplier in restorer.c file.

For both cases we generate headers files which consist of

  • Functions offsets for export
  • C array of binary data, for example
#define parasite_blob_offset____export_parasite_args 0x000000000000002c
#define parasite_blob_offset____export_parasite_cmd 0x0000000000000028
#define parasite_blob_offset____export_parasite_head_start 0x0000000000000000
#define parasite_blob_offset____export_parasite_stack 0x0000000000006034

static char parasite_blob[] = {
	0x48, 0x8d, 0x25, 0x2d, 0x60, 0x00, 0x00, 0x48,
	0x83, 0xec, 0x10, 0x48, 0x83, 0xe4, 0xf0, 0x6a,
	0x00, 0x48, 0x89, 0xe5, 0x8b, 0x3d, 0x0e, 0x00,
	0x00, 0x00, 0x48, 0x8d, 0x35, 0x0b, 0x00, 0x00,
...
};

These headers we include in crtools compiled file and then use for checkpoint/restore.

Generation of this files is done in several steps

  • All object files needed by are linked into 'built-in.o'
  • With help of ld script we move code and data to special layout, i.e. to sections with predefined names and addresses
  • With help of objcopy we move the section(s) we need to one binary file
  • With help of hexdump we generate C-styled array of data and put it into -blob.h header

Example of building procedure

 LINK     pie/parasite.built-in.o
 GEN      pie/parasite.built-in.bin.o
 GEN      pie/parasite.built-in.bin
 GEN      pie/parasite-blob.h
 
 LINK     pie/restorer.built-in.o
 GEN      pie/restorer.built-in.bin.o
 GEN      pie/restorer.built-in.bin
 GEN      pie/restorer-blob.h