DEV Community: Kushagra Srivastava

My Google Summer of Code Journey: Part 3

Kushagra Srivastava — Sun, 21 Sep 2025 07:31:58 +0000

Time for a technical deep dive into my project.

In the previous blog, I gave an overview of my journey, mostly keeping it noob-friendly and showing what a realistic journey from the preparation, ideation, acceptance, to the completion looks like.

This would be my last article about my GSoC journey. In this article, I’ll be going down into the technical depths of my project. You may or may not find it interesting, but if OS, kernels, concurrency, memory management (and mismanagement too) tickle your brain, do stick around. I’ll post more technical and non-technical content in the upcoming blogs.

Overview of my project.

As mentioned previously, I completed GSoC’25 in The FreeBSD Project. FreeBSD, as you might know, is a Unix-like operating system known for its stability, performance, and security. My project was medium-sized (175 hours), made of two small-sized projects, namely (i) mac_do(4) improvements and (ii) mdo(1) improvements.

mac_do(4) improvements

mac_do(4) is a kernel security module that can enable controlled process credentials transitions, such as changing the user IDs or group IDs to particular values. Processes that make such requests and are authorized mac_do(4) do not need to be root or spawned from an executable with the setuid bit. It overcomes the fundamental security issues of programs like sudo or doas.

I had two objectives for this module:

Allow mac_do(4) to support a list of executables authorized to request credential transitions, and enable the ability to configure this list in jail(8)s.
Allow mac_do(4) to support authorizing credential transitions outside the setcred(2) system call, i.e., implementing support for traditional system calls like setuid(2), setgid(2), setgroups(2), etc.

Objective 1: Per-jail configurable list for executable paths

One major drawback of the original mac_do(4) module was that it was hardcoded to only allow processes that spawned from /usr/bin/mdo. Any other application wishing to take advantage of the credential transition capabilities would be out of luck due to this rigidity. As with the credential transition rules, it was my responsibility to make this configurable on a per-jail basis.

The existing infrastructure was built around managing rules - the credential transition specifications. However, I needed to store and manage both rules and executable paths together. The original structure was simple:

struct rules {
    char        string[MAC_RULE_STRING_LEN];
    struct rulehead head;
    volatile u_int  use_count __aligned(CACHE_LINE_SIZE);
};

This needed to evolve into something more comprehensive that could handle multiple types of configuration data while maintaining the same lifetime management and concurrency guarantees.

Introducing struct conf: A Unified Configuration Container

The solution was to create a new struct conf that would encapsulate both rules and executable paths:

struct exec_paths {
    char exec_paths_str[EXEC_PATHS_MAXLEN];
    char exec_paths[MAX_EXEC_PATHS][PATH_MAX];
    int exec_path_count;
};

struct conf {
    struct rules rules;
    struct exec_paths exec_paths;
    volatile u_int use_count __aligned(CACHE_LINE_SIZE);
};

This design adds the new exec_paths functionality while preserving the original struct rules. In order to ensure atomic updates of both rules and executable paths, the reference counting mechanism that was previously at the rules level now functions at the configuration level.

Memory Management and Lifetime Challenges

One of the trickiest aspects was migrating all the lifetime management logic from rules to conf. The original code had functions like:

static struct rules *alloc_rules(void)
static void toast_rules(struct rules *const rules)  
static void hold_rules(struct rules *const rules)
static void drop_rules(struct rules *const rules)

These all needed to be reimplemented for the new configuration structure:

static struct conf *alloc_conf(void)
static void drop_conf(struct conf *const conf)
{
    if (refcount_release(&conf->use_count)) {
        toast_rules(&conf->rules);  // Clean up embedded rules
        free(conf, M_MAC_DO);       // Free the container
    }
}

The key insight was that struct conf now owns the lifetime of the embedded struct rules, so the cleanup process needed to handle the nested structure properly.

Deep vs Shallow Copying: A Critical Distinction

I ran into a minor but significant copying problem when implementing configuration inheritance and updates. The dynamically allocated arrays (uids and gids) in the struct rules are not easily copied using bcopy(). I had to put deep cloning functions into practice:

static void
clone_rules(struct rules *dst, struct rules *const src)
{
    // Copy the basic structure
    strlcpy(dst->string, src->string, sizeof(dst->string));
    STAILQ_INIT(&dst->head);

    // Deep copy each rule with its dynamic arrays
    STAILQ_FOREACH(src_rule, &src->head, r_entries) {
        dst_rule = malloc(sizeof(*dst_rule), M_MAC_DO, M_WAITOK | M_ZERO);
        bcopy(src_rule, dst_rule, sizeof(*dst_rule));

        if (src_rule->uids_nb > 0) {
            dst_rule->uids = malloc(sizeof(*dst_rule->uids) * src_rule->uids_nb,
                M_MAC_DO, M_WAITOK);
            bcopy(src_rule->uids, dst_rule->uids,
                sizeof(*dst_rule->uids) * src_rule->uids_nb);
        }
        // Similar for gids...
    }
}

This was required because jail configuration inheritance meant that a jail had to inherit from its parent, but as an independent copy rather than a shared reference, when it didn't specify its own rules or paths.

Concurrency and Prison Lock Management

The kernel environment requires careful attention to locking and concurrency. The existing infrastructure used prison locks to protect jail-specific data, and I had to ensure this remained consistent:

static struct conf *
find_conf(struct prison *const pr, struct prison **const aprp)
{
    struct prison *cpr, *ppr;
    struct conf *conf;
    cpr = pr;
    for (;;) {
        prison_lock(cpr);
        conf = osd_jail_get(cpr, osd_jail_slot);
        if (conf != NULL)
            break;
        prison_unlock(cpr);
        ppr = cpr->pr_parent;
        MPASS(ppr != NULL); // prison0 always has config
        cpr = ppr;
    }
    *aprp = cpr;
    return (conf);
}

The caller receives both the configuration and the prison that holds it, and must unlock that prison when done. This pattern ensures that the configuration remains valid for the duration of use while preventing deadlocks.

Jail Parameter Integration

Adding the new executable paths required extending the jail parameter system. This meant implementing new sysctl handlers and jail management hooks:

static int
mac_do_sysctl_exec_paths(SYSCTL_HANDLER_ARGS)
{
    char *const buf = malloc(EXEC_PATHS_MAXLEN, M_MAC_DO, M_WAITOK);
    struct conf *conf;
    struct prison *pr;

    conf = find_conf(td_pr, &pr);
    strlcpy(buf, conf->exec_paths.exec_paths_str, EXEC_PATHS_MAXLEN);
    prison_unlock(pr);

    // Handle updates...
}

SYSCTL_PROC(_security_mac_do, OID_AUTO, exec_paths,
    CTLTYPE_STRING | CTLFLAG_RW | CTLFLAG_PRISON | CTLFLAG_MPSAFE,
    0, 0, mac_do_sysctl_exec_paths, "A",
    "Colon-separated list of allowed executables");

Transforming check_proc(): From Static to Dynamic

The original check_proc() function was trivial; just a hardcoded string comparison:

// Original version
error = strcmp(path, "/usr/bin/mdo") == 0 ? 0 : EPERM;

The new version needed to dynamically check against the jail's configured executable paths:

static int
check_proc(void)
{
    char *path, *to_free;
    int error = EPERM;

    if (vn_fullpath(curproc->p_textvp, &path, &to_free) != 0)
        return (EPERM);

    struct conf *conf;
    struct prison *pr;
    conf = find_conf(curproc->p_ucred->cr_prison, &pr);

    for (int i = 0; i < conf->exec_paths.exec_path_count; i++) {
        if (strcmp(conf->exec_paths.exec_paths[i], path) == 0) {
            error = 0;
            break;
        }
    }

    prison_unlock(pr);
    free(to_free, M_TEMP);
    return (error);
}

This change enables per-jail customization of authorized executables while maintaining the security model.

OSD Integration and Default Configuration

The jail lifecycle hooks had to be updated to accommodate the new configuration structure for the Object-Specific Data (OSD) framework integration. The default configuration needed to provide backward compatibility:

static void
set_default_conf(struct prison *const pr)
{
    struct conf *const conf = alloc_conf();
    // Maintain backward compatibility
    strlcpy(conf->exec_paths.exec_paths_str, "/usr/bin/mdo", EXEC_PATHS_MAXLEN);
    strlcpy(conf->exec_paths.exec_paths[0], "/usr/bin/mdo", PATH_MAX);
    conf->exec_paths.exec_path_count = 1;
    set_conf(pr, conf);
}

The Result: Flexible, Per-Jail Configuration

mac_do(4) was successfully transformed from a rigid, hardcoded system to one that is completely configurable. Now, administrators can specify a list of executable paths for various jails:

# System-wide configuration
sysctl security.mac.do.exec_paths="/usr/bin/mdo:/usr/local/bin/custom_tool"
# Per-jail configuration  
jail -c name=myjail mac.do.exec_paths="/usr/bin/mdo:/usr/local/bin/jail_specific_tool"

Objective 2: Implementing support for traditional credentials changing syscalls

One major drawback of the original mac_do(4) implementation was that it could only approve credential transitions that were requested using the specific setcred(2) system call. Traditional POSIX system calls such as setuid(2), setgid(2), and setgroups(2) are usually used in real-world applications, even though setcred(2) offers complete credential management. In order to intercept and authorize these common credential-changing functions, I had to extend mac_do(4).

The Infrastructure Challenge

The existing code already had a sophisticated infrastructure for handling setcred(2) through the MAC framework:

struct mac_do_data_header {
    size_t allocated_size;
    size_t size;
    int priv;           // Privilege identifier
    struct conf *conf;  // Configuration to apply
};

struct mac_do_setcred_data {
    struct mac_do_data_header hdr;
    const struct ucred *new_cred;
    u_int setcred_flags;
};

This infrastructure uses per-thread Object-Specific Data (OSD) to pass information between MAC hooks safely, handling concurrency and memory management automatically. The challenge was extending this pattern to handle multiple different system calls.

Creating Specialized Data Structures

I created dedicated data structures for different categories of system calls:

struct mac_do_setuid_data {
    struct mac_do_data_header hdr;
    uid_t target_uid;
};

struct mac_do_setgid_data {
    struct mac_do_data_header hdr;
    gid_t target_gid;
};

struct mac_do_setgroups_data {
    struct mac_do_data_header hdr;
    int ngroups;
    gid_t *groups;
};

Each structure shares the common header but carries syscall-specific data needed for authorization decisions.

Expanding the Privilege Grant Logic

The original mac_do_priv_grant() function handled only PRIV_CRED_SETCRED. I extended it to handle all the new privilege types:

static int
mac_do_priv_grant(struct ucred *cred, int priv)
{
    switch (priv) {
        case PRIV_CRED_SETCRED: {
            // Original setcred logic
            break;
        }

        case PRIV_CRED_SETUID:
        case PRIV_CRED_SETEUID:
        case PRIV_CRED_SETREUID:
        case PRIV_CRED_SETRESUID: {
            struct mac_do_setuid_data *data = fetch_data();
            // Check rules against target UID
            STAILQ_FOREACH(rule, &rules->head, r_entries)
                if (rule_applies(rule, cred)) {
                    error = rule_grant_user(rule, cred, data->target_uid);
                    if (error != EPERM) break;
                }
            return (error);
        }

        case PRIV_CRED_SETGROUPS: {
            struct mac_do_setgroups_data *data = fetch_data();
            // Check rules against target groups
            STAILQ_FOREACH(rule, &rules->head, r_entries)
                if (rule_applies(rule, cred)) {
                    error = rule_grant_setgroups(rule, cred, 
                            data->ngroups, data->groups);
                    if (error != EPERM) break;
                }
            return (error);
        }
        // Similar cases for GID syscalls...
    }
}

Implementing the Hook Triplets

Each system call requires three MAC hooks: enter, check, and exit. I implemented these for all nine syscalls (setuid, seteuid, setreuid, setresuid, setgid, setegid, setregid, setresgid, setgroups). The pattern is consistent:

