553
edits
Changes
mLine 3:
Line 3: − + − 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].+ Line 28:
Line 28: − − === Use eBPF to lock and unlock the network === − − '''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. − − '''Links:''' − * https://www.criu.org/TCP_connection#Checkpoint_and_restore_TCP_connection − * https://github.com/systemd/systemd/blob/master/src/core/bpf-firewall.c − * https://blog.zeyady.com/2021-08-16/gsoc-criu − − '''Details:''' − * Skill level: intermediate − * Language: C − * Expected size: 350 hours − * Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Prajwal S N <prajwalnadig21@gmail.com> − * Suggested by: Adrian Reber <areber@redhat.com> Line 103:
Line 85: − + − − − === Add support for arm64 Guarded Control Stack (GCS) === − − '''Summary:''' Support arm64 Guarded Control Stack (GCS) − − The arm64 Guarded Control Stack (GCS) feature provides support for − hardware protected stacks of return addresses, intended to provide − hardening against return oriented programming (ROP) attacks and to make − it easier to gather call stacks for applications such as profiling (taken from [1]). − We would like to support arm64 Guarded Control Stack (GCS) in CRIU, which means − that CRIU should be able to Checkpoint/Restore applications using GCS. − − This task should not require any Linux kernel modifications − but will require a lot of effort to understand Linux kernel and − glibc support patches. We have a good example of support for − x86 shadow stack [4] thanks to Mike. − − '''Links:''' − * [1] kernel support https://lore.kernel.org/all/20241001-arm64-gcs-v13-0-222b78d87eee@kernel.org − * [2] libc support https://inbox.sourceware.org/libc-alpha/20250117174119.3254972-1-yury.khrustalev@arm.com − * [3] libc tests https://inbox.sourceware.org/libc-alpha/20250210114538.1723249-1-yury.khrustalev@arm.com − * [4] x86 support (a great reference!) https://github.com/checkpoint-restore/criu/pull/2306 − − '''Details:''' − * Skill level: expert (a lot of moving parts: Linux kernel / libc / CRIU) − * Language: C − * Expected size: 350 hours − * Suggested by: Mike Rapoport <rppt@kernel.org> − * Mentors: Mike Rapoport <rppt@kernel.org>, Andrei Vagin <avagin@gmail.com>, Alexander Mikhalitsyn <alexander@mihalicyn.com> − − === Coordinated checkpointing of distributed applications === − − '''Summary:''' Enable coordinated container checkpointing with Kubernetes. − − Checkpointing support has been recently introduced in Kubernetes, where the − smallest deployable unit is a Pod (a group of containers). Kubernetes is often − used to deploy applications that are distributed across multiple nodes. − However, checkpointing such distributed applications requires a coordination − mechanism to synchronize the checkpoint and restore operations. To address this − challenge, we have developed a new tool called <code>criu-coordinator</code> − that relies on the action-script functionality of CRIU to enable synchronization − in distributed environments. This project aims to extend this tool to enable − seamless integration with the checkpointing functionality of Kubernetes. − − '''Links:''' − * https://github.com/checkpoint-restore/criu-coordinator − * https://lpc.events/event/18/contributions/1803/ − * https://sched.co/1YeT4 − * https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/ − − '''Details:''' − * Skill level: intermediate − * Language: Rust / Go / C − * Expected size: 350 hours − * Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Prajwal S N <prajwalnadig21@gmail.com> − * Suggested by: Radostin Stoyanov <rstoyanov@fedoraproject.org> Line 261:
Line 186: + + + + + + + + +
no edit summary
This page contains project ideas for upcoming Google Summer of Code.
This page contains project ideas for upcoming Google Summer of Code.
== Contacts ==
== Contact ==
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 ==
* Suggested by: Andrei Vagin <avagin@gmail.com>
* Suggested by: Andrei Vagin <avagin@gmail.com>
* Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Alexander Mikhalitsyn <alexander@mihalicyn.com>, Andrei Vagin <avagin@gmail.com>
* Mentors: Radostin Stoyanov <rstoyanov@fedoraproject.org>, Alexander Mikhalitsyn <alexander@mihalicyn.com>, Andrei Vagin <avagin@gmail.com>
=== Files on detached mounts ===
=== Files on detached mounts ===
* 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>
== Suspended project ideas ==
== Suspended project ideas ==
the queue is written into the image and is restored into the socket (with the CORK
the queue is written into the image and is restored into the socket (with the CORK
bit set too).
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:'''
'''Links:'''