Tag Archives: Linux

Bounds Checking Flexible Array Members

Buffer overflows are the cause of many security issues, and are a persistent thorn in programmers' sides. C is particularly susceptible to them. The advent of sanitizers mitigates some security issues by automatically inserting bounds checking, but they're not able to do so in all situations—in particular for flexible array members, because their size is known only at runtime.

The size of a flexible array member is typically opaque to the compiler. The alloc_size attribute on malloc() may be used for bounds checking flexible array members within the same function as the allocation. But the attribute's information isn't carried with the allocated object, making it impossible to perform bounds checking elsewhere.

To mitigate this drawback, Clang and GCC are introducing1 the counted_by attribute for flexible array members.


Specifying a flexible array member's element count

The number of elements allocated for a flexible array member is frequently stored in another field within the same structure. When applied to the flexible array member, the counted_by attribute is used by the sanitizer—enabled by -fsanitize=array-bounds—by explicitly referencing the field that stores the number of elements. The attribute creates an implicit relationship between the flexible array member and the count field enabling the array bounds sanitizer to verify flexible array operations.

There are some rules to follow when using this feature. For this structure:

struct foo {
	/* ... */
	size_t count; /* Number of elements in array */
	int array[] __attribute__((counted_by(count)));
};
  • The count field must be within the same non-anonymous, enclosing struct as the flexible array member.
  • The count field must be set before any array access.
  • The array field must have at least count number of elements available at all times.
  • The count field may change, but must never be larger than the number of elements originally allocated.

An example allocation of the above structure:

struct foo *foo_alloc(size_t count) {
  struct foo *ptr = NULL;
  size_t size = MAX(sizeof(struct foo),
                    offsetof(struct foo, array[0]) +
                        count * sizeof(p->array[0]));

  ptr = calloc(1, size);
  ptr->count = count;
  return ptr;
}

Uses for fortification

Fortification (enabled by the _FORTIFY_SOURCE macro) is an ongoing project to make the Linux kernel more secure. Its main focus is preventing buffer overflows on memory and string operations.

Fortification uses the __builtin_object_size() and __builtin_dynamic_object_size() builtins to try to determine if input passed into a function is valid (i.e. "safe"). A call to __builtin_dynamic_object_size() generally isn't able to take the size of a flexible array member into account. But with the counted_by attribute, we're able to calculate the size and improve safety.


Uses in the Linux kernel

The counted_by attribute is already in use in the Linux kernel, and will be instrumental in catching issues like integer overflows, which led to a heap buffer overflow. We want to expand its use to more flexible array members, and enforce its use in the future.


Conclusion

The counted_by attribute helps address a long-standing fortification road block where the memory bounds of a flexible array member couldn't be determined by the compiler, thus making Linux, and other hardened applications, less exploitable.

1In Clang v18.0.0 and GCC v15.0.0.

By Bill Wendling, Staff Software Engineer

Why Diversity is Important in Open Source: Google’s Sponsorship of OSSEU

The Open Source Summit + Embedded Linux Conference is taking place in Lyon, France, which the Google Open Source Programs Office is sponsoring. The Linux Foundation supports shared technology through open source, while the conference provides a space for developers and technologists in open source to meet, network, and share knowledge with one another in order to advance the community. Why is this of utmost importance to Google OSS? Google has been rooted in the open source community for many years, supporting programs, projects, and organizations to help advance open source software and technology—we understand the necessity of sustaining open source and the developer community in order to advance technology as a whole.

Sponsoring OSSEU is more than just providing funds, but really pushing the diversity initiative in open source. We need diversity across all levels in open source whether it’s contributors, maintainers, doc writers, or anyone supporting the project. As said recently by the Open Source Initiative, “Many perspectives makes better software.” Having previously funded diversity initiatives such as scholarships or lunches at OSS conferences, Google continues to support this cause by sponsoring the diversity lunch at OSSEU.
In particular, sessions and events that Google will be hosting while at OSSEU include a keynote on Documentation by Megan Byrd-Sanicki and the Women in Open Source Lunch, both on Tuesday, October 29, 2019. The keynote on Docs highlights the importance of doc stars and why their contributions are essential to the growth of the open source community. Our support of the women in open source lunch is especially important as we look to increase the diversity of the open source community by supporting women and non-binary persons to get more involved and have the opportunity to connect with each other at an event of this scale.

If you’re attending OSSEU, stop by the keynote, and we hope to see you at the lunch as well. If you aren’t attending this year, and are interested in getting more involved in the open source community, the summits hosted by the Linux Foundation are one of the best ways to learn more about OSS and meet passionate people involved in different OSS projects and organizations.

By Radha Jhatakia, Google OSPO

High engagement, larger screens: How Android developers can reach users on any device

Posted by Allan Livingston, Product Management Director, Chrome OS App Ecosystem

Android fuels mobile apps on devices that range far beyond your typical small-screen smartphone, from new Chromebooks like the lightweight, high-performance Google Pixelbook Go to multi-display devices and foldable phones like the Samsung Galaxy Fold. Not to mention the more than 175M Android tablets that have the Google Play store installed.1

These large-screen devices set the stage for more engaging and visually immersive experiences, whether by creating a larger canvas for creativity or by giving users faster, more flexible ways to work. As we’ve continued to prioritize large-screen devices with OEM partners like Samsung, Asus, and Lenovo, we’ve been able to expand our reach to a huge new audience of users.

During the week of Black Friday in 2018, 1 in 3 notebooks sold in the U.S. were Chromebooks.2 Chromebook unit sales also increased 22% YoY, while the rest of the notebook category decreased -6.1%.3 And we’re not just reaching more users — we’re reaching more engaged users. In fact, in just the last year, the total amount of time spent in Android apps on Chrome OS has grown 4X.4

YoY notebook sales in the U.S.

By making adjustments for larger screens, you can provide richer experiences across all these devices and tap into a wider audience of app users. Development teams around the world — including Adobe Lightroom, Evernote, and Gameloft, among many others — have already seen some incredible results:

App developers driving engagement on larger screens

With the goal of allowing users to play any video file, anywhere, on any device or screen size, the developers at VideoLAN project decided to adapt VLC — an open source, cross-platform multimedia player — for all screens. The team started by adding keyboard and mouse support before designing multiple versions of the layout to allow users to easily scale and resize the app.

Users can now enjoy the same immersive experience across a range of different devices and form factors, and VideoLAN has already received overwhelmingly positive feedback from users around the world.

War Robots — a 12-player real-time battle game developed by Pixonic — was originally designed for early-generation phones. The team enabled windowed gameplay so users could play in one window while watching their favorite streamers or upgrading their robots in another, created new tutorials and controls that appear whenever players switch between desktop and tablet mode, and added support for keyboard and mouse input.

More than 100,000 players have already played War Robots on Chrome OS since Pixonic rolled out the latest optimizations, which made War Robots’ battles even more thrilling and engaging on larger screens, and Pixonic has seen 25% longer user sessions on Chromebooks as a result.

Is your app optimized for large-screen devices? Here are a few things to consider:

1) Laptop and tablet mode
Test your core app functions to make sure everything works smoothly without crashing as users switch between different modes.

2) Window management and layout
Support multi-window mode and free-form window resizing, and be sure to design optimized layouts for both landscape and portrait orientations. Set up your app to correctly handle configuration changes to avoid crashes when people rotate their devices.

Suite of devices

3) Keyboard and mouse input
Make sure your app is fully functional without touch input, and add support for keyboards, mice, and game controllers (if applicable).

4) Hardware support
If you’re using NDK, be sure to support x86 (32 and 64bit) ABIs to ensure the highest possible performance.

Build, test, and run Android apps on a Chromebook

From the start, our goal has been to make the Chromebook a simple, secure, and speedy environment for everyone. The launch of Linux (Beta) on Chrome OS allowed Android developers to build and test apps with a Chromebook. And earlier this year at I/O, we announced that Android Studio 3.5 now fully supports Chrome OS with a simple one-click installation.

Since then, we’ve been working on a few improvements that make Chromebooks an even better place for safe and seamless Android app development. Let’s start with the biggest one:

Deploying an app directly to Chrome OS to enable full Android development
In the past, you could only test your apps by deploying them to Android phones. With Chrome OS’s upcoming M80 release, you’ll be able to deploy Android apps directly to your Chromebook. That way, you can develop and test your app on the same machine, all without a connected device or needing to put your laptop in developer mode. Developers can start testing this feature in developer channel in November.

GPU acceleration for a snappier, jank-free UI (now in beta channel)
We’ve enabled GPU support to reduce latency and deliver a snappier UI. That goes for developer apps such as Android Studio, Unity Editor, or Visual Studio Code. And for developers who also work on web apps, GPU acceleration means faster testing with Chrome Canary or Firefox.

Container backup and restore to easily move between devices
Previously, Linux files and apps were tied entirely to the device — if you lost your device, you lost all the work inside of it. Now, Chrome OS’s container-based architecture allows you to pack up your entire workspace and export it to external storage or Drive. The backup file can be restored at any point, either on the same machine — which is helpful when jumping back to a previous state — or to move to another Chromebook.

You can now find import and export buttons in your Linux settings.

Picture-in-picture (PiP) support

If you’ve built PIP support into your Android apps, you’ll see that function work seamlessly in Chrome OS in 2020. But you can start testing this feature now by enabling PiP in Android settings → Developer options.

Build your apps with larger screens in mind

With millions of users on Chromebooks, tablets, foldables, and now multi-display devices, designing app experiences with larger screens in mind is crucial. Seize this opportunity to engage more users by optimizing your existing apps to work great across all screens. And the latest Linux features on Chrome OS give you the power to use a single machine to build and run Android apps. Don’t hesitate to take action to ensure your apps work seamlessly on larger screens with Linux on Chrome OS.









Sources

1. The number of tablets only accounts for devices that have the Google Play Store installed (e.g., excluding tablets in China); the actual number of tablets capable of running Android applications is much larger.

2. The NPD Group, Inc., Retail Tracking Service, U.S., Notebook Computers, Chrome OS, based on units, Nov. 18, 2018–Nov. 24, 2018 vs. Nov. 19, 2017–Nov. 25, 2017.

3. The NPD Group, Inc., U.S. Retail Tracking Service, Notebook Computers, based on units, Sept. 2018–Aug. 2019. Sales are adjusted for 5 weeks in Jan. 2018 vs. 4 weeks in Jan. 2019.

4. Google Internal Data, March 2018–March 2019.

Google fosters the open source hardware community

Open source silicon promises new challenges and opportunities for both industry and the open source community. To take full advantage of open silicon we will need new design methodologies, new governance models, and increased collaborations between industry, academia, and not for profits. A vibrant free and open source software community has been vital to both Google and our customer’s success. We look forward to supporting the new domain of open source silicon to similarly benefit all participants.

Working through its Open Source Programs Office (OSPO), Google is actively engaged in helping seed the open silicon space. Specifically by providing funding, strategic, and legal support to key open hardware efforts including lowRISC and CHIPS alliance.

lowRISC

lowRISC is a leader in open silicon community outreach, technical documentation, and advancing the goal of a truly open source system on a chip. We have long supported lowRISC’s mission of transparently implemented silicon and robust engagement of the open source silicon community, providing funding, advice, and recognizing their open source community leadership by selecting them as a Google Summer of Code mentoring organization.

Similar to the benefits of open source software, we believe our users will derive great outcomes from open source silicon. Besides enabling and encouraging innovation, chip designs derived from a common, open baseline will provide the benefit of implementation choice while still guaranteeing software compatibility and a set of common interfaces. With regards to security, the transparency of an open source approach is critical to both bugfinding and establishing implementation trustworthiness.

"Google has encouraged and supported lowRISC since the very start. They clearly share our optimism for what open source hardware can offer and our community-driven vision of the future. We are excited by the expanding open source RISC-V ecosystem and look forward to lowRISC community IP being deployed in the real world,” said Alex Bradbury, Co-founder and Director. “We believe lowRISC can act as an important catalyst for open source silicon, providing a shared engineering resource to ensure quality, provide support and help to maintain IP from a range of partners.”
lowRISC board members (L to R): Dominic Rizzo (Google), Alex Bradbury (lowRISC), Gavin Ferris (lowRISC), Dr Robert Mullins (University of Cambridge), Prof. Luca Benini (ETH Zürich), and Ron Minnich (Google, not pictured).
A first example of Google’s ongoing collaboration with ETH Zürich and lowRISC is the recently released “Ibex” RISC-V core. ETH Zürich donated their Zero-riscy core as a starting point and technical work to extend the core was done across all three organizations. You can learn more about Google’s collaboration with lowRISC on the RISC-V core here.

Furthermore, Google is excited to announce that it is joining the board of lowRISC, with the appointment of Dominic Rizzo and Ronald Minnich as corporate directors.

