| Age | Commit message (Collapse) | Author |
|---|
|
This makes it harder for an exploit to replace the kernel's randomized
canary value since the memory containing it will be mapped read-only.
|
|
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. :^) :^)
|
|
|
|
We don't want kernel_base to be modifiable by an attacker or a stray
memory scribbler bug, so lets mark it as READONLY_AFTER_INIT.
|
|
Despite what the declaration would have us believe these are not "u8*".
If they were we wouldn't have to use the & operator to get the address
of them and then cast them to "u8*"/FlatPtr afterwards.
|
|
This also removes the section attribute for kernel_base which had no
effect because the section wasn't included in the linker script.
|
|
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.
|
|
|
|
There are a few occurrences of the old name that slipped through.
|
|
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>
|
|
Otherwise it'll use the first 32 bits that happen to come after,
leading to very weird bugs. Fixes #8601
|
|
We should initialize the timers before KernelRNG as the RNG may want
to utilize system time as an entropy source.
Fixes #8710
|
|
Without this we won't be able to detect whether .ksyms overlaps the end
of the page table we set up for the kernel image.
|
|
This adds a new section .ksyms at the end of the linker map, reserves
5MiB for it (which are after end_of_kernel_image so they get re-used
once MemoryManager is initialized) and then embeds the symbol map into
the kernel binary with objcopy. This also shrinks the .ksyms section to
the real size of the symbol file (around 900KiB at the moment).
By doing this we can make the symbol map available much earlier in the
boot process, i.e. even before VFS is available.
|
|
This re-arranges the order of how things are initialized so that we
try to initialize process and thread management earlier. This is
neccessary because a lot of the code uses the Lock class, which really
needs to have a running scheduler in place so that we can properly
preempt.
This also enables us to potentially initialize some things in parallel.
|
|
This matches the formatting used in SysFS.
|
|
Give them names that sound related to SysFS.
|
|
Give them names that sound related to SysFS.
|
|
Folders are a GUI concept, file systems have directories. :^)
|
|
|
|
|
|
Instead of just disabling interrupts and halting when entering the C++
section, just halt with a printed message indicating the error.
|
|
|
|
|
|
|
|
The new ProcFS design consists of two main parts:
1. The representative ProcFS class, which is derived from the FS class.
The ProcFS and its inodes are much more lean - merely 3 classes to
represent the common type of inodes - regular files, symbolic links and
directories. They're backed by a ProcFSExposedComponent object, which
is responsible for the functional operation behind the scenes.
2. The backend of the ProcFS - the ProcFSComponentsRegistrar class
and all derived classes from the ProcFSExposedComponent class. These
together form the entire backend and handle all the functions you can
expect from the ProcFS.
The ProcFSExposedComponent derived classes split to 3 types in the
manner of lifetime in the kernel:
1. Persistent objects - this category includes all basic objects, like
the root folder, /proc/bus folder, main blob files in the root folders,
etc. These objects are persistent and cannot die ever.
2. Semi-persistent objects - this category includes all PID folders,
and subdirectories to the PID folders. It also includes exposed objects
like the unveil JSON'ed blob. These object are persistent as long as the
the responsible process they represent is still alive.
3. Dynamic objects - this category includes files in the subdirectories
of a PID folder, like /proc/PID/fd/* or /proc/PID/stacks/*. Essentially,
these objects are always created dynamically and when no longer in need
after being used, they're deallocated.
Nevertheless, the new allocated backend objects and inodes try to use
the same InodeIndex if possible - this might change only when a thread
dies and a new thread is born with a new thread stack, or when a file
descriptor is closed and a new one within the same file descriptor
number is opened. This is needed to actually be able to do something
useful with these objects.
The new design assures that many ProcFS instances can be used at once,
with one backend for usage for all instances.
|
|
The intention is to add dynamic mechanism for notifying the userspace
about hotplug events. Currently, the DMI (SMBIOS) blobs and ACPI tables
are exposed in the new filesystem.
|
|
|
|
Clang requires that attributes declared using the bracketed
`[[attr_name]]` syntax come before those with
`__attribute__((attr-name))`.
This fixes a Clang build error.
|
|
This also removes a lot of CPU.h includes infavor for Sections.h
|
|
This does not add any functional changes
|
|
Instead, try to create the device objects in separate static methods,
and if we fail for some odd reason to allocate memory for such devices,
just panic with that reason.
|
|
|
|
Instead of initializing network adapters in init.cpp, let's move that
logic into a separate class to handle this.
Also, it seems like a good idea to shift responsiblity on enumeration
of network adapters after the boot process, so this singleton will take
care of finding the appropriate network adapter when asked to with an
IPv4 address or interface name.
With this change being merged, we simplify the creation logic of
NetworkAdapter derived classes, so we enumerate the PCI bus only once,
searching for driver candidates when doing so, and we let each driver
to test if it is resposible for the specified PCI device.
|
|
There are a bunch of places like drivers which for all intense and
purposes can't really fail allocation during boot, and if they do
fail we should crash immediately.
This change adds `KString::must_create_uninitialized(..)` as well as
`KString::must_create(..)` for use during early boot initialization of
the Kernel. They enforce that they are only used during early boot.
|
|
This adds the -t command-line argument for the profile tool. Using this
argument you can filter which event types you want in your profile.
|
|
This simple driver simply finds a device in a device definitions list
and then sets up a SerialDevice instance based on the definition.
The driver currently only supports "WCH CH382 2S" pci serial boards,
as that is the only device available for me to test with, but most
other pci serial devices should be as easily addable as adding a
board_definitions entry.
|
|
|
|
We now initialize the PCI Bus as early as possible, to allow for
early boot (PCI based) serial logging.
|
|
This will ensure we will get all the kernel log on the second tty.
|
|
|
|
As we removed the support of VBE modesetting that was done by GRUB early
on boot, we need to determine if we can modeset the resolution with our
drivers, and if not, we should enable text mode and ensure that
SystemServer knows about it too.
Also, SystemServer should first check if there's a framebuffer device
node, which is an indication that text mode was not even if it was
requested. Then, if it doesn't find it, it should check what boot_mode
argument the user specified (in case it's self-test). This way if we
try to use bochs-display device (which is not VGA compatible) and
request a text mode, it will not honor the request and will continue
with graphical mode.
Also try to print critical messages with mininum memory allocations
possible.
In LibVT, We make the implementation flexible for kernel-specific
methods that are implemented in ConsoleImpl class.
|
|
Like in 8cd5477e54a19d5476e9a31d0677e58c9a4ce12d, we need to expand the
kernel slot again to be able to boot again.
|
|
This change will help to distinguish between the console
device and the Console abstraction layer in the Graphics
subsystem later.
|
|
This new subsystem is replacing the old code that was used to
create device nodes of framebuffer devices in /dev.
This subsystem includes for now 3 roles:
1. GraphicsManagement singleton object that is used in the boot
process to enumerate and initialize display devices.
2. GraphicsDevice(s) that are used to control the display adapter.
3. FramebufferDevice(s) that are used to control the device node in
/dev.
For now, we support the Bochs display adapter and any other
generic VGA compatible adapter that was configured by the boot
loader to a known and fixed resolution.
Two improvements in the Bochs display adapter code are that
we can support native bochs-display device (this device doesn't
expose any VGA capabilities) and also that we use the MMIO region,
to configure the device, instead of setting IO ports for such tasks.
|
|
GCC with -flto is more aggressive when it comes to inlining and
discarding functions which is why we must mark some of the functions
as NEVER_INLINE (because they contain asm labels which would be
duplicated in the object files if the compiler decides to inline
the function elsewhere) and __attribute__((used)) for others so
that GCC doesn't discard them.
|
