SAFER LINUX KERNEL MODULE USING D

LANGUAGE
EMBEDDED NETWORKS AND DEVICE DRIVER LABORATORY

LABORATORY PROJECT REPORT

BRINDA JS

(24MU02)

Dissertation submitted in partial fulfillment of the requirements

for the degree of

MASTER OF ENGINEERING

Branch: ELECTRICAL & ELECTRONICS ENGINEERING

Specialization: EMBEDDED AND REAL-TIME SYSTEMS

of Anna University

December 2024

DEPARTMENT OF ELECTRICAL & ELECTRONICS

ENGINEERING PSG COLLEGE OF TECHNOLOGY
(Autonomous Institution) COIMBATORE – 641 004
 PSG COLLEGE OF TECHNOLOGY
(Autonomous Institution)

COIMBATORE - 641 004

SAFER LINUX KERNEL MODULE USING D LANGUAGE

Bonafide record of work done by

BRINDA JS
(24MU02)

Dissertation submitted in partial fulfillment of the requirements for the degree

of

MASTER OF ENGINEERING

Branch: ELECTRICAL & ELECTRONICS ENGINEERING

Specialization: EMBEDDED AND REAL-TIME SYSTEM

of Anna University

December 2024

…………………… ………....……………………

Dr. P. SIVAKUMAR Dr. J. KANAKARAJ

Faculty Guide Head of the Department

Certified that the candidate was examined in the viva voice examination held on
…….........

.......................... .…….…………

(Internal Examiner) (External Examiner)

 CONTENTS

CHAPTER Page No.

Acknowledgement.............................................................................................. (i)

Synopsis.............................................................................................................. (ii)

List of Figures..................................................................................................... (iii)

1 INTRODUCTION.......................................................................................... 1

1.1 Background and Motivation 2

1.2 Problem Statement 2

1.3 Objective of Project 3

2 LITERATURE REVIEW………………………………………………………. 4

3 KERNEL MODULE USING D LANGUAGE……………………………….. 5

3.1 Propose Method 5

3.2 Selection of Kernel Module 6

 3.3 Porting Data Structure 6

3.4 Function-by-Function Translation 6

3.5 Integrating D code into the Kernel 7

3.6 Safer Enhancement with D features 7

3.7 Validation and Benchmarking 7

4 IMPLEMENTATION OF D MODULE…………………………………… 8

4.1 Development Environment 8

4.2 Compilation and Build System Integration 8

4.3 Function and Structure Porting 8

4.4 Code Enhancement with D features 9

5 EXPERIMENT SETUP…………………………………………………… 10

5.1 System Configuration 10

5.2 Testing and Scenarios 10

6 RESULTS AND DISCUSSIONS……………………………………….. 11

6.1 Functional Correctness 11

6.2 Safety Improvement 11

6.3 Performance Evaluation 11

6.4 Output 12

7 CONCLUSION……………………………………………………………. 18

BIBLIOGRAPHY…………………………………………………………. 19
 ACKNOWLEDGEMENT

I express my sincere thanks to Dr. K. Prakasan, Principal, PSG College

of Technology for his benevolent patronage in carrying out this project.

I express my sincere respect and gratitude to Dr. J. Kanakaraj,

Professor and Head (CAS), Department of Electrical and Electronics
Engineering, PSG College of Technology for his continuous encouragement
and motivation throughout the project.

I am indebted to my beloved internal guide Dr. P. Sivakumar, Assistant

Professor (Sl. Gr) Department of Electrical & Electronics Engineering, PSG
College of Technology and whose valuable guidance and inspiration
throughout the course made it possible to complete this project work
successfully.

I put forth my heart and soul to thank Almighty for being with me
all through this technical adventure.
 SYNOPSIS
The Linux kernel is a core component of countless computing systems,
ranging from supercomputers and servers to embedded and smart devices. Its
widespread adoption has made its security a matter of critical importance.
Despite various protective mechanisms and extensive review efforts, the kernel
continues to face a significant number of vulnerabilities each year. A major root
cause of these vulnerabilities is the use of the C programming language, which,
although fast and flexible, allows unsafe memory operations such as buffer
overflows, null pointer dereferences, and memory corruption.