CHIPS Alliance 

Along with our increased funding, support and collaboration with lowRISC, we are also happy to announce our status as a founding member of the Linux Foundation’s CHIPS Alliance project. CHIPS Alliance features an industry-driven, collaborative model to release high-quality silicon IP and supporting technical collateral. Most recently, in collaboration with CHIPS Alliance, we released a Universal Verification Methodology (UVM) instruction stream generator to aid in the verification of RISC-V cores. We believe such open sourcing of verification tools will prove critical to the long-term success of the open source silicon community.

Google has been an early, strong supporter of the open silicon community. We believe deeply in a future where transparent, trustworthy open source chip designs are commonplace. To get there, we are committed to establishing a collaborative, community-focused, open source basis for free and open silicon design.

By Parthasarathy Ranganathan, Distinguished Engineer, Google and Dominic Rizzo, Open Silicon Tech Lead, Google 

Control Flow Integrity in the Android kernel

Posted by Sami Tolvanen, Staff Software Engineer, Android Security

Android's security model is enforced by the Linux kernel, which makes it a tempting target for attackers. We have put a lot of effort into hardening the kernel in previous Android releases and in Android 9, we continued this work by focusing on compiler-based security mitigations against code reuse attacks.

Google's Pixel 3 will be the first Android device to ship with LLVM's forward-edge Control Flow Integrity (CFI) enforcement in the kernel, and we have made CFI support available in Android kernel versions 4.9 and 4.14. This post describes how kernel CFI works and provides solutions to the most common issues developers might run into when enabling the feature.

Protecting against code reuse attacks

A common method of exploiting the kernel is using a bug to overwrite a function pointer stored in memory, such as a stored callback pointer or a return address that had been pushed to the stack. This allows an attacker to execute arbitrary parts of the kernel code to complete their exploit, even if they cannot inject executable code of their own. This method of gaining code execution is particularly popular with the kernel because of the huge number of function pointers it uses, and the existing memory protections that make code injection more challenging.

CFI attempts to mitigate these attacks by adding additional checks to confirm that the kernel's control flow stays within a precomputed graph. This doesn't prevent an attacker from changing a function pointer if a bug provides write access to one, but it significantly restricts the valid call targets, which makes exploiting such a bug more difficult in practice.

Figure 1. In an Android device kernel, LLVM's CFI limits 55% of indirect calls to at most 5 possible targets and 80% to at most 20 targets.

Gaining full program visibility with Link Time Optimization (LTO)

In order to determine all valid call targets for each indirect branch, the compiler needs to see all of the kernel code at once. Traditionally, compilers work on a single compilation unit (source file) at a time and leave merging the object files to the linker. LLVM's solution to CFI is to require the use of LTO, where the compiler produces LLVM-specific bitcode for all C compilation units, and an LTO-aware linker uses the LLVM back-end to combine the bitcode and compile it into native code.

Figure 2. A simplified overview of how LTO works in the kernel. All LLVM bitcode is combined, optimized, and generated into native code at link time.

Linux has used the GNU toolchain for assembling, compiling, and linking the kernel for decades. While we continue to use the GNU assembler for stand-alone assembly code, LTO requires us to switch to LLVM's integrated assembler for inline assembly, and either GNU gold or LLVM's own lld as the linker. Switching to a relatively untested toolchain on a huge software project will lead to compatibility issues, which we have addressed in our arm64 LTO patch sets for kernel versions 4.9 and 4.14.

In addition to making CFI possible, LTO also produces faster code due to global optimizations. However, additional optimizations often result in a larger binary size, which may be undesirable on devices with very limited resources. Disabling LTO-specific optimizations, such as global inlining and loop unrolling, can reduce binary size by sacrificing some of the performance gains. When using GNU gold, the aforementioned optimizations can be disabled with the following additions to LDFLAGS:

LDFLAGS += -plugin-opt=-inline-threshold=0 \
           -plugin-opt=-unroll-threshold=0

Note that flags to disable individual optimizations are not part of the stable LLVM interface and may change in future compiler versions.

Implementing CFI in the Linux kernel

LLVM's CFI implementation adds a check before each indirect branch to confirm that the target address points to a valid function with a correct signature. This prevents an indirect branch from jumping to an arbitrary code location and even limits the functions that can be called. As C compilers do not enforce similar restrictions on indirect branches, there were several CFI violations due to function type declaration mismatches even in the core kernel that we have addressed in our CFI patch sets for kernels 4.9 and 4.14.

