Images

The criu utility dumps the state of processes/containers into a set of image files. This article describes the format of them.

Types of image files

CRIU images can be in one of formats

• crtools specific images in google protocol buffer format (PB format)
• crtools specific images with binary data in it
• image files in 3rd party format

crtools-specific format description

All crtools-specific image files begin with 32-bit magic cookie. Images in PB format are followed by zero or more entries of the same type (not size!), each entry is preceded with 32-bit entry size value (not including this 32-bit value itself). Optionally each entry may be followed by extra payload which depends on the entry type.

IOW protocol-buffers image files look like

IMAGE_FILE ::= MAGIC { ENTRY }
ENTRY      ::= SIZE PAYLOAD [ EXTRA ]
PAYLOAD    ::= "message encoded in ProtocolBuffer format"
EXTRA      ::= "arbitrary blob, depends on the PAYLOAD contents"

MAGIC      ::= "32 bit integer"
SIZE       ::= "32 bit integer, equals the PAYLOAD length"

The amount of entries in a image file depends on the type of file.

Types of image files with PB data

Such images can be one of

Array image files

In these files the amount of entries can be any. You should read the image file up to the EOF to find out the exact number.

Single-entry image files

In these files exactly one entry is stored.

A file type can be guessed by the magic. The description of the entries in ProtocolBuffers language are in <type>.proto files.

name	type	description	extra payload
inventory	single-entry	Top level description of images	-
fdinfo	array	Open file descriptors	-
regfile	array	Paths to files opened with open(2) syscall	-
eventfd	array	Eventfd file information	-
eventpoll	array	Eventpoll file information	-
eventpoll-tfd	array	Target file descriptors of eventpoll fds	-
inotify-file	array	Inotify file information	-
inotify-wd	array	Watch descriptors of inotify fds	-
signalfd	array	signalfd info
core	single-entry	Arch-dependent information (registers, etc.)	-
mm	single-entry	Address space generic information (segments, exe file, etc.)	-
vmas	array	Virtual mappings (mmap(2))	-
pipes	array	Pipes information	-
pipes-data	array	Contents of pipes	entry.bytes bytes of data sitting in a pipe
fifo	array	FIFO information	-
fifo-data	array	Contents of FIFOs	same as in pipes-data
pstree	array	Process tree linkage and IDs	-
sigacts	array	Signal handling map	-
unixsk	array	Unix domain sockets	-
inetsk	array	PF_INET sockets, both IPv4 and IPv6	-
sk-queues	array	Contents of socket queues	entry.length bytes of data, one entry per packet
itimers	array	Interval timers state	-
creds	single-entry	Task credentials: uids, gids, caps, etc.	-
fs	single-entry	Chroot and chdir information	-
path-remap	array	File paths remaps	-
ghost-file	single-entry	Ghost files (those, not visible from FS, but still used by tasks)	Right after the entry up to the EOF goes the contents of the file
tcp-stream	single-entry	TCP connection state (including data in queues)	-
mountpoints	array	Mountpoints information	-
utsns	single-entry	Uname nodename and domainname of a UTS namespace	-
tty	array	Information about opened tty-s
tty-info	array	Termios and similar stuff about tty-s
packetsk	array	Info about PF_PACKET sockets
netdev	array	Info about network devices

Images with binary crtools data

These are

Memory dumps

These files contain memory dumps. The format is

IMAGE ::= MAGIC [ ADDRESS DATA ]
ADDRESS ::= "64-bit virtual address"
DATA ::= "4K bytes blob (i.e. -- memory page)"