Google Summer of Code 2022 Ideas

This page lists all the project ideas for our Google Summer of Code 2022 application. Students should also visit our general GSoC 2022 page for more information including a Student Guide and our contact information.

1 Your Own Idea!
2 Hardening
3 Kernel sanitizers
- 3.1 Address Sanitizer
- 3.2 Data race detector
4 Kernel and HAL projects
5 Drivers
6 Sound stack
- 6.1 Audio Mixer
7 Durability
- 7.1 Kernel mode test suite
8 System Enhancements
- 8.1 Add support for ext2 file system as a boot FS
- 8.2 Integrating a modern C++ standard library
9 Debugging Improvements
- 9.1 Support for debugging over USB 3.0
- 9.2 PDB support for dbghelp

Your Own Idea!

We are eager to hear about your proposal to improve either ReactOS or its infrastructure. Come and propose your project on the ReactOS developers mailing-list or on IRC to get feedback about its feasibility. If your project is doable, we will be glad to provide you with a mentor so you can succeed in your project.

Don't forget that ReactOS is a big project and application fields are wide. You can choose between user-mode or kernel-mode development, between application, or dll/driver development, or between working on ReactOS itself or on extra tools used by developers for their daily work on ReactOS. Also if all you prefer is web development, we also have needs there.

Skills needed: Yours

Difficulty: The one you'll have set

Extras: You'll be working on your own project and be able to choose its direction along with your mentor :-).

Hardening

The goal of all hardening projects is to make ReactOS a more secure operating system, bringing it to more modern security standards.

Implement Address Space Layout Randomization (ASLR)

Difficulty: Medium

Expected project size: 350 hours

Clang's ShadowCallStack support in the kernel

Optional goal: Intel Control-flow Enforcement Technology (CET) support

Difficulty: Hard

Expected project size: 350 hours

References: Clang Shadow Call Stack documentation

Intel Supervisor Mode Execution Prevention (SMEP) support

This technology is able to prevent executing a user mode application's memory in the kernel context

Difficulty: Medium

Expected project size: 175 hours

Kernel sanitizers

Address Sanitizer

This project suggests to implement the Kernel Address Sanitizer for detecting memory errors in the kernel.

Difficulty: Medium

Benefits: Address sanitizer helps developers to catch different types of memory access bugs which GREATLY improves debugging experience.

Expected project size: 350 hours

Data race detector

This project suggests to implement a data race detector in the kernel using either Thread Sanitizer or Data-collider approach. Please, consult in the developer chat if you are interested in this one.

Difficulty: Hard

Benefits: As any bug detector, race detectors greatly improve debugging experience, especially with the upcoming SMP support.

Expected project size: 175 hours

Kernel and HAL projects

Refactor ReactOS hardware clock sources support

Currently ReactOS HAL (Hardware Abstraction Layer) supports only PIT and TSC as a hardware clock source, and the usage of these are hardcoded (PIT is used when the 8259 PIC is used, TSC is used when APIC is enabled). On the other hand, modern operating systems try to choose the best timer dynamically, depending on the current system.

Tasks for this project

Unify the timers code (detection and initialization) in HAL, so the OS can easily switch between different clock sources
Implement remaining timers support on x86 (namely, HPET and ACPI PM timer)
Implement the choosing routine at the OS boot (can be simple at first)

This is a relatively easy task, but it may help a lot to get familiar with the HAL and kernel code

References: Timer Interrupt Sources; TSC resynchronization; the source of ReactOS x86 HAL(s)

Skills needed: Development in C; Kernel-mode development; Familiarity with x86-specific platform features

Expected project size: 175 hours

Memory manager improvements

The memory manager in ReactOS kernel does not support modern CPU features which greatly improve kernel performance and security. This project suggest implementing some of them, namely:

ASID (address space identifiers) support (it is called PCID on newer x86 processors)
Global Pages feature on x86 CPUs
Kernel page table isolation technique for Meltdown vulnerability mitigation

A contributor should also create a benchmark as a part of this project so one can verify implemented features actually bring more performance.

Difficulty: Medium

Expected project size: 350 hours

Implement the resource arbiter library

ReactOS cannot use devices which try to use overlapping hardware resource ranges (I/O ports, or memory ranges). In Windows this is done using the arbiter library, which is not implemented in ReactOS. Check out the attached links for how resource translation and arbitration works in Windows.

Tasks for this project

Fix the implementation of "range lists" functions in RTL library
Write better tests for range lists functions
Implement the arbiter library, using them and check it with PCI (pcix) driver

References: Arbitration and Translation Part 1; Translation and Windows Part 2; Arbitration and Translation Part 3; VGalNT's attempt to implement the library (check other LIB:ARB and LIB:RTL commits in the branch too)

Expected project size: Flexible (175-350 depending on the tasks selected)

AVX register context saving

Currently ReactOS does not support AVX/AVX2/AVX512 instructions in both user and kernel mode. This can be fixed by adding code for saving AVX/AVX512 registers into the process context.

Tasks for this project