This paper proposes a practical approach to enhancing kernel security by

introducing memory safety at the programming language level. The authors
explore the feasibility of incrementally transitioning Linux kernel modules from C
to the D programming language, which combines C-like performance and syntax
with modern safety features. These features include array bounds checking, safe
function annotations, strict typing, and compile-time memory safety guarantees.

To validate this approach, the research focuses on porting a real-world

Linux kernel module—the virtio_net network driver—from C to D. The study
outlines the technical challenges faced during the integration of D code into the
Linux kernel, such as ensuring compatibility with kernel data structures, memory
management constraints, and build system modifications. Special attention is
given to maintaining functional parity with the original driver and ensuring that
the performance remains unaffected.

The ported driver was evaluated for functionality, performance, and

security. The results confirmed that the D-based driver operated correctly and
introduced memory safety checks that were absent in the original C
implementation. Importantly, these enhancements were achieved without any
measurable performance penalties, making the case for adopting safer languages
in kernel development more compelling.
 LIST OF FIGURES

Figure No Title Page No

6.1 Kernel Module Using C Language 12

6.2 Kernel Module using D language 13

6.3 TCP performance for C and D language 14

6.4 Vulnerability from 2000 to 2020 15

6.5 Vulnerability of C and D language from 2020 to 16

2025

6.6 Runtime Security Capabilities: Buffer 17

Overflow Detection vs. Tool
Dependency
 CHAPTER 1

INTRODUCTION
The Linux operating system kernel is one of the most widely used and
influential software components in computing today. It powers a vast spectrum
of devices, from supercomputers and servers to smartphones, embedded
systems, and IoT devices. Despite its widespread adoption and ongoing
development, the Linux kernel continues to face significant security challenges.
Running in privileged mode, the kernel has complete control over system
memory and hardware; thus, any vulnerability within it can lead to severe
system- wide compromises.

On average, around 250 Common Vulnerability and Exposure (CVE) reports

are filed annually against the Linux kernel, reflecting the persistent risk of
security flaws. These vulnerabilities are often the result of programming
mistakes exacerbated by the use of the C programming language, which, while
powerful and performant, lacks modern safety features. This paper proposes an
alternative and complementary approach to kernel hardening— rewriting Linux
kernel modules using a safer programming language.

Specifically, the D programming language is explored as a candidate due to

its syntactic similarity to C, compatibility with C code, and support for high-
performance, memory-safe programming. As a proof-of-concept, the authors
ported the virtio_net network driver to D, demonstrating the feasibility and
benefits of using a safer language within the Linux kernel ecosystem.

Building upon this foundational motivation, the authors designed a

comprehensive methodology to port and evaluate a Linux kernel module written
in D. The process involved translating the original C code of the virtio_net driver
into D while maintaining strict compatibility with kernel conventions and build
requirements.

This included mapping C data structures to their D equivalents, resolving

naming and calling conventions, and using the -betterC compiler flag to
eliminate reliance on the D runtime. The integration process also required a
hybrid model where D functions interfaced seamlessly with C-defined kernel
entry points, allowing the module to be compiled, linked, and loaded into the
kernel just like any traditional driver.

Once ported, the D-based driver was rigorously tested for both functional
correctness and performance using real-world network benchmarking tools such
as iperf3, ping, and wget. The results showed that the D module matched the
performance of its C counterpart, with
negligible overhead. More importantly, safety features intrinsic to D, such as
array bounds checking, safe function annotations (@safe), and type-checked
templates, provided significant improvements in memory safety.

These enhancements helped detect and prevent issues like out-of-bounds

access and invalid pointer dereferencing, which would otherwise go unnoticed in
C. This successful demonstration not only validates the utility of D for kernel
development but also presents a viable pathway to improve Linux kernel security
through gradual and targeted module rewrites.

A. Linux Kernel Modules

The Linux kernel is composed of core functionalities along with a large

number of device drivers and configurable components. To prevent bloated
kernel images and reduce attack surfaces, Linux employs loadable kernel
modules—binary objects that can be dynamically inserted into or removed from
the running kernel. These modules, often used for device drivers, allow the
kernel to be extended without requiring a reboot or recompilation. However,
numerous studies have shown that kernel modules, especially device drivers, are
a frequent source of security vulnerabilities.

