Explore Projects

<p>This project will explore extending a new feature for the Performance Co-Pilot (PCP). PCP is an open source framework at the system level that monitors, analyze and retrieve information to understand system performance. It has a distributed architecture of agents, called Performance Metric Domain Agents (PMDA), that extract performance values from the desired environments or systems.</p> <p>Every agent (PMDA) reports to a centralized daemon called Performance Metric Collection Daemon or PMCD per host. Then, accessing any metric is as easy as sending a request to PMCDs. PCP has several client tools to help the final user understand the metrics. Finally, PCP also offers a good API to create an agent for any software.</p> <p>Coming back to the interest of the proposal, PCP also supports instrumentation. This is a way to enable user applications like Firefox to send metrics in execution time to the PMDA. In this scenario, Memory Mapped Values (MMV) are used to offer an extremely lightweight mechanism for instrumenting applications using shared memory. However, there is no support for metadata labels added since the newest v4, and hence the goal of this project: add label support for instrumentation.</p>

<p>BCC (BPF Compiler Collection) is a toolkit for efficient kernel tracing using eBPF (extended Berkeley Packet Filters). This project extends the current PCP BCC PMDA (Performance Metrics Domain Agent) by adding advanced BCC tools for system introspection and extends Vector with new widgets that expose these collected metrics. The collected metrics include block device I/O latency, latency of the open/read/write/fsync operations for ext4, xfs and zfs, per-process disk I/O time, TCP session and retransmit details, per-process TCP throughput, scheduler run queue latency and process details of new processes.</p>

The ticket-32159 (https://code.djangoproject.com/ticket/32519) originally requested a new feature to make Django provide generic database functions for manipulating JSON data on the database. Currently, in order to make partial updates to a JSONField, developers need tol oad model instance to the memory, modify JSONField data as objects, then call save() on the model instance, or write custom mapping for JSON functions as Func subclasses, and use them in update(). It would be better if Django has built-in support for doing partial JSONField updates more efficiently and more idiomatic to how developers can currently query JSONFields (i.e. with key transforms). In order to achieve that, this proposal intends to create an implementation for all databases supported that developers can use in order to update partial values of JSONField. This project aims to accomplish the problem by dividing it into two big parts: first, implement JSONSet and JSONRemove functions to allow partial updates to JSONField. Second, add support for key transforms in update() for JSONField to make it easier to use for developers. The project will be executed on creating JSONSet for SQLite, MySQL, PostgreSQL, Oracle first, then, create JSONRemove on same databases. After that, support for key transform on update() will be implemented.

The ZOO-Project is a solid WPS server able to handle services implemented in various different programming languages. The existing `ZOO-Kernel` supports C, C++, and JS implementations with the embedded version of the SpiderMonkey engine. With this project, the objective is to add support for NodeJS implementation of the `ZOO-Kernel`.

<p>Problems with memory management and array access by unchecked index or pointer introduce significant risk. Especially if it comes to the OS kernel. LDV project aims to improve Linux kernel and I want to correct issues with its environment model for kernel.</p> <p>As a results of my work I expect to find and fix a number of bug in one of the last kernel releases and improve LDV verification framework.</p>

The CernVM File System - CVMFS distributes LHC experiment software and conditions data to the LHC computing infrastructure. The client application is a read-only filesystem in userspace - a FUSE module, and may be sensitive to the different versions of linux kernel. Currently the integration test suite of CVMFS is run on different linux distributions and platforms and has coverage over a handful of kernel versions. The goal of this project is to increase this coverage and allow systematic testing for specific kernel versions and features.

<p>FreeBSD includes support for the kernel coverage sanitizer and undefined behaviour sanitizer, however support for the other sanitizers is missing. These are useful to find bugs while fuzzing the kernel.</p> <p>Port one or more of KASAN, KMSAN, and KTSAN to work in the FreeBSD kernel. Use the ported sanitizers with fuzzers (syzkaller or triforce) in order to find more memory vulnerabilities.</p>

<p>PCLm is a file format which is a light-weight subset of PDF which makes printing fast and efficient. It is streamable, i.e. can be printed page by page unlike PDFs, where PDF files require them to be loaded completely to the printer memory to be printed. Many cheap printers which are low on memory have this limitation of printing large PDF files, and here PCLm comes to the rescue. It also makes printing faster for high end printers. PCLm is also one of the standards for Wifi-Direct IPP printers. The project aims at enabling PCLm printing using cups and cups filters to PCLm supported printers.</p>

Currently, during an IKEv2 negotiation in Libreswan, each peer independently selects its authentication method without knowing what the other side supports, which can lead to SA establishment failures when peers are configured with multiple credentials. The goal of this project is to implement RFC 9593, which introduces the SUPPORTED_AUTH_METHODS notification to allow peers to announce their supported authentication methods during SA establishment, enabling Libreswan to adjust its authentication selection to a method both sides support. The deliverables include: New ipsec.conf configuration option. Modifications to emit and parse SUPPORTED_AUTH_METHODS notification across IKE_SA_INIT, IKE_INTERMEDIATE, and IKE_AUTH exchanges. Modifications to select the applicable authentication method based on the peer's announced capabilities. Additions to the test-suite.

When an IPsec-encrypted packet matches a trap policy in the kernel, the kernel notifies IKE daemon (Pluto) via an ACQUIRE Netlink message. Then Pluto identifies that to which connection does this packet belong to by doing a lookup through all the loaded connections. Currently this is done in O(N) time (scanning through all the connections and the connection with highest priority is choosen). This Project aims to reduce this by using a hashtable to find the connection by using a unqiue id which is passed to the kernel while installing the policy. A complication arises with Opportunistic IPsec. Multiple clones of the same template connection would inherit the same reqid, causing collisions both in the hashtable and in the kernel's SA binding. This is addressed by a global counter that assigns a guaranteed unique reqid to each clone of the template connection. The deliverables would be the following , 1.Unique id placed in the policy before sending it to the kernel. 2.ACQUIRE lookup path using the hashtable 3.Guaranteed unique reqid for opportunistic connection clones via a global counter. 4.Display of the reqid in the status as well. 5. New Tests for functional testing and updating the current testsuites.c

<p>Currently in IKEv2 , signature based authentication is per algorithm i.e., there is one for RSA digital signatures, one for DSS digital signatures (using SHA-1), and three for different ECDSA curves, each tied to exactly one hash algorithm.This design is cumbersome when more signature algorithms, hash algorithms, and elliptic curves need to be supported. RFC 7427 generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. Why is it important for libreswan and what problem does it solve? Currently Libreswan only supports RSA as the digitial signature authentication method. Therefore there exists a need for extension so that other methods, such as ECDSA or EDDSA can be used easily. Implementation of RFC 7427 would solve this problem as the new digital signature method is flexible enough to include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.) and add new methods (ECGDSA, ElGamal, etc.) in the future.</p>

