Age | Commit message (Collapse) | Author |
|
|
|
I was working on some more KASAN changes and realized the system
no longer links when passing -DENABLE_KERNEL_ADDRESS_SANITIZER=ON.
Prekernel will likely never have KASAN support given it's limited
environment, so just suppress it's usage.
|
|
This enables further work on implementing KASLR by adding relocation
support to the pre-kernel and updating the kernel to be less dependent
on specific virtual memory layouts.
|
|
This allows us to specify virtual addresses for things the kernel should
access via virtual addresses later on. By doing this we can make the
kernel independent from specific physical addresses.
|
|
Previously the kernel relied on a fixed offset between virtual and
physical addresses based on the kernel's load address. This allows us
to specify an independent offset.
|
|
GCC and Clang allow us to inject a call to a function named
__sanitizer_cov_trace_pc on every edge. This function has to be defined
by us. By noting down the caller in that function we can trace the code
we have encountered during execution. Such information is used by
coverage guided fuzzers like AFL and LibFuzzer to determine if a new
input resulted in a new code path. This makes fuzzing much more
effective.
Additionally this adds a basic KCOV implementation. KCOV is an API that
allows user space to request the kernel to start collecting coverage
information for a given user space thread. Furthermore KCOV then exposes
the collected program counters to user space via a BlockDevice which can
be mmaped from user space.
This work is required to add effective support for fuzzing SerenityOS to
the Syzkaller syscall fuzzer. :^) :^)
|
|
This is unnecessary because the prekernel is always loaded at a known
base address.
|
|
|
|
The boot_pd0_pts variable contains more than 512 PTEs so we shouldn't
wrap the index here.
|
|
|
|
These headers are ordered by virtual address - at least with GCC - but
that might not always be the case.
|
|
The kernel would just turn those virtual addresses into physical
addresses later on, so let's just use physical addresses right from the
start.
|
|
Instead of manually redeclaring those variables in various files this
now adds a header file for them.
|
|
This copies the ELF header because we might end up overwriting when
loading the ELF sections.
|
|
Depending on the exact layout of the .ksyms section the kernel would
fail to boot because the kernel_load_end variable didn't account for the
section's size.
|
|
|
|
This implements a simple bootloader that is capable of loading ELF64
kernel images. It does this by using QEMU/GRUB to load the kernel image
from disk and pass it to our bootloader as a Multiboot module.
The bootloader then parses the ELF image and sets it up appropriately.
The kernel's entry point is a C++ function with architecture-native
code.
Co-authored-by: Liav A <liavalb@gmail.com>
|