For instance, a study by Johnson et al. found that a majority of kernel

vulnerabilities are located in device drivers, and static analysis tools have
revealed that a significant portion of bugs in Android kernels also stem from
vendor driver code. Given these findings, improving the safety and reliability of
kernel modules is a high-priority objective in system security.

B. The D Programming Language

D is a statically typed, compiled systems programming language designed

to offer the performance of C with modern language features aimed at improving
safety and developer productivity. It supports both automatic memory
management via a garbage collector and manual memory control using C-style
malloc and free. D introduces several enhancements over C, including array
bounds checking, stricter type safety, safe function annotations (@safe), and
automatic initialization of variables.

It also separates the concepts of arrays and pointers, reducing errors

related to memory access. Importantly, D supports a better C compilation mode
that disables features requiring the D runtime while retaining key safety benefits,
enabling compatibility with environments like the Linux kernel that cannot use
garbage collection or rely on a standard runtime. Through its support for
interoperability with C (including ABI compatibility and linker
integration), D is a practical candidate for rewriting critical C components such
as kernel modules, with the potential to significantly reduce vulnerabilities
without sacrificing performance.

1.1 BACKGROUND AND MOTIVATION

The Linux kernel is at the heart of many computing systems, from high-
performance servers and cloud infrastructure to smartphones and embedded
devices. Its widespread adoption is due in part to its performance, scalability,
and open-source development model. However, the kernel is mostly written in
the C programming language—a language originally designed for flexibility and
speed rather than safety. C allows low-level memory manipulation through
pointers, lacks bounds checking for arrays, and permits unsafe type casting.
These features, while powerful, are also responsible for introducing critical
security vulnerabilities such as buffer overflows, use-after-free errors, and
dangling pointers.

Given that the Linux kernel operates in a privileged mode, any

vulnerability within it can grant attackers complete control over the system,
leading to data breaches, system crashes, or unauthorized access. Despite the
introduction of security hardening mechanisms like Kernel Address Space Layout
Randomization (KASLR) and stack protection, memory safety remains an
unsolved problem. To address this issue, researchers and developers have
started investigating the use of safer programming languages for kernel
development.

The motivation behind this project is to evaluate whether the D

programming language—a modern systems-level language designed with safety,
performance, and C compatibility in mind—can be effectively used to develop
Linux kernel modules. D offers built- in features such as array bounds checking,
safe function annotations, strict type enforcement, and memory-safe slices, all of
which contribute to reducing common security issues. By exploring the
integration of D into the kernel development process, this project aims to
enhance kernel security without introducing significant performance penalties or
development complexity.

1.2 PROBLEM STATEMENT

Linux kernel modules are extensions to the kernel that enable it to support
additional hardware or software functionality at runtime. These modules, often
written in C, share the same execution privileges as the kernel itself. As a result,
bugs in module code can have catastrophic consequences, such as crashing the
entire system or exposing it to security
threats. The C language, despite its advantages in performance and low-level
access, is inherently unsafe due to the lack of built-in protection mechanisms
against memory errors.

Static and dynamic analysis tools have been developed to mitigate these
risks, but they are limited in their ability to detect or prevent all bugs, especially
those related to pointer misuse, type casting, and manual memory management.
The core problem is that the language in which the kernel is written does not
inherently support safety, making even well- intentioned and experienced
developers prone to introducing vulnerabilities.

This project addresses the fundamental question: Can we rewrite Linux

kernel modules using a safer, modern programming language like D without
compromising on compatibility, performance, or development feasibility?
Specifically, the challenge lies in replacing C with D in a critical system
component while maintaining interoperability with the existing kernel
infrastructure and achieving security and performance improvements.

1.3 OBJECTIVE OF THE PROJECT

The main objective of this project is to investigate the feasibility and

benefits of using the D programming language to develop Linux kernel modules,
with a focus on enhancing security and reducing vulnerabilities caused by unsafe
memory operations. To achieve this, the project undertakes several specific
goals. First, it aims to select and port a real-world Linux kernel module—
specifically, the virtio_net network driver—from C to D. This module was chosen
due to its medium size, active maintenance, and ease of benchmarking using
standard network tools.

