Please restore ᴄᴘᴜ time !

[ytrezq]

I have a ᴄᴘᴜ load intensive process. However, sometimes, one task is requiring too much time in order to complete and it needs to be skipped so that the next one is picked. In that case, the process checks how many days it has spent on the current task and gave up if the ᴄᴘᴜ time on that task is more than a week.

On such intensive, process criu is almost a checkpointing requirement. However, because it resets the ᴄᴘᴜ time on restore, the process never gives up when it should do so (and even crash if the task isn’t the first one because ᴄᴘᴜ_start_time−ᴄᴘᴜ_time becomes negative).

[rst0git]

I think this the reason for the reserved start_time field in the TaskCoreEntry structure (https://github.com/checkpoint-restore/criu/commit/4232b270b8a0c866b9ee26e7b5f381cbf7cea56a). However, it might not be straightforward to implement due to security concerns (e.g., kernel#7b55851).

This can be used to circumvent security systems that identify processes by their pid+start_time combination.

[Snorch]

I think this the reason for the reserved start_time field

In Virtuozzo 7 containers we've recently implemented checkpoint/restore of process start times.

It requires custom kernel interface so that host is able to configure start times for container processes on restore.

One can try to mainstream this functionality, I don't see any security problem of giving the process outside of container time namespace which is owning that timens the power to setup start times for processes in this timens on some initial stage.

This can be used to circumvent security systems that identify processes by their pid+start_time combination.

The user with root privilege can change start_time with systemtap scripts as he likes, so all such security systems are not protected against root.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[ytrezq]

@avagin hey, this is still a compatibility problem for programs which needs to track for how long they were running. Please reopen!

[adrianreber]

The bot should not have closed it. I reopened it.

[avagin]

@adrianreber we need to disable the bot and investigate why it doesn't work properly.