static void
mac_do_setuid_enter(void)
{
    // Set up per-thread data if authorized executable
    if (do_enabled == 0 || check_proc() != 0)
        return;

    conf = find_conf(curproc->p_ucred->cr_prison, &pr);
    hold_conf(conf);

    data = alloc_data(data, sizeof(*data));
    set_data_header(data, sizeof(*data), PRIV_CRED_SETUID, conf);
}

static int
mac_do_check_setuid(struct ucred *cred, uid_t uid)
{
    // Capture the target UID for privilege checking
    data->target_uid = uid;
    return (0);
}

static void
mac_do_setuid_exit(void)
{
    // Clean up per-thread data
    clear_data(data);
}

Handling Complex Parameter Logic

Some syscalls like setreuid(2) and setresuid(2) can take multiple UIDs where -1 means "don't change". I had to implement logic to determine the effective target:

static int
mac_do_check_setreuid(struct ucred *cred, uid_t ruid, uid_t euid)
{
    if (euid != (uid_t)-1)
        data->target_uid = euid;      // Effective UID takes priority
    else if (ruid != (uid_t)-1)
        data->target_uid = ruid;      // Fall back to real UID
    else
        data->target_uid = cred->cr_uid;  // No change requested
    return (0);
}

Adapting Group Authorization Logic

The setgroups(2) syscall required special attention since it operates differently from setcred(2). I created rule_grant_setgroups() that works directly with the group array:

static int
rule_grant_setgroups(const struct rule *const rule,
    const struct ucred *const old_cred, const int ngroups, 
    const gid_t *const groups)
{
    // Check each group in the new groups array
    for (int new_idx = 0; new_idx < ngroups; ++new_idx) {
        const gid_t gid = groups[new_idx];
        bool may_accept = false;

        // Apply same rule logic as setcred supplementary groups
        // but work directly with the groups array
    }
    return (0);
}

MAC Framework Integration

Beyond the module changes, this required extending the MAC framework itself. I added new MAC policy entry points in the kernel:

// In mac_policy.h
typedef void (*mpo_cred_setuid_enter_t)(void);
typedef int (*mpo_cred_check_setuid_t)(struct ucred *cred, uid_t uid);
typedef void (*mpo_cred_setuid_exit_t)(void);
// ... and similar for all other syscalls

// In kern_prot.c - example for setuid()
MAC_CRED_SETUID_ENTER();
error = priv_check_cred(oldcred, PRIV_CRED_SETUID);  
MAC_CRED_CHECK_SETUID(newcred, uid);
if (error) {
    MAC_CRED_SETUID_EXIT();
    return (error);
}
// ... perform the actual credential change
MAC_CRED_SETUID_EXIT();

Finally, I registered all the new hooks in the MAC policy operations structure:

static struct mac_policy_ops do_ops = {
    // Original hooks
    .mpo_cred_setcred_enter = mac_do_setcred_enter,
    .mpo_cred_check_setcred = mac_do_check_setcred,
    .mpo_cred_setcred_exit = mac_do_setcred_exit,

    // New UID syscall hooks
    .mpo_cred_setuid_enter = mac_do_setuid_enter,
    .mpo_cred_check_setuid = mac_do_check_setuid,
    .mpo_cred_setuid_exit = mac_do_setuid_exit,

    .mpo_cred_seteuid_enter = mac_do_seteuid_enter,
    .mpo_cred_check_seteuid = mac_do_check_seteuid,
    .mpo_cred_seteuid_exit = mac_do_seteuid_exit,

    // ... and similar triplets for all other syscalls
};

The Result: Comprehensive Coverage

This implementation allows credential transitions from any standard POSIX credential-changing function, not only setcred(2), to be authorized by mac_do(4). With mac_do(4) control, applications can now be deployed without setuid bits and still execute the required privilege escalations. All syscalls use the same rule syntax; for example, uid=1000>uid=0 will allow transitions to root through setuid(2), seteuid(2), or any other suitable syscall. Per-thread data isolation, appropriate cleanup on exceptions, and uniform rule application across all code paths are among the safety guarantees that the infrastructure upholds, just like the original setcred(2) implementation.

mdo(1) improvements

mdo(1) is the companion userland program to mac_do(4) used for changing credentials by requesting mac_do(4) using the novel setcred(2) system call. Initially, it could only change to a target user.