Kernel modules add another complication to CFI, as they are loaded at runtime and can be compiled independently from the rest of the kernel. In order to support loadable modules, we have implemented LLVM's cross-DSO CFI support in the kernel, including a CFI shadow that speeds up cross-module look-ups. When compiled with cross-DSO support, each kernel module contains information about valid local branch targets, and the kernel looks up information from the correct module based on the target address and the modules' memory layout.

Figure 3. An example of a cross-DSO CFI check injected into an arm64 kernel. Type information is passed in X0 and the target address to validate in X1.

CFI checks naturally add some overhead to indirect branches, but due to more aggressive optimizations, our tests show that the impact is minimal, and overall system performance even improved 1-2% in many cases.

Enabling kernel CFI for an Android device

CFI for arm64 requires clang version >= 5.0 and binutils >= 2.27. The kernel build system also assumes that the LLVMgold.so plug-in is available in LD_LIBRARY_PATH. Pre-built toolchain binaries for clang and binutils are available in AOSP, but upstream binaries can also be used.

The following kernel configuration options are needed to enable kernel CFI:

CONFIG_LTO_CLANG=y
CONFIG_CFI_CLANG=y

Using CONFIG_CFI_PERMISSIVE=y may also prove helpful when debugging a CFI violation or during device bring-up. This option turns a violation into a warning instead of a kernel panic.

As mentioned in the previous section, the most common issue we ran into when enabling CFI on Pixel 3 were benign violations caused by function pointer type mismatches. When the kernel runs into such a violation, it prints out a runtime warning that contains the call stack at the time of the failure, and the call target that failed the CFI check. Changing the code to use a correct function pointer type fixes the issue. While we have fixed all known indirect branch type mismatches in the Android kernel, similar problems may be still found in device specific drivers, for example.

CFI failure (target: [<fffffff3e83d4d80>] my_target_function+0x0/0xd80):
------------[ cut here ]------------
kernel BUG at kernel/cfi.c:32!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
…
Call trace:
…
[<ffffff8752d00084>] handle_cfi_failure+0x20/0x28
[<ffffff8752d00268>] my_buggy_function+0x0/0x10
…

Figure 4. An example of a kernel panic caused by a CFI failure.

Another potential pitfall are address space conflicts, but this should be less common in driver code. LLVM's CFI checks only understand kernel virtual addresses and any code that runs at another exception level or makes an indirect call to a physical address will result in a CFI violation. These types of failures can be addressed by disabling CFI for a single function using the __nocfi attribute, or even disabling CFI for entire code files using the $(DISABLE_CFI) compiler flag in the Makefile.

static int __nocfi address_space_conflict()
{
      void (*fn)(void);
 …
/* branching to a physical address trips CFI w/o __nocfi */
 fn = (void *)__pa_symbol(function_name);
      cpu_install_idmap();
      fn();
      cpu_uninstall_idmap();
 …
}

Figure 5. An example of fixing a CFI failure caused by an address space conflict.

Finally, like many hardening features, CFI can also be tripped by memory corruption errors that might otherwise result in random kernel crashes at a later time. These may be more difficult to debug, but memory debugging tools such as KASAN can help here.

Conclusion

We have implemented support for LLVM's CFI in Android kernels 4.9 and 4.14. Google's Pixel 3 will be the first Android device to ship with these protections, and we have made the feature available to all device vendors through the Android common kernel. If you are shipping a new arm64 device running Android 9, we strongly recommend enabling kernel CFI to help protect against kernel vulnerabilities.

LLVM's CFI protects indirect branches against attackers who manage to gain access to a function pointer stored in kernel memory. This makes a common method of exploiting the kernel more difficult. Our future work involves also protecting function return addresses from similar attacks using LLVM's Shadow Call Stack, which will be available in an upcoming compiler release.

Google Summer of Code 2016 wrap-up: Linux XIA

We're sharing guest posts from students, mentors and organization administrators who participated in Google Summer of Code 2016. This is the fifth post in that series and there are more on the way.


Linux XIA is the native implementation of XIA, a meta network architecture that supports evolution of all of its components, which we call “principals,” and promotes interoperability between these principals. It is the second year that our organization, Boston University / XIA, has participated in Google Summer of Code (GSoC), and this year we received 31 proposals from 8 countries.