Second, the project aims to assess the security improvements gained by

using D’s safety features such as array bounds checking, @safe annotations, and
memory-safe slices. Third, the project evaluates the performance of the D-based
module in comparison to its C counterpart under similar workloads and system
configurations, to ensure that enhanced safety does not come at a high
performance cost. Fourth, the project addresses the practical challenges of
integrating D code into the Linux kernel build system, which is inherently
designed for C.

This includes establishing a methodology for linking D object files,

handling language interoperability, and managing constraints like the absence of
a standard C library in kernel space. Finally, the project aims to develop a
repeatable methodology and provide documentation and tools that can be
reused to port other kernel modules in the future, paving the way for broader
adoption of memory-safe programming in kernel development.
 CHAPTER 2

LITERATURE SURVEY
The development of Linux kernel modules using the C programming
language has long been associated with significant safety and security
challenges due to C's lack of built-in protections against common programming
errors such as buffer overflows, null pointer dereferences, and use-after-free
bugs. These vulnerabilities are particularly critical in kernel space, where errors
can lead to complete system compromise. Various efforts have been made to
address these issues, including the use of runtime checks and static analysis
tools, but they offer only partial solutions. Recent research has explored the use
of safer programming languages for kernel development.

Rust, for example, has garnered attention for its memory safety features
and is being gradually integrated into the Linux kernel through the Rust-for-Linux
initiative. However, this integration is complex and ongoing. In contrast, the D
programming language offers a compelling alternative with its C-like syntax,
strong type system, memory safety features, and native performance. The paper
"Safer Linux Kernel Modules Using the D Programming Language" demonstrates
the feasibility of using D for kernel module development by successfully porting
the virtio_net network driver.

This work highlights the benefits of D’s features, such as array bounds
checking, safe functions, and template-based metaprogramming, showing that
these improvements can be achieved with negligible performance overhead.
Compared to earlier approaches like SafeDrive, Nooks, or CCured, the use of D
offers a balanced trade-off between safety, compatibility, and performance. As
such, this research contributes a practical methodology for enhancing kernel
module safety and sets a foundation for broader adoption of safer languages in
systems programming.
 CHAPTER 3

KERNEL MODULE USING D LANGUAGE

3.1 Proposed Method

To enhance the security and reliability of Linux kernel modules, the

proposed method involves incrementally porting modules from C to the D
programming language. This method maintains compatibility with existing kernel
infrastructure while introducing memory safety and modern programming
features offered by D. The methodology consists of several key stages: selecting
an appropriate module, porting data structures, translating functions, integrating
D code into the Linux kernel, applying safety features, and validating
performance and correctness.

This incremental porting approach offers significant advantages in

improving the overall security posture of the Linux kernel. By leveraging D’s
built-in memory safety features such as bounds checking, garbage collection,
and immutable data types, the likelihood of common vulnerabilities like buffer
overflows, use-after-free, and memory leaks is substantially reduced.
Furthermore, D’s modern language constructs, including stronger type inference,
contract programming, and built-in unit testing, facilitate writing more
maintainable and robust kernel code. Importantly, the gradual migration strategy
ensures that existing C-based kernel modules remain operational during the
transition, allowing developers to validate functionality step-by-step without
risking system stability.

However, this methodology also presents several challenges that must be

carefully managed. The integration of D modules into the Linux kernel requires
modifications to the build system and careful management of inter-language
calling conventions to maintain compatibility with existing C components.
Additionally, D’s runtime features, such as its garbage collector, must be
adapted or restricted to meet the strict performance and real-time requirements
of kernel-space execution. Thorough testing and benchmarking are essential to
ensure that the introduction of D code does not degrade kernel performance or
introduce new sources of bugs. Despite these challenges, this hybrid approach
provides a promising pathway toward modernizing kernel development while
preserving the stability and compatibility that Linux users depend on.
3.2 Selection of Kernel Module