I had two objectives for this program:

Extend mdo(1) to allow setting the primary group and secondary groups list, allowing explicit UID and GID overrides, and enabling users to have fine-grain control over the credentials.
Allowing users to print the target part of mac_do(4) rules corresponding to the requested transition.

Objective 1: From Simple User Switching to Fine-Grained Credential Control

The original mdo(1) utility was quite basic; it could switch to a different user and either keep the current groups or replace them entirely with the target user's groups. The interface was minimal:

while ((ch = getopt(argc, argv, "u:i")) != -1) {
    switch (ch) {
    case 'u':
        username = optarg;
        break;
    case 'i':
        uidonly = true;  // Keep current groups
        break;
    }
}

The enhanced version now supports a comprehensive set of options for precise credential control:

# Basic usage remains the same
mdo -u alice id

# But now you can do much more:
mdo -u bob -g wheel -G staff,operator /bin/sh
mdo -u alice -s @,+wheel,+operator /usr/bin/id  
mdo --ruid 1002 --svgid 1003 --egid 1004 /bin/id

Managing usernames and numeric IDs correctly was one of the initial difficulties. This logic was disjointed and a little brittle in the original code. I developed specific functions for parsing and checking stuff.

static uid_t parse_user_pwd(const char *s, struct passwd **pwd);
static uid_t parse_user(const char *s);
static gid_t parse_group(const char *s);
static gid_t *realloc_groups(gid_t *array, size_t new_count);
static int id_cmp(const size_t *id_a, const size_t *id_b);
static size_t remove_duplicates(gid_t *array, size_t count);
static size_t remove_groups_from_array(gid_t *array, size_t count, const gid_t *remove_list, size_t remove_count);

Then in the main() function, I started handling each option, starting with the user-related options, which were more straightforward than the group handling. I performed the relevant checks related to the absence of -i, -g or any explicit GID override, then moved on to setting the explicit UID options too. The most complex part was implementing the group management features. The new tool needed to support three different ways of specifying groups:

1. Exact Group Lists (-G): Specify precisely which supplementary groups to have:

mdo -u bob -G wheel,staff,operator /bin/sh

2. Group Modifications (-s): Add/remove groups with a powerful syntax:

mdo -u alice -s @,+wheel,+operator,-staff /usr/bin/id

3. Smart Defaults: Inherit from the user database or the current process as appropriate.

The group modification syntax was particularly interesting to implement:

while ((tok = strsep(&p, ",")) != NULL) {
    if (*tok == '\0')
        continue;
    if (tok[0] == '@')  {
        if (i > 0)
            errx(EXIT_FAILURE, "'@' must be the first token in -s option");
        supp_groups_reset = true;  // Start with empty group list
    } else if (tok[0] == '+' || tok[0] == '-') {
        bool is_add = tok[0] == '+';
        const char *gstr = tok + 1;
        gid = parse_group(gstr);
        if (is_add) {
            supp_groups_add = realloc_groups(supp_groups_add, add_count + 1);
            supp_groups_add[add_count++] = gid;
        } else {
            groups_supp_del = realloc_groups(groups_supp_del, rem_count + 1);
            groups_supp_del[rem_count++] = gid;
        }
    }
}

Managing Dynamic Arrays and Memory:

Working with supplementary groups meant dealing with dynamic arrays that could grow and shrink. I needed utility functions for array manipulation:

static size_t
remove_duplicates(gid_t *array, size_t count)
{
    size_t j = 0;
    if (count <= 1)
        return (count);
    qsort(array, count, sizeof(gid_t), gid_cmp);
    // Remove consecutive duplicates
    for (size_t i = 1; i < count; i++) {
        if (array[i] != array[j]) {
            array[++j] = array[i];
        }
    }
    return (j + 1);
}

Much more intricate decision trees had to be handled by the updated version. For instance, explicitly specifying users is incompatible with the -k flag (keep current user):

if (start_from_current_user && (username_provided || ruid_str != NULL ||
    svuid_str != NULL || euid_str != NULL))
    errx(EXIT_FAILURE, "-k incompatible with -u or specifying all users");