Our ideas list this year focused on upgrading key forwarding data structures to their best known versions. Our group chose the most deserving students for each of the following projects:

Accelerating the forwarding speed of the LPM principal with poptrie

Student André Ferreira Eleuterio and mentor Cody Doucette implemented the first version of the LPM principal in Linux XIA for GSoC 2015. The LPM principal enables Linux XIA to leverage routing tables derived from BGP, OSPF, IS-IS and any other IP routing protocol to forward XIA packets natively, that is, without encapsulation in IP. For GSoC 2016, student Vaibhav Raj Gupta from India partnered with mentor Cody Doucette to speed up the LPM principal by employing a state-of-the-art data structure to find the longest prefix matching using general purpose processors: poptrie.

Upgrading the FIB hash table of principals to the relativistic hash table

Principals that rely on routing flat names have used a resizable hash table that supports lockless readers since 2011. While this data structure was unique in 2011, in the same year, relativistic hash tables were published. The appeal to upgrade to relativistic hash tables was twofold: reduced memory footprint per hashed element, and the fact they were implemented in the Linux kernel in 2014. Student Sachin Paryani, also from India, worked with mentor Qiaobin Fu to replace our resizable hash table with the relativistic hash table.

Google Summer of Code nurtures a brighter future. Thanks to GSoC, our project has received important code contributions, and our community has been enlarged. It was rewarding to learn that two of our GSoC students have decided to pursue graduate school after their GSoC experience with us: Pranav Goswami (2015) and Sachin Paryani (2016). We hope these examples will motivate other students to do their best because the world is what we make of it.

By Michel Machado, Boston University / XIA organization administrator

Google Summer of Code wrap-up: Linux XIA

It’s Friday! Time for another Google Summer of Code wrap-up post. Boston University / XIA is one of the 37 new organizations to the program this year. Read below about three student projects and their work to discover the future architecture of the internet.
lx-motto.png
Linux XIA is the native implementation of eXpressive Internet Architecture (XIA), a meta network architecture that supports evolution of all of its components, which we call “principals,” and promotes interoperability between these principals. We are developing Linux XIA because we believe that the most effective way to find the future Internet architecture that will eventually replace TCP/IP is to crowdsource the search. This crowdsourced search is possible in Linux XIA.

Our organization, Boston University / XIA, received 34 proposals from 12 countries. As a first-year organization in Google Summer of Code (GSoC), we were surprised by the number of proposals, and we did our best to choose great students for each of the following projects:

XLXC is a set of scripts written in Ruby that creates network topologies using virtual interfaces and Linux containers. While testing a new network stack, a good amount of work goes into creating testing environments. XLXC saves developers and tinkerers a lot of time while experimenting with Linux XIA. Our student Aryaman Gupta from India worked with mentor Rahul Kumar to enable XLXC to emulate any topology using a language to describe the topologies.

Linux XIA needs to call forwarding functions that correspond to each XID type in order to forward a packet. XID types are 32-bit identifiers associated with principals which, in turn, define the forwarding functions. Being able to hash each XID type to a unique entry in an array increases the number of packets Linux XIA can forward per second because it reduces the number of memory accesses per lookup. Our student Pranav Goswami, also from India, worked with mentor Qiaobin Fu to find the best perfect hashing algorithm for Linux XIA to use in this case, and implemented it in Linux XIA.

We do not know how the future Internet will route packets between autonomous systems (ASes), but we are certain that Linux XIA can leverage IP's routing tables to have large deployments of Linux XIA. This is the goal of the LPM principal: leveraging routing tables derived from BGP, OSPF, IS-IS and any other IP routing protocol to forward XIA packets natively, that is, without encapsulation in IP. Thanks to the evolution mechanism built into Linux XIA, when a better way to route between ASes becomes available, we will be able to incrementally phase LPM out. Student André Ferreira Eleuterio from Brazil implemented the LPM principal in Linux XIA with the help of mentor Cody Doucette.

We are going to work with our students during the fall to have their contributions merged into our repositories and to add new projects to our ideas list that build upon their contributions. We expect that this will motivate new contributors by showing how much impact they can have on Linux XIA. Finally, new collaborators do not need to wait for the next GSoC to get involved! Join our community today, and "do what you can, with what you have, where you are" to make a difference like our three students successfully did.

By Michel Machado, Organization Administrator for Boston University / XIA