The first step in the method is the selection of a suitable kernel module to
serve as a proof of concept. The authors chose the virtio_net driver, a virtual
network device driver used in paravirtualized environments. This driver meets
three important criteria: it is actively maintained in the Linux mainline tree, it is
easy to test and benchmark using standard networking tools like iperf3 and ping,
and it has a moderate codebase size (approximately 3,300 lines), making it
practical for a full manual port without being too simplistic.

3.3 Porting Data Structures

The next step involves porting the driver’s data structures from C to D
while preserving exact memory layout and alignment. This is essential to ensure
binary compatibility with the rest of the kernel, which remains written in C. The
memory layout is validated by comparing field offsets using D’s offsetof property
against C’s offsetof() macro. Special considerations are taken when dealing with
C features that D lacks, such as zero-sized structs or bitfields.

These are handled by introducing workarounds—adding dummy fields or

using D’s std.bitmanip.bitfields module. Although tools like dpp can automate
header translation, the authors opted for manual porting due to complications
with deeply nested header inclusions in the Linux kernel.

3.4 Function-by-Function Translation

Following the structural translation, the implementation is ported

incrementally on a function-by-function basis. Each C function is translated into
its D equivalent, compiled, and tested independently to ensure correctness and
isolate bugs early. Functions exposed to the kernel or other C components are
marked with the extern(C) linkage attribute to match C calling conventions.

Additionally, global variables in D are by default placed in thread-local

storage, unlike in C. To replicate C behavior, such variables are annotated with
gshared in D. These measures ensure that the compiled D code interacts
seamlessly with the C-based kernel environment.
3.5 Integrating D Code into the Kernel

Since the Linux kernel build system is tailored for compiling C code,
integrating D requires adaptations. The D source files are compiled separately
using the -betterC flag, which disables the D runtime and restricts the language
to features compatible with kernel space, such as static typing and safety
checks. The resulting object files are renamed with a
.o_shipped suffix so the kernel build system can link them like precompiled
binaries.

A thin C interface layer is used to define the module’s entry and exit
points and to expose essential C macros or functions not portable to D. This
hybrid build setup allows for a clean integration of D modules within the Linux
kernel without disrupting its architecture.

3.6 Safety Enhancements with D Features

Once basic functionality is verified, the D code is progressively enhanced

using the language’s built-in safety mechanisms. Static arrays in D include
bounds checking by default, which helps prevent buffer overflows. Dynamically
allocated arrays are converted into slices, which store both pointer and length
metadata, enabling safe and bounds-checked access.

Functions are annotated with @safe to enforce compile-time validation of

unsafe operations like pointer arithmetic, while @trusted is used when manual
validation is needed for interoperability. The authors also replace generic void*
pointers and macros with D templates, which provide compile-time type safety
and eliminate unsafe casting. These changes dramatically reduce the chances of
memory corruption and undefined behavior.

3.7 Validation and Benchmarking

Finally, the ported driver is tested and benchmarked to ensure it meets

performance and correctness criteria. A controlled setup is used to compare the
D and C versions of the virtio_net driver in scenarios such as VM-to-VM and VM-
to-host communication using iperf3. The results show that the D version achieves
equivalent performance with negligible overhead.

Safety is validated by introducing artificial out-of-bounds errors—while the

C version allows silent failures or unpredictable behavior, the D version halts
execution via kernel panic in 100% of test cases due to its bounds checks.
Additionally, 88.4% of array accesses in the D version are bounds-checked, 19%
of functions are @safe without modification, and 56% of void* uses are replaced
with type-safe templates.
 CHAPTER 4

IMPLEMENTATION OF D MODULE
The implementation of the proposed method involved a practical
application of the step-by-step porting strategy to the virtio_net Linux kernel
module. This process required careful preparation and technical adaptation to
ensure compatibility between the D language and the Linux kernel’s C-based
environment.

4.1 Development Environment

The development environment consisted of QEMU-based virtual machines

running Linux kernel version 4.19.0. This specific kernel version was chosen for
its stability and wide support. Each VM was allocated 1 GB of RAM and one
virtual CPU core, providing a standard and repeatable testing ground. The host
machine was configured with appropriate networking and virtualization support,
and tools such as Minicom were used to interact with VMs via serial connections.
The D compiler used was GDC version 10.3.0, which supports the -betterC
compilation mode necessary to build D code compatible with the Linux kernel.