And when we don't have a passwd entry but need to set groups, we must have explicit group specifications:

if (!start_from_current_groups && pw == NULL && primary_group == NULL &&
    (rgid_str == NULL || svgid_str == NULL || egid_str == NULL))
    errx(EXIT_FAILURE,
        "must specify primary groups or a user with an entry in the password database");

Objective 2: Implementing --print-rule.

The only thing I had to do here was add this at the end:

if (print_rule) {
    fprintf(stdout, "uid=%u,gid=%u,", wcred.sc_uid, wcred.sc_gid);
    if (setcred_flags & SETCREDF_SUPP_GROUPS && wcred.sc_supp_groups_nb > 0) {
        fprintf(stdout, "+gid=");
        for (size_t i = 0; i < wcred.sc_supp_groups_nb; i++) {
            if (i > 0)
                fprintf(stdout, ",");
            fprintf(stdout, "%u", wcred.sc_supp_groups[i]);
        }
    }
    fprintf(stdout, "\n");
    exit(0);
}

Conclusion

I tried to fit as many technicalities as I could include in a small article, but truth be told, the actual project was way more involved than what I could show here. Those unending kernel crashes, VM restarts, hair-tearing moments while debugging. With every problem I tried to solve, it felt like how little I knew, and I had to learn everything on the go. With this, My Google Summer of Code Journey comes to an end. Hope you liked it!

TL;DR

Go and read it.

My Google Summer of Code Journey: Part 2

Kushagra Srivastava — Tue, 16 Sep 2025 08:53:24 +0000

From failing to cracking to passing GSoC 2025

In the previous blog, I shared my story of dreaming, attempting, and failing GSoC. This one is about learning from my earlier mistakes, applying my knowledge, getting accepted into GSoC, and eventually passing it. I will discuss the details and technicalities in Part 3 of this blog.

Before getting accepted (Oct 2024 - Apr 2025)

It is October 2024, and I’m in my pre-final year. Over the summer, I had built some projects (more about them in the upcoming blogs), and I’d decided I wanted to dive into lower-level areas of software development: operating systems, kernels, networking, virtualization, and graphics. I started learning about system calls, kernel development, Linux internals, drivers, etc., but couldn’t go very deep because of time and college work.

By the end of this semester (November), I had three organizations in my mind: The FreeBSD Project (OS), Haiku (OS), and FFmpeg (graphics). Now there is a reason for this. These orgs have a good track record of returning to GSoC each year, and their project ideas are posted on the ideas page all year round.

Now,

Haiku was written in C++, and the community wasn’t active.
FFmpeg was tempting (filters, encoders, Vulkan, SIMD), but my college senior, who did GSoC 2024 with them, strictly warned me against it due to poor documentation and community support.
That left FreeBSD, which I eventually picked by January 2025. (Lucky choice, since Haiku didn’t even make it to GSoC 2025.)

Now things were different this time. I chose an organization that is not crowded, unlike most webdev organizations, like Rocket.Chat, so I did not have to worry about much competition. This is an advantage of choosing a tech stack like this (C, OS, kernels, etc).

I went through the idea list and chose two projects to make proposals for:

mac_do(4) and mdo(1) improvements (kernel security module)
adding compressed qcow2 images creation using mkimg(1) (userland tool)

This time, I didn’t contribute at all (which was a risky move), but I immediately started contacting mentors once orgs were announced. I read the FreeBSD Handbook, studied some code, and pestered ChatGPT endlessly, constantly learning new things about the things required to work on the project. I got replies from both mentors, answering all my queries.

By March 2025, I was writing proposals for both projects simultaneously. It took me 23 days. I sent drafts to both mentors; one replied (kernel project) with some corrections, but said it looked solid. I was more confident about the userland project; it felt easier than kernel-level work. Unlike the previous year, this time I focused well on the proposals. The mentor and I exchanged emails for a few days before I submitted my final proposal on April 8, 2025.

Getting Accepted and Community Bonding (May 2025)

May 8, 2025, it’s 11:30 pm. No email.
11:35 pm. Still nothing.
11:42 pm. I got an email. I got rejected.