Add the support for process context saving via x86 XSAVE instruction.
Implement the support for optimized XSAVEOPT/XSAVES instructions.
Implement the extended context saving for drivers (kernel mode).

References: https://wiki.osdev.org/SSE; An article about XSAVE internals on Windows

Expected project size: 175 hours

Continue SMP bringup

With GSoC 2021 we have started implementing SMP support. There is a lot work to do here, so everybody is welcome to help. The task may involve work on: scheduler, HAL, SMP debugging support and many parts more. Please, contact developers in chat if you want to work in this area.

Difficulty: Hard

Expected project size: Flexible (175-350 depending on the tasks selected)

Improving the quality of our Registry Hive implementation

ReactOS features a basic implementation of the Windows-compatible Registry Hive format for storing system and application settings. There are two major areas where our current implementation could be improved:

When ReactOS crashes, Registry Hives easily get corrupted and render the whole system unbootable. The reliability of the Registry Hive implementation shall be improved to make the effect of crashes less severe and also recover from partly corrupted Hives.
Hives created by our mkhive tool are roughly compatible with the Windows format. The only part that is currently missing are the implementation of Security Descriptors. Implementing these could make the tool more usable and improve interoperability between Windows and ReactOS.

Related components in ReactOS are the cmlib library, the ntoskrnl Cm, and the mkhive tool.

References: "The Internal Structure of the Windows Registry", MSc Thesis by Peter Norris, BSc (Hons), MBCS: http://amnesia.gtisc.gatech.edu/~moyix/suzibandit.ltd.uk/MSc/; Offline NT Password and Registry Editor: http://pogostick.net/~pnh/ntpasswd/; Bug reports CORE-6762, CORE-9195 and CORE-10793.; Other links can be found in the Registry wiki page.

Skills needed: Development in C; Kernel-mode development

Difficulty Note: This is a formidable task. Please get advice from a mentor regarding the recommended skill level and possible reductions in scope to ensure your project proposal is realistic.

Expected project size: Flexible (175-350 depending on the tasks selected)

Drivers

Finish storport.sys driver implementation

storport.sys is a library (aka port-driver), which is used in conjunction with a miniport-driver to operate storage controllers. Currently the ReactOS' storport.sys implementation is not finished and getting it into a usable state will allow the project to use open source AHCI and NVMe storport-miniports which can greatly improve ReactOS hardware support. A potential contributor may look into legacy scsiport.sys driver for the task, as they share a lot of concepts.

Tasks for this project

Fix a Microsoft's storahci.sys driver example to compile with ReactOS SDK.
Make the ReactOS storport.sys library to work with storahci.sys example driver.
Check storport.sys can work in Windows 2003 too.
Make the Open Fabrics NVMe driver work with storport.sys (ask in the chat)

References: storahci.sys driver example; ReactOS storport driver on GitHub; MSDN StorPort driver developer's manual; Introduction to Plug and Play

Skills needed: The knowledge about Windows Driver Model; Kernel development in C and under Windows

Expected project size: 350 hours

USB stack refactoring and stability improvement

There are parts in USB stack where we want to improve the code quality and leverage the use of modern driver frameworks. This project suggests to refactor the usbhub.sys driver on ReactOS tree, and make it use the WDF (Windows Driver Foundation) framework for better code density and stability.

Difficulty: Medium

Benefits: ReactOS should have a more robust and performant USB stack after this task being done.

Expected project size: 175 hours

Isochronous transfers support in USB stack

ReactOS USB stack currently supports only Bulk, Control and Interrupt transfers from USB spec. There is only one type of transfer left - Isochronous transfers, which is mostly used in streaming devices like webcams, USB audio devices, etc.

Difficulty: Hard

Benefits: With this project being done, ReactOS will support USB audio adapters, webcams and some other USB devices.

Expected project size: 350 hours

Paravirtualization Support / VirtIO drivers

Virtual machines are increasingly common in all fields of computing. To increase VM performance, paravirtualization bypasses the emulation of traditional hardware (such as specific network or storage interfaces, or even the entire PCI bus) and uses specially crafted drivers in the guest OS to more directly interface with the hypervisor. The guest OS kernel can also be modified to directly interact with the hypervisor for CPU and memory management operations, leading to improved performance.

There are many choices of projects in this space, such as:

Making Xen's open source drivers work in ReactOS

Creating an initial set of drivers to support "enlightenment" under Hyper-V

Enhance the kernel to make use of hypervisor functionality for low-level operations (e.g. via VMI)

Testing and integrating VirtIO drivers, VirtualBox Guest Additions and/or open-vm-tools into ReactOS

Implementing automatic hypervisor detection during setup or in the applications manager to simplify the installation of the appropriate VM guest drivers

VirtIO-FS support for the possibility to use shared host directories on QEMU

Note that these projects can vary greatly in difficulty. Please consult with a mentor to ensure your skill set and the scope of your proposal match up to make a realistic project.

Benefits: Avoid non-free or unavailable alternative drivers; Improved out-of-the-box functionality in virtual machines; Integration of kernel features that may improve VM performance

References: Xen Windows PV Drivers; open-vm-tools; VirtualBox Guest Additions; Linux Hyper-V drivers; The VMI virtualization interface; VirtIO-FS website