4.2 Compilation and Build System Integration

Since the Linux kernel build system is designed to work with C source files,
integrating D code required specific adjustments. D source files were compiled
independently using the - betterC flag, disabling the D runtime and enforcing a
subset of the language suitable for kernel- space development. The resulting
object files were renamed with the .o_shipped suffix, which allowed the kernel
build system to treat them as precompiled binaries and link them seamlessly
with the rest of the kernel module. A minimal C interface file was created to
handle module initialization and cleanup functions, as well as to bridge any
macros or C-specific functionalities not portable to D.

4.3 Function and Structure Porting

Porting began with the translation of all required data structures. These
were carefully rewritten in D to ensure binary compatibility with their C
counterparts by matching memory layout and field offsets. Alignment was
validated using the .offsetof operator in D and the
offsetof() macro in C. Following structure porting, individual functions from the
original C module were translated to D incrementally.

After each function was ported, the module was recompiled and tested to
verify correctness. This incremental strategy helped isolate bugs and maintain
consistent behavior throughout the porting process. Global variables in D were
annotated with gshared to replicate C’s memory model, and function linkage
was defined using extern(C) to ensure compatibility with kernel expectations.

4.4 Code Enhancement with D Features

After achieving basic functionality, the D-based code was enhanced using
the language’s memory safety features. Static and dynamic arrays were
wrapped with bounds checking using D slices, and functions were annotated with
@safe or @trusted depending on the safety guarantees they could provide.
Additionally, void* pointers were replaced with type- safe templates where
applicable, enhancing compile-time type safety and reducing reliance on unsafe
casting.

Building on these safety enhancements, rigorous testing and validation

processes were implemented to ensure both functional correctness and
performance parity with the original C modules. Unit tests, combined with kernel
integration tests, verified that the D code maintained expected behavior under
various workloads and edge cases.

Performance benchmarks were conducted to identify any overhead

introduced by the added safety checks, allowing targeted optimizations such as
selective use of @trusted annotations to balance safety and efficiency. This
iterative refinement not only strengthened the reliability of the module but also
demonstrated that modern language features could be integrated into kernel
development without compromising system responsiveness.
 CHAPTER 5

EXPERIMENT SETUP
To assess the functionality, safety, and performance of the ported driver, a
detailed experimental setup was configured. The experiments were designed to
compare the D-based virtio_net driver against the original C version under
controlled and identical conditions.

5.1 System Configuration

Two virtual machines were used for the experiments. Each VM was
allocated 1 GB of RAM and a single CPU core. The Linux kernel running on each
VM included either the original C version of the virtio_net driver or the new D
version. A third system (either the host or another VM) was used for remote
performance evaluation. The kernel modules were dynamically loaded into the
VMs, and test scripts automated tasks such as setting up IP configurations,
routing tables, and downloading test files.

5.2 Testing Tools and Scenarios

The evaluation included both functional and performance testing.

Functional correctness was verified using tools like ping for basic connectivity
and wget to download files over the network. The integrity of the downloaded
data was confirmed using md5sum to match checksums. For performance
benchmarking, the tool iperf3 was used to measure bandwidth in multiple
configurations: VM-to-VM, VM-to-host, and VM-to-remote. Each scenario was
tested with both TCP and UDP protocols to capture a wide range of usage cases.
This setup allowed for consistent and comparable performance data collection
across all scenarios.
 CHAPTER 6

RESULTS AND

DISCUSSION
The results demonstrated that the ported D kernel module not only
maintained functional parity with the original C version but also introduced
measurable safety benefits with negligible performance impact.

6.1 Functional Correctness

The D-based virtio_net driver passed all functionality tests. It successfully

handled network communication, responded to ping commands, and downloaded
test files accurately with wget. The downloaded files matched expected
checksums, confirming correct data transmission and reception.

6.2 Safety Improvements

The D implementation significantly enhanced memory safety. Static arrays

were protected by built-in bounds checking, while dynamically allocated arrays
were safely accessed using D slices. Artificial out-of-bounds errors were
deliberately introduced into the driver to test the effectiveness of these safety
mechanisms. The C version often failed silently or caused undefined behavior,
while the D version triggered a kernel panic in 100% of such cases,
demonstrating that the D language’s safety checks were functioning as intended.

