mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-01-23 02:14:37 +00:00
bab72af9a5
This commit teaches criu to deal with processes which have a "[uprobes]" vma.
This vma is mapped by the kernel when execution hits a uprobe location. This
is done so as to execute the uprobe'd instruciton out-of-line in the special
vma. The uprobe'd location is replaced by a software breakpoint instruction,
which is int3 on x86. When execution reaches that location, control is
transferred over to the kernel, which then executes whatever handler code
it has to, for the uprobe, and then executed the replaced instruction out-of-line
in the special vma. For more details, refer to this commit:
d4b3b6384f
Reason for adding a new option
------------------------------
A new option is added instead of making the uprobes vma handling transparent
to the user, so that when a dump is attempted on a process tree in which a
process has the uprobes vma, criu will error, asking the user to use this option.
This gives the user a chance to check what uprobes are attached to the processes
being dumped, and try to ensure that those uprobes are active on restore as well.
Again, the same reason for requiring this option on restore as well. Because
if a process is dumped with an active uprobe, and on restore if the uprobe
is not active, then if execution reaches the uprobe location, then the process
will be sent a SIGTRAP, whose default behaviour will terminate and core dump
the process. This is because the code pages are dumped with the software
breakpoint instruction replacement at the uprobe'd locations. On restore, if
execution reaches these locations and the kernel sees no associated active
uprobes, then it'll send a SIGTRAP.
So, using this option is on dump and restore is an implicit guarantee on the
user's behalf that they'll take care of the active uprobes and that any future
SIGTRAPs because of this are not on us! :)
Handling uprobes vma on dump
----------------------------
We don't need to store any information about the uprobes vma because it's
completely handled by the kernel, transparent to userspace. So, when a uprobes
vma is detected, we check if the --allow-uprobes option was specified or not.
If so, then the allow_uprobes boolean in the inventory image is set (this is
used on restore). The uprobes vma is skipped from being added to the vma list.
Handling uprobes vma on restore
-------------------------------
If allow_uprobes is set in the inventory image, then check if --allow-uprobes
is specified or not. Restoring the vma is not required.
Fixes: checkpoint-restore#1961
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
37 lines
1.1 KiB
Protocol Buffer
37 lines
1.1 KiB
Protocol Buffer
// SPDX-License-Identifier: MIT
|
|
|
|
syntax = "proto2";
|
|
|
|
import "core.proto";
|
|
|
|
enum lsmtype {
|
|
NO_LSM = 0;
|
|
SELINUX = 1;
|
|
APPARMOR = 2;
|
|
}
|
|
|
|
// It is not possible to distinguish between an empty repeated field
|
|
// and unset repeated field. To solve this problem and provide backwards
|
|
// compabibility, we use the 'plugins_entry' message.
|
|
message plugins_entry {
|
|
repeated string plugins = 12;
|
|
};
|
|
|
|
message inventory_entry {
|
|
required uint32 img_version = 1;
|
|
optional bool fdinfo_per_id = 2;
|
|
optional task_kobj_ids_entry root_ids = 3;
|
|
optional bool ns_per_id = 4;
|
|
optional uint32 root_cg_set = 5;
|
|
optional lsmtype lsmtype = 6;
|
|
optional uint64 dump_uptime = 8;
|
|
optional uint32 pre_dump_mode = 9;
|
|
optional bool tcp_close = 10;
|
|
optional uint32 network_lock_method = 11;
|
|
optional plugins_entry plugins_entry = 12;
|
|
// Remember the criu_run_id when CRIU dumped the process.
|
|
// This is currently used to delete the correct nftables
|
|
// network locking rule.
|
|
optional string dump_criu_run_id = 13;
|
|
optional bool allow_uprobes = 14;
|
|
}
|