I was devastated; those countless hours of learning, understanding deep concepts, and creating proposals, gone. I was shocked because I was pretty confident, but then, as I was accepting my reality that I wasn’t cut out for GSoC, I got an email saying, “GSoC 2025: Congratulations, your proposal with The FreeBSD Project has been accepted!”. (The previous mail was for the other proposal that I submitted.)

I was ecstatic! A dream of seven years is finally coming true! I was hoping that the other project got selected, but at this point, it didn’t matter. I got selected for the “mac_do(4) and mdo(1) improvements” project.

During the community bonding period, nothing much happened because my mentor was away for work, and I was chilling too, not putting much effort into learning more. This was a mistake that came back to bite me during the coding period.

The Coding Period (Jun 2025 - Aug 2025)

June

My mentor and I connect on Signal. We have our first call to discuss our first task on the mac_do(4) kernel security module (the most difficult of the three tasks). And I was blank. What I wrote in my proposal only covered half of what was required. When the remaining details were being discussed, I didn’t know what to do or how to do it.

Anyway, I started coding. After about three weeks, I opened a PR and took a break for a few days, while my mentor reviewed it, and I came to know that whatever I had coded was complete and utter BS (well, not exactly, but…). I had to refactor my code from scratch, rewrite most of the functions, and manage memory well while handling the kernel-level concurrency of the main struct conf that I had to work on. This task was difficult due to these concepts. Debugging was brutal; every memory management mistake risked a kernel panic and VM restart. I refactored my code for the rest of the month and opened a new PR.

July

I switched to the second task on the mdo(1) tool. This was a relatively easy task. I had to mainly add new functionalities and features to the existing minimal tool. This part felt chill, and after about ten days or so, I opened a PR for this task.

My mentor gave an extensive review of the first task’s PR. Issues: memory leaks, use-after-free bugs, and jail mutex problems causing crashes. It seems a bit easier now, but just a few months back from today, I did not know what the hell I was doing. I had my mid-term evaluations that month, and thankfully, I passed. When I had my first call with my mentor in June, I was confident I would fail the mid-term evals. Anyway, I worked on the issues pointed out by my mentor, and July ended.

August

By now, 75% of the work was done on both tasks. The second task was almost complete, but the first task haunted me with a mysterious bug. Days and nights blurred as I tried to find it. I was afraid there was less time left since the third task hadn’t even been touched. I found the bug, fixed it, and immediately started working on the new task.

My mentor and I discussed the third task, and I was blank again. This time, apparently, the task wasn’t difficult, but I was just not exposed to the files that he pointed out during the call, which I missed during my proposal. Anyway, I did that task in about two days, working about sixteen hours a day, because significant work remained, and only ten days remained until the end. In the final week, I wrapped up everything, added ATF tests, and fixed last-minute issues just before the deadline.

Looking Back

All in all, this was a wild experience for me. Coming from a not-so-low-level programming background, to completing a project that involved knowledge about deep kernel-level concurrency, it was a ride. This journey was an extremely fulfilling experience, and I felt a 95% expansion of my brain after completing it.

And yes, I passed my final evaluations and successfully completed Google Summer of Code 2025.

What did I learn?

Orgs can skip GSoC some years, even with a long track record.
I got lucky: I picked a project way beyond my league, and learned things the hard way.
Maybe don’t slack off during the Community Bonding period.

I’m genuinely thankful to my mentor, Olivier Certner, for being patient with my endless mistakes and questions, and to The FreeBSD Project for giving me the opportunity to work on something way beyond my comfort zone. Without their support, I wouldn’t have made it through.

My Google Summer of Code Journey: Part 1

Kushagra Srivastava — Mon, 15 Sep 2025 14:47:21 +0000

My first failed attempt at GSoC (The history)

It’s 2018, I’m in class 10th, scrolling YouTube, and I stumble upon Google Summer of Code. I used to watch many videos related to software development back then. I am immediately fascinated by the program (initially, honestly, due to the crazy $5500 stipend it used to offer). I was bummed that students under 18 could not participate, but I decided I had to do it at least once during my undergrad.