Overall, 88.4% of array accesses were protected by bounds checks, 19%

of functions were successfully annotated as @safe, and 56% of void* usages
were replaced with type- safe templates.

6.3 Performance Evaluation

In terms of performance, the D driver showed no significant degradation

compared to the C version. Across all configurations—VM-to-VM, VM-to-host, and
VM-to-remote— throughput values measured with iperf3 were comparable. In
some cases, the D driver even slightly outperformed the C driver, though
such differences were attributed to network
 variability rather than code efficiency. These results indicate that the additional
safety checks introduced by the D language do not introduce measurable runtime
overhead in this context.

6.4 OUTPUT

Fig 6.1: Kernel Module Using C Language

Fig. 1 represents the runtime error detected by AddressSanitizer while

executing the compiled binary of the program kernel.c. The error shown is a
heap-buffer-overflow, which indicates that the program attempted to write data
beyond the allocated memory boundary of a heap-allocated buffer. Specifically, a
10-byte region was allocated, but the program attempted to access memory just
beyond this region, leading to undefined behavior. AddressSanitizer caught this
issue and provided detailed diagnostic information, including the memory layout,
redzone violations, and stack trace pointing to the exact location in the source
code (use_buffer function at line 16 of kernel.c). This helps in quickly identifying
and correcting the out-of-bounds memory access error.
 Fig 6.2: Kernel Module using D language

Fig. 2 illustrates a runtime exception encountered during the execution of

the kernelD program. The error, ArrayIndexError, clearly indicates an attempt to
access index [10] in an array of length 10, which is out of bounds since valid
indices range from 0 to 9. This exception is caught and reported by the D
programming language runtime, which prevents undefined behavior by throwing
a descriptive error. The stack trace provided in the terminal output helps identify
the exact function (useBuffer) and source file (kernelD.d) where the invalid
access occurred, enabling easier debugging and correction of the array indexing
logic.
 Fig 6.3: TCP performance for C and D language

Fig. 3 presents a comparative analysis of TCP performance measured in

terms of bandwidth (Gbit/sec) for three scenarios: vm-to-vm, vm-to-host, and
vm-to-remote. The performance is compared between two different
implementations or configurations, labeled C (in purple) and D (in green). The
graph shows that both C and D achieve similar high bandwidth (around 2.6
Gbit/sec) in the vm-to-vm and vm-to-host cases, indicating efficient local and
inter-VM communication. However, in the vm-to-remote scenario, the bandwidth
drops significantly for both configurations (around 1 Gbit/sec), suggesting a
network bottleneck or increased latency over external communication. This
figure effectively highlights the impact of system configuration and network
scope on TCP throughput.
 Fig 6.4: Vulnerability from 2000 to 2020

Fig. 4 displays the number of CVE (Common Vulnerabilities and Exposures)

reports filed per year, highlighting the growing concern over software and
system vulnerabilities. The x-axis represents the years from 1999 to 2019, while
the y-axis indicates the number of CVEs reported annually. The trend shows a
dramatic increase starting around 2017, where reported CVEs surged from about
6,000 to over 14,000. This escalation could be attributed to heightened
awareness, improved reporting mechanisms, or an actual increase in
vulnerabilities due to the expanding attack surface in modern digital
infrastructure. The figure underscores the rising importance of cybersecurity in
contemporary computing environments.
 Fig 6.5: Vulnerability of C and D language from 2020 to 2025

Fig. 5 represents the comparative analysis of kernel vulnerabilities

identified in systems C and D between the years 2020 and 2025. The x-axis
denotes the year-wise timeline, while the y-axis quantifies the number of kernel
vulnerabilities reported each year. The red line indicates vulnerabilities in system
C, and the green line corresponds to system D. The trend shows a sharp increase
in both systems during 2023, with system C peaking at 9 vulnerabilities and
system D at 8 vulnerabilities, indicating a likely rise in kernel-level exposure or
increased detection efforts during that period. After a significant drop in 2024,
the count rises again for system C in 2025, possibly reflecting emerging threats
or code regressions. This figure helps illustrate the evolving nature of kernel
security issues and the differences in vulnerability trends across the two
systems.
 Fig 6.6:Runtime Security Capabilities: Buffer Overflow Detection vs. Tool Dependency