<p>As of Linux kernel 4.15, nftables provides around 80% of the iptables feature-set. The idea is to work on implementing missing or new features on nftables.</p>

<p>As of Linux kernel 4.15, nftables provides around 80% of the iptables feature-set . I'm interested in working on project “Help by implementing missing features available in iptables as matches/targets in nftables.”</p>

<p>This project will be focused towards developing the missing features in nftables which are present in iptables. Features such as "-m time support" to allow data packets within certain time limit only , feature for matching the operating system version, and various tests for the existing features will be developed. Another primary focus will be to strengthen automated testing infrastructure for nftables as well as iptables.</p>

<p>The project involves work on adding support for RFC 5723 primarily. RFC 5723 proposes an extension to IKEv2 (Internet Key Exchange v2) that allows a client to re-establish an IKE Security Association with a gateway in a highly efficient manner, utilizing a previously established IKE SA. As this RFC might not be enough for the entire GSoC period, I will be working on further adding support for RFC 6023. RFC 6023 describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association to be created and authenticated without generating a Child SA.</p>

Parameterized tests allow the test logic and the data passed into the test to be specified separately. Such a feature would have wide applicability in Linux kernel testing. This project would entail designing a new API for defining parameterized tests, integrating parameterized tests into the KUnit reporting mechanism and converting some tests over to use this new API. We envision something similar to https://dzone.com/articles/junit-parameterized-test Adding the feature makes it easier to write Kunit tests that need to iterate over a set of values without duplicated code and with clear reporting of failures.

Problem statement: LLDB doesn't support module information in kernel space now. So in my proposal, I want to implement full kernel module support for kernel space. Method: To achieve this goal, I take kgdb as a reference and use the same method in in my project but use lldb as the backend (kld as the frontend). Deliverables: In brief, this project is to implement kernel module supply for lldb which the current lldb doesn't have. After this project, LLDB will support more kernel level debug information and thus facilitate kernel module development.

<p>One of the main challenges when creating custom Linux Kernel images is choosing the adequate drivers composing it, respectively to the target machine. We want all needed hardware functionalities to be enabled in software but also, either from performance of security reasons, the number of unnecessary modules to be minimal. The configuration system provides several methods of achieving this goal either by generating a default configuration or by letting the user select the needed drivers but, by far the most interesting solution is the automated disabling of unused modules with localmodconfig configuration.</p> <p>Linux Kernel backports are a solution to provide drivers released on newer kernels to be available for usage on older kernels. APIs and data structures change over time but drivers should provide functionality in any case.</p> <p>This project aims to add support for Linux Kernel backports in already existing configuration option, localmodconfig. The goal is to automatically determine the available functionalities not only from the drivers provided by the current kernel version but also from all the backported ones. Extensions of this project could fill some gaps in upstream Linux.</p>

<p>I would like to work implementing missing features in nftables. My plan is to work on the following subtasks: extending stateful object infrastructure, allow deletion of set elements from ruleset and rework netfilter logging.</p> <p>Another task that catches my attention is working on nftlb. I think my professional experience with load balancers and inverse proxies can be useful to develop this task successfully.</p>

<p>I am interested in the proposed tasks 1 and 4. These tasks are related with the implementation of nftables missing features and the completion of the iptables to nftables translation tool.</p>

<p>At the end of the project nftables’ feature set should very closely match that of iptables. This project has the objective of implementing all the missing features. These have been further split in sub-tasks 1.1 to 1.5 already by the netfilter core team, and this proposal draws upon them.</p> <p>Each of the sub-tasks is a self-contained feature. Sub-tasks 1.1, 1.2 and 1.4 should be completed in a week each. However I have allocated a bit more than that for incidentals. I expect sub-task 1.3 to take a bit more than a week.</p> <p>There is an additional sub-task 1.6 defined (“Rework Netfilter logging”). I do not get into the details of this as that requires a more thorough investigation. The ability to activate to nf_tables loggers at the same time seems to go beyond the scope of nf_tables itself. The last 3 weeks of August have been reserved in the timeline to investigate the feasibility of this sub-task, and implement it, if feasible.</p>

<p>I would like to work in the, currently halted, development of nft-sync tool.</p>

<p>I'm interesting in two of the proposed tasks. I'm talk about how I would work on these and my experience with netfilter.</p>