Skills needed: Experience with the Hypervisor of your choice, and preferably its paravirtualization interface; Kernel development under Windows

Expected project size: Flexible (175-350 depending on the tasks selected)

UEFI GOP graphics driver

ReactOS still does not fully support booting on UEFI machines (without CSM support). One of the last bits not done on that behalf is the UEFI graphics driver (GOP).

Difficulty: Medium

Benefits: Finishing this project will make ReactOS almost being able to boot on UEFI PCs (the last remaining bit is setup support for that).

Expected project size: 175 hours

Sound stack

Audio Mixer

Implement support for mixing of audio streams.

Benefits: An audio mixer is responsible for routing of multiple audio streams. This would be very beneficial to ReactOS as audio driver support has improved yet the use of these drivers is limited by the lack of an audio mixer. At the end of the project multiple audio streams should be able to be played at the same time.

References: Audio Mixer Reference; DirectKS Sample Application download; Programming Services; "Secret Rabbit Code" (SRC) Sample Rate Converter aka libsamplerate

Skills needed: Windows Services familiarity; Basic Audio file format familiarity; Audio mixing algorithms / libraries familiarity; Basic kernel streaming familiarity

Expected project size: 175 hours

Durability

Kernel mode test suite

Useful for: Developers

Improve our existing kernel mode test suite (created by a previous successful GSoC student) by adding comprehensive new tests in areas previously untouched by the test suite such as the kernel caching APIs and PnP. The goal is to extensively test Native API functions exported by the kernel. Reference behavior could be checked by running the test suite against the corresponding Windows operating system.

Benefits: Improved system stability.; More information about undocumented behavior.; Improved compatibility with third party drivers.

Skills needed: Native API knowledge; NT driver development skills

Expected project size: Flexible (175-350 depending on the tasks selected)

System Enhancements

Add support for ext2 file system as a boot FS

There is already an ext2 file system driver available in ReactOS tree (Ext2Fsd project). Our bootloader (FreeLoader) also has some sort of ext2 support, but it is unknown whether it is finished or not. The goal for this task is to verify ext2 support in both ReactOS and the bootloader, create formatting tools for ReactOS Setup utility and glue everything together.

Difficulty: Easy

Benefits: Along with FAT32 and BTRFS there will be another file system ReactOS can be installed on.

Expected project size: 175 hours

Integrating a modern C++ standard library

To attract new developers, speed up development and make it less error-prone, the ReactOS Project wants to leverage the features of modern C++. This requires a C++ standard library supporting at least C++11 and C++14. However, ReactOS currently uses an unspecified version of GNU libstdc++ when built with GCC and the largely unmaintained stlport when built with MSVC. This limits us to C++98 features, and having two libraries is the root cause for many subtle problems.

As ReactOS is one of the few operating systems, which can be built with both GCC and MSVC (and possibly Clang in the future), we need a modern C++ standard library that is compatible with all of them. Candidates are LLVM libc++ and Microsoft's [STL https://github.com/microsoft/STL/]. Being an operating system, the standard library also needs to be integrated into our source tree and built through CMake.

In this task, the student shall evaluate both C++ standard libraries regarding features, compatibility with our compilers, and required customizations. The student shall then proceed to integrate it into our source tree and get it to build together with the rest of our code. Some of our few current C++ applications may need minor fixes for that.

Note that LLVM's libc++ and Microsoft's STL are just two C++ standard libraries we found. Any other library under an OSI-approved license is welcome as well.

Benefits: Accelerating ReactOS development by attracting more C++ developers and easing the work for the existing ones; Fixing a lot of subtle bugs due to the current usage of two different C++ standard libraries

References: LLVM libc++; Microsoft STL; stlport in our current source tree; cpprt in our current source tree

Skills needed: Development in C++, including modern C++11 and C++14, down to the runtime level; Knowledge about the CMake build system; Basic debugging skills

Expected project size: 350 hours

Debugging Improvements

Support for debugging over USB 3.0

ReactOS debugging is currently most effective when using a serial port. Many real hardware systems no longer have serial ports, leaving on-screen debugging as the only viable alternative.

Windows supports debugging via the KD protocol using transport mediums other than serial lines: 1394, USB3, ethernet, and the undocumented KDVM protocol supported by Hyper-V and other Hypervisors. ReactOS should be made compatible with these additional transport providers, and open source versions of these providers should be created.

Benefits: Support for debugging on additional hardware platforms; Improved debugging speed, easier and more reliable setups

References: MSDN: 1394 Debugging; MSDN: Network Debugging; MSDN: USB3 Debugging; OSR: KDNET Debugging; Existing KDCOM transport dll

Skills needed: Software Development in C and under Windows; Kernel Development and Debugging experience

Expected project size: 175 hours

PDB support for dbghelp

Making it possible for our dbghelp read pdb files would improve our ability to debug ReactOS directly in user mode with tools like WinDbg, Process Explorer and more. We could also be able to have small tools for reporting crashes and translating addresses automatically.

Expected project size: 175 hours