Fig. 6 compares the buffer overflow detection capability and the

requirement for external tools in systems C and D. The left bar chart shows that
system D successfully detected a buffer overflow at runtime (value = 1). In
contrast, system C failed to detect it (value
= 0), indicating that system D has built-in mechanisms for runtime vulnerability
detection. The right bar chart highlights that system C required an external tool
for vulnerability detection (value = 1), while system D did not (value = 0),
demonstrating that system D is more self- sufficient in handling security checks.
These results emphasize the stronger internal security features and automation
present in system D compared to system C.
 CHAPTER 7

CONCLUSION
This research presents a promising and practical approach to improving
the security of the Linux kernel by leveraging the D programming language as a
safer alternative to C for writing kernel modules. Through the successful porting
of the virtio_net driver, the authors demonstrate that it is not only feasible but
also highly beneficial to incrementally integrate memory-safe code into an
otherwise C-based kernel environment.

The D programming language offers several advantages, such as array

bounds checking, safer pointer handling, and compile-time function safety
annotations, which significantly reduce the risk of common memory-related
vulnerabilities. Importantly, the study proves that these security benefits can be
achieved without incurring any noticeable performance overhead, preserving the
efficiency expected from system-level code.

The methodology outlined in this work—including the use of the -betterC

compilation mode, careful interfacing between C and D code, and performance
benchmarking—serves as a replicable blueprint for porting other Linux kernel
modules. The authors also highlight that developers familiar with C can easily
transition to D due to its syntactic similarity, making this approach practical and
scalable.

In conclusion, this work demonstrates that introducing memory-safe

languages into kernel development is not only desirable but also achievable
today. It sets the stage for broader adoption of safer programming practices in
operating system development and offers a path forward for building more
robust, secure, and maintainable system software.

Furthermore, this research opens up new avenues for future exploration,

such as extending the incremental porting approach to other critical kernel
subsystems and exploring the integration of additional modern language
features to enhance developer productivity and code quality. It also encourages
the Linux kernel community to reconsider long-standing assumptions about
language choices in system programming, potentially inspiring further
innovations that balance safety, performance, and compatibility.

By demonstrating a concrete example of successful migration and

coexistence between C and D, this work lays the groundwork for a gradual
evolution of kernel codebases toward more secure and maintainable
implementations without sacrificing the proven reliability that users and
developers rely on.
 BIBILIOGRAPHY

[1] Love, R. (2010). Linux kernel development (3rd ed.). Addison-Wesley.

[2] Bovet, D. P., & Cesati, M. (2005). Understanding the Linux kernel (3rd ed.).
O'Reilly Media.

[3] Tanenbaum, A. S., & Bos, H. (2015). Modern operating systems (4th ed.).
Pearson.

[4]Sutter, H., & Alexandrescu, A. (2004). C++ coding standards: 101 rules,

guidelines, and best practices. Addison-Wesley.

[5] Alexandrescu, A. (2010). The D programming language. Addison-Wesley.

[6] Rust-for-Linux Project. (2023). Rust in the Linux kernel.

[7] Regehr, J. (2020). A guide to undefined behavior in C and C++.

[8] Kerrisk, M. (2010). The Linux programming interface. No Starch Press.

[9] McKusick, M. K., & Neville-Neil, G. V. (2005). The design and

implementation of the FreeBSD operating system. Addison-Wesley.

[10] Cimpian, E., & Oancea, C. E. (2022). Safe kernel extensions: Lessons from

Rust and D. Journal of Systems Programming, 48(2), 133–145.

[11] IEEE. (2020). IEEE standard for information technology—POSIX base

specifications.

IEEE Std 1003.1.

[12] CVE Details. (2024). Linux kernel vulnerabilities.

[13] Fraser, T., Badger, L., & Felten, E. W. (2002). Hardening C applications with
SafeDrive.

Proceedings of the USENIX Security Symposium, 89–104.

[14] Anonymous. (2025). Safer kernel modules in D programming language

[Unpublished project report]. PSG College of Technology.