| Line 3: |
Line 3: |
| | This page contains project ideas for upcoming Google Summer of Code. | | This page contains project ideas for upcoming Google Summer of Code. |
| | | | |
| − | == Contacts == | + | == Contact == |
| | | | |
| − | Please contact the respective mentor for the idea you are interested in. For general questions feel free to send an email to the [mailto:criu@openvz.org mailing list] or write in [https://gitter.im/save-restore/criu gitter].
| + | First, make sure to go through the [[GSoC Students Recommendations]]. Once you build CRIU locally and C/R a simple process successfully, please contact the respective mentor for the idea you are interested in. For general questions feel free to send an email to the [mailto:criu@lists.linux.dev mailing list] or write in [https://gitter.im/save-restore/criu gitter]. |
| | | | |
| | == Project ideas == | | == Project ideas == |
| | | | |
| − | === Add support for memory compression === | + | === Kubernetes Operator for Automated Checkpointing === |
| − |
| |
| − | '''Summary:''' Support compression for page images
| |
| − |
| |
| − | We would like to support memory page files compression
| |
| − | in CRIU using one of the fastest algorithms (it's matter
| |
| − | of discussion which one to choose!).
| |
| | | | |
| − | This task does not require any Linux kernel modifications
| + | '''Summary:''' Extend the Checkpoint/Restore Operator with support for automated policy-based checkpointing. |
| − | and scope is limited to CRIU itself. At the same time it's
| |
| − | complex enough as we need to touch memory dump/restore codepath
| |
| − | in CRIU and also handle many corner cases like page-server and stuff.
| |
| − |
| |
| − | '''Details:''' | |
| − | * Skill level: intermediate
| |
| − | * Language: C
| |
| − | * Expected size: 350 hours
| |
| − | * Suggested by: Andrei Vagin <avagin@gmail.com>
| |
| − | * Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com>, Andrei Vagin <avagin@gmail.com>
| |
| | | | |
| − | === Add support for checkpoint/restore of CORK-ed UDP socket ===
| + | The [https://github.com/checkpoint-restore/checkpoint-restore-operator Checkpoint/Restore Operator] for Kubernetes currently supports only policies and parameters that limit the number of checkpoints. This project aims to extend the current support with automated policy-based checkpointing, allowing users to define triggers for checkpoint creation, such as time-based schedules, resource thresholds (CPU, memory, I/O usage), Kubernetes events (node drain, pod eviction, preemption), and application-level signals or annotations. |
| − |
| |
| − | '''Summary:''' Support C/R of corked UDP socket
| |
| − |
| |
| − | There's UDP_CORK option for sockets. As man page says:
| |
| − | <pre>
| |
| − | If this option is enabled, then all data output on this socket
| |
| − | is accumulated into a single datagram that is transmitted when
| |
| − | the option is disabled. This option should not be used in
| |
| − | code intended to be portable.
| |
| − | </pre>
| |
| | | | |
| − | Currently criu refuses to dump this case, so it's effectively a bug. Supporting
| |
| − | this will need extending the kernel API to allow criu read back the write queue
| |
| − | of the socket (see [[TCP connection|how it's done]] for TCP sockets, for example). Then
| |
| − | the queue is written into the image and is restored into the socket (with the CORK
| |
| − | bit set too).
| |
| − |
| |
| | '''Links:''' | | '''Links:''' |
| − | * https://github.com/checkpoint-restore/criu/issues/409 | + | * https://github.com/checkpoint-restore/checkpoint-restore-operator |
| − | * https://github.com/criupatchwork/criu/commit/a532312 | + | * https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api |
| − | * [[Sockets]], [[TCP connection]]
| + | |
| − | * [[https://groups.google.com/forum/#!topic/comp.os.linux.networking/Uz8PYiTCZSg UDP cork explained]]
| |
| − |
| |
| | '''Details:''' | | '''Details:''' |
| − | * Skill level: intermediate (+linux kernel) | + | * Skill level: intermediate |
| − | * Language: C | + | * Language: Go |
| | * Expected size: 350 hours | | * Expected size: 350 hours |
| − | * Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Andrei Vagin <avagin@gmail.com> | + | * Mentors: Viktória Spišaková <spisakova@ics.muni.cz>, Radostin Stoyanov <rstoyanov@fedoraproject.org>, Adrian Reber <areber@redhat.com> |
| | | | |
| − | === Add support for pidfd file descriptors === | + | === Forensic Checkpointing Framework for Kubernetes === |
| | | | |
| − | '''Summary:''' Support C/R of pidfd descriptors
| + | Kubernetes provides a highly dynamic and ephemeral environment where workloads can start and disappear very quickly and are continuously being rescheduled across different nodes in the cluster. |
| | + | One of the key challenges with forensic investigations in Kubernetes is capturing and preserving the evidence during security incidents. This project aims to address this problem by developing a framework for efficiently capturing and preserving the state of all running applications in a container at a specific point in time, along with the associated container configurations and metadata. These artifacts would allow investigators to accurately reconstruct the events, create a timeline, and analyze security incidents without impacting the running cluster. This is an important step towards enabling forensic readiness for Kubernetes, where cluster administrators proactively ensure the environments are prepared to collect and preserve evidence before a security incident occurs. |
| | | | |
| − | There is pidfd_open syscall which allows opening
| + | '''Links:''' |
| − | a special PID file descriptor. A user can send a signal to
| + | * https://github.com/checkpoint-restore/checkpointctl |
| − | the process (pidfd_send_signal syscall), wait for the process
| + | * [https://fosdem.org/2026/events/attachments/F9RANH-forensic-snapshots-in-kubernetes/slides/266249/fosdem_2_4dh73ni.pdf Investigating Security Incidents with Forensic Snapshots in Kubernetes] |
| − | (poll() on pidfd).
| + | * [https://www.cncf.io/reports/cloud-native-security-whitepaper/ Cloud Native Security Whitepaper] |
| − | | + | * [https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF Kubernetes Hardening Guide] |
| − | At the moment CRIU can't dump processes that have pidfd's opened.
| |
| | | | |
| − | '''Links:'''
| |
| − | * https://lwn.net/Articles/801319/
| |
| − | * https://lwn.net/Articles/794707/
| |
| − | * https://github.com/torvalds/linux/blob/v5.16/kernel/fork.c#L1877
| |
| − |
| |
| | '''Details:''' | | '''Details:''' |
| | * Skill level: intermediate | | * Skill level: intermediate |
| − | * Language: C | + | * Language: Go |
| | * Expected size: 350 hours | | * Expected size: 350 hours |
| − | * Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Christian Brauner <christian@brauner.io> | + | * Mentors: Lorena Goldoni <lory.goldoni@gmail.com>, Radostin Stoyanov <rstoyanov@fedoraproject.org>, Adrian Reber <areber@redhat.com> |
| − | * Suggested by: Alexander Mikhalitsyn <alexander@mihalicyn.com>
| |
| | | | |
| − | === Use eBPF to lock and unlock the network === | + | === Enabling Checkpoint/Restore of Rootless Containers === |
| − |
| |
| − | '''Summary:''' Use eBPF instead of external iptables-restore tool for network lock and unlock.
| |
| | | | |
| − | During checkpointing and restoring CRIU locks the network to make sure no network packets are accepted by the network stack during the time the process is checkpointed. Currently CRIU calls out to iptables-restore to create and delete the corresponding iptables rules. Another approach which avoids calling out to the external binary iptables-restore would be to directly inject eBPF rules. There have been reports from users that iptables-restore fails in some way and eBPF could avoid this external dependency.
| + | [https://rootlesscontaine.rs/ Rootless containers] are containers that can be created, run, and managed by unprivileged users. Container engines such as Podman natively support running containers in a rootless mode to improve security and usability. While checkpoint/restore functionality is already available for rootful containers and unprivileged checkpointing is possible with the <code>CAP_CHECKPOINT_RESTORE</code> capability, container engines do not yet support native checkpointing of containers running in rootless mode. This project aims to explore and address the remaining challenges required to enable unprivileged checkpoint/restore for rootless containers. |
| | | | |
| | '''Links:''' | | '''Links:''' |
| − | * https://www.criu.org/TCP_connection#Checkpoint_and_restore_TCP_connection | + | * https://github.com/checkpoint-restore/criu/pull/1930 |
| − | * https://github.com/systemd/systemd/blob/master/src/core/bpf-firewall.c | + | * https://github.com/torvalds/linux/commit/124ea650d3072b005457faed69909221c2905a1f |
| − | * https://blog.zeyady.com/2021-08-16/gsoc-criu | + | * https://src.fedoraproject.org/rpms/criu/pull-request/10#request_diff |
| | | | |
| | '''Details:''' | | '''Details:''' |
| | * Skill level: intermediate | | * Skill level: intermediate |
| − | * Language: C | + | * Language: C, Go |
| | * Expected size: 350 hours | | * Expected size: 350 hours |
| − | * Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Prajwal S N <prajwalnadig21@gmail.com> | + | * Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Adrian Reber <areber@redhat.com> |
| − | * Suggested by: Adrian Reber <areber@redhat.com>
| |
| | | | |
| | === Files on detached mounts === | | === Files on detached mounts === |
| Line 156: |
Line 113: |
| | * Language: C | | * Language: C |
| | * Expected size: 350 hours | | * Expected size: 350 hours |
| − | * Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com>, Prajwal S N <prajwalnadig21@gmail.com> | + | * Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com> |
| | * Suggested by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> | | * Suggested by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> |
| | | | |
| − | === Kubernetes operator for managing container checkpoints === | + | === Add support for SCM_CREDENTIALS / SCM_PIDFD and friends === |
| | + | |
| | + | '''Summary:''' Support for SCM_CREDENTIALS / SCM_PIDFD |
| | | | |
| − | '''Summary:''' Develop a Kubernetes operator that automates the management of container checkpoints
| + | SCM_CREDENTIALS and SCM_PIDFD are types of SCM (Socket-level Control Messages). They play a crucial role |
| | + | in systemd and many other user space applications. This project is about adding support for these |
| | + | SCMs to be properly saved and restored back with CRIU. There is an existing code in OpenVZ CRIU fork, |
| | + | see [1] and [2]. Goal would be first of all to properly port this code, cover with extensive tests and |
| | + | ensure that SCM_PIDFD / SO_PEERPIDFD are handled correctly. Also we expect to cover things like |
| | + | SO_PASSRIGHTS and SO_PASSPIDFD. |
| | | | |
| − | Container checkpointing has recently been introduced as an alpha feature in Kubernetes.
| + | There is some extra source of complexity here pidfds can be "stale" (see PIDFD_STALE in Linux kernel) |
| − | To enable this feature, the kubelet API was extended with an endpoint that enables the
| + | and we need to ensure that we properly cover those cases. |
| − | creation of checkpoints for individual containers. By default, all container checkpoints
| |
| − | are stored as tar archives in <code>/var/lib/kubelet/checkpoints</code> using the following
| |
| − | file name format: <code>checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tar</code>.
| |
| − | However, the current implementation does not provide a mechanism for limiting the number
| |
| − | of checkpoints, which may lead to filling up all existing disk space. This project aims to
| |
| − | develop a Kubernetes operator that automates the management of checkpoints and provides
| |
| − | a garbage collection mechanism to discard obsolete checkpoints.
| |
| | | | |
| | '''Links:''' | | '''Links:''' |
| − | * https://github.com/checkpoint-restore/checkpoint-restore-operator | + | * [1] openvz-criu https://bitbucket.org/openvz/criu.ovz/history-node/918653a0a343194385592d7b50b5bd7a8fbe1cc1/criu/sk-unix.c?at=hci-dev |
| − | * https://kubernetes.io/docs/reference/node/kubelet-checkpoint-api/
| + | * [2] openvz-criu https://bitbucket.org/openvz/criu.ovz/history-node/918653a0a343194385592d7b50b5bd7a8fbe1cc1/criu/sk-queue.c?at=hci-dev |
| − | * https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/ | + | * [3] Linux kernel https://github.com/torvalds/linux/commit/5e2ff6704a275be009be8979af17c52361b79b89 |
| − | * https://kubernetes.io/blog/2023/03/10/forensic-container-analysis/
| + | * [4] Linux kernel https://github.com/torvalds/linux/commit/c679d17d3f2d895b34e660673141ad250889831f |
| − | * https://github.com/kubernetes/kubernetes/pull/115888 | |
| − | * https://github.com/kubernetes/enhancements/issues/2008 | |
| | | | |
| | '''Details:''' | | '''Details:''' |
| − | * Skill level: intermediate | + | * Skill level: intermediate / advanced |
| − | * Language: Go | + | * Language: C |
| | * Expected size: 350 hours | | * Expected size: 350 hours |
| − | * Mentors: Adrian Reber <areber@redhat.com>, Radostin Stoyanov <rstoyanov@fedoraproject.org>, Prajwal S N <prajwalnadig21@gmail.com> | + | * Suggested by: Alexander Mikhalitsyn <alexander@mihalicyn.com> |
| − | * Suggested by: Adrian Reber
| + | * Mentors: Andrei Vagin <avagin@gmail.com>, Alexander Mikhalitsyn <alexander@mihalicyn.com> |
| | | | |
| | == Suspended project ideas == | | == Suspended project ideas == |
| Line 268: |
Line 223: |
| | * Skill level: beginner | | * Skill level: beginner |
| | * Language: Python | | * Language: Python |
| | + | |
| | + | === Add support for checkpoint/restore of CORK-ed UDP socket === |
| | + | |
| | + | '''Summary:''' Support C/R of corked UDP socket |
| | + | |
| | + | There's UDP_CORK option for sockets. As man page says: |
| | + | <pre> |
| | + | If this option is enabled, then all data output on this socket |
| | + | is accumulated into a single datagram that is transmitted when |
| | + | the option is disabled. This option should not be used in |
| | + | code intended to be portable. |
| | + | </pre> |
| | + | |
| | + | Currently criu refuses to dump this case, so it's effectively a bug. Supporting |
| | + | this will need extending the kernel API to allow criu read back the write queue |
| | + | of the socket (see [[TCP connection|how it's done]] for TCP sockets, for example). Then |
| | + | the queue is written into the image and is restored into the socket (with the CORK |
| | + | bit set too). |
| | + | |
| | + | '''Notes:''' |
| | + | |
| | + | We already had a couple (3) of tries for this problem: |
| | + | |
| | + | * UDP_REPAIR approach didn't succeed: https://lore.kernel.org/netdev/721a2e32-c930-ad6b-5055-631b502ed11b@gmail.com/, https://lore.kernel.org/netdev/?q=udp_repair |
| | + | * eBPF (CRIB) approach, socket queue iterator was not merged: https://lore.kernel.org/netdev/AM6PR03MB5848EDA002E3D7EACA7C6BDA99A52@AM6PR03MB5848.eurprd03.prod.outlook.com/, and we have general objections to CRIB approach https://lore.kernel.org/bpf/CAHk-=wjLWFa3i6+Tab67gnNumTYipj_HuheXr2RCq4zn0tCTzA@mail.gmail.com/ |
| | + | |
| | + | We still have one idea we didn't try, as UDP allows packets to be lost on the way on restore we can somehow mark the socket to drop all data before UNCORK. This way we don't really need to restore contents of UDP CORK-ed sockets send queue. |
| | + | |
| | + | '''Links:''' |
| | + | * https://github.com/checkpoint-restore/criu/issues/409 |
| | + | * https://github.com/criupatchwork/criu/commit/a532312 |
| | + | * [[Sockets]], [[TCP connection]] |
| | + | * [[https://groups.google.com/forum/#!topic/comp.os.linux.networking/Uz8PYiTCZSg UDP cork explained]] |
| | + | |
| | + | '''Details:''' |
| | + | * Skill level: intermediate (+linux kernel) |
| | + | * Language: C |
| | + | * Expected size: 350 hours |
| | + | * Mentors: Alexander Mikhalitsyn <alexander@mihalicyn.com>, Pavel Tikhomirov <ptikhomirov@virtuozzo.com>, Andrei Vagin <avagin@gmail.com> |
| | | | |
| | | | |