Fast forward to early 2023, my 2nd year of B.Tech. This was the first time I actually tried to understand what it takes to get accepted into GSoC. I started watching videos about GSoC, checking out organizations, digging into old proposals online, and getting overwhelmed by the details and technicalities mentioned in those proposals. At this point, I was wading here and there, without any clear goals for my target organization, my choice of tech stack, or even whether I wanted to do GSoC. I didn’t have the programming and soft skills back then to even think about cracking GSoC (I will talk more about my technical journey in the upcoming blogs).

Moving on to December 2023, I was into Full-stack Web Development. Again, I binged too many videos on YouTube about “how to crack GSoC”. But this time, my motivation had shifted. It wasn’t the stipend anymore, but the love for open-source (more about it in the upcoming blogs). I genuinely wanted to fulfill my dream from 5 years ago, contribute something meaningful to the organizations, and put my skills to good use.

Here’s the problem, though: I watched too many videos that were catered to the Indian audience. The problem with that is that most of these videos talk about cracking GSoC as if it is some competition (JEEfication of GSoC), but very few of them actually talk about the fundamentals that must be focused on to get accepted in GSoC; most talk about the tips and tricks. They say you must start very early (by September-October) to get into GSoC, which I feel is untrue. I have seen many people around me getting accepted in just two months. I’d be lying if I said I did not use some of these “tips and tricks.” However, if you focus on the fundamentals, show that you are worth something, and communicate effectively, you will almost definitely be accepted.

So anyway, I started shortlisting organizations according to my tech stack (It was MERN, xD. I didn’t have much choice because I only knew Game Development apart from that). I came across this golden website: gsocorganizations.dev. I selected all the years from 2018 to 2023, ensuring these organizations will return to GSoC in 2024 (not always, but yeah). I selected the relevant technologies, topics, and categories in the filter. I had a list of organizations at this point, namely Rocket.Chat, Zulip, Sugarlabs, and Oppia. I went with Rocket.Chat.

The thing I liked about Rocket.Chat was that their communication system was top-notch. It used to happen on the Rocket.Chat application itself, and they created a channel for each of the project ideas that they listed. They were extremely welcoming to the community. By February 2024, I attended their meetings to learn how to create a Rocket.Chat app. In March, I started contributing to their projects, mainly to EmbeddedChat. I contributed because:

Every YouTube guru said that you need to have at least 2-3 months of contributions to the organization in which you want to get accepted. I had only 2-3 weeks left before the deadline.
Rocket.Chat created a leaderboard that showed the number of open PRs, merged PRs, and issues you’ve opened. You can check it out at gsoc.rocket.chat.

I had mixed feelings about the leaderboard because it felt unnecessary. Anyway, I contributed mostly small to medium-sized issues, opened about 7 PRs, and 4 got merged, bringing my ranking to 15 out of 200 contributors. Felt okay about it, but not great, because the top 5 people had like 15 merged PRs and were bound to get accepted.

That year, they had a bunch of AI/LLM integration project ideas. I picked “Chat thread summarizer using AI”. And here’s where I messed up: I didn’t use my time wisely. I focused on contribution too much and didn’t actually work on my proposal until the very last day (I know it's foolish).

April 2, 2024, I woke up early and started building my proposal. Some ideas and implementation details were discussed in this project’s channel, but I barely talked to the potential mentor about the details, and I just started writing independently. I wrote whatever I knew could be relevant to the project, why it could be helpful, the implementation details, the timeline, the future work, etc. Honestly, the proposal wasn’t strong. I missed a lot of details.

Meanwhile, this other guy who joined in March skyrocketed to rank 3 in just days and picked the same project idea. Looking at his contributions, I already knew he was going to beat me. Still, I wanted to at least finish and submit. At 6:30 pm (deadline was 11:30 pm), I submitted my proposal and called it a day.

It’s May 1, 2024, and the results are announced. I knew I wasn’t going to get selected. And guess what… I did not get selected.

That same guy got selected. I reached out to him and asked if he’d share his proposal. He did. And I was blown away. For what seemed like a small project, he had written a super-detailed proposal, covering every corner, but he was right in doing so, trying not to miss any details. I learnt a lot from his proposal and this journey. I just moved on to improve more.