You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While container mode is the default and recommended in the documentation, we currently do not strongly warn against it. For example, there is no warning when running BenchExec with --no-container (and typically, this is good behavior because warning about something that the user explicitly requested is likely to lead to warning fatigue). And while it is clear that a tool running in no-container mode can escape limits and measurements by moving itself to a different cgroup, we thought that for a non-malicious tool this would be unlikely to happen. Tools only change a cgroup if they do so deliberately, and most tools that do that work well and stay below the cgroup where we put them. BenchExec for example takes care to follow this.
But the introduction of cgroupsv2 has changed this. Because of the difficulties in using a process' current cgroup, BenchExec by default asks systemd to create a cgroup for it, and that cgroup will be somewhere else in the cgroup tree. So if we use runexec --no-container to benchmark a tool that internally itself calls runexec again, this will lead to the inner runexec calls escaping all limits and measurements of the outer runexec. This hasn't happened with cgroupsv1 and is certainly unexpected, so we should warn about this in our documentation and when BenchExec is started with --no-container.
The text was updated successfully, but these errors were encountered:
While container mode is the default and recommended in the documentation, we currently do not strongly warn against it. For example, there is no warning when running BenchExec with
--no-container
(and typically, this is good behavior because warning about something that the user explicitly requested is likely to lead to warning fatigue). And while it is clear that a tool running in no-container mode can escape limits and measurements by moving itself to a different cgroup, we thought that for a non-malicious tool this would be unlikely to happen. Tools only change a cgroup if they do so deliberately, and most tools that do that work well and stay below the cgroup where we put them. BenchExec for example takes care to follow this.But the introduction of cgroupsv2 has changed this. Because of the difficulties in using a process' current cgroup, BenchExec by default asks systemd to create a cgroup for it, and that cgroup will be somewhere else in the cgroup tree. So if we use
runexec --no-container
to benchmark a tool that internally itself callsrunexec
again, this will lead to the innerrunexec
calls escaping all limits and measurements of the outerrunexec
. This hasn't happened with cgroupsv1 and is certainly unexpected, so we should warn about this in our documentation and when BenchExec is started with--no-container
.The text was updated successfully, but these errors were encountered: