Previously, we started parsing the ELF file again in a completely
different place, and without the partial mapping that we do while
validating.
Instead of doing manual parsing in two places, just capture the
requested stack size right after we validated it.
Once LibC is installed to the sysroot and its conflicts with libc++
are resolved, including LibC headers in such a way will cause errors
with a modern LLVM-based toolchain.
This is needed to avoid including LibC headers in Lagom builds.
Unfortunately, we cannot rely on the build machine to provide a
fully POSIX-compatible ELF header for Lagom builds, so we have to
use our own.
This has KString, KBuffer, DoubleBuffer, KBufferBuilder, IOWindow,
UserOrKernelBuffer and ScopedCritical classes being moved to the
Kernel/Library subdirectory.
Also, move the panic and assertions handling code to that directory.
As IFUNC resolvers may call arbitrary functions though the PLT, they can
only be called after the PLT has been populated. This is true of the
`[[gnu::target_clones]]` attribute, which makes a call to
`__cpu_indicator_init`, which is defined in `libgcc_s.so`, through the
PLT.
`do_plt_relocation` and `do_direct_relocation` are given a parameter
that controls whether IFUNCs are immediately resolved. In the first
pass, relocations pointing to IFUNCs are put on a worklist, while all
other relocations are performed. Only after non-IFUNC relocations are
done and the PLT is set up do we deal with these.
No functional changes intended. This is in preparation of a commit that
overhauls how IFUNCs are resolved.
This commit lets us move the implementation of PLT patching from
`DynamicObject` to `DynamicLoader` where all other relocation code
lives. For this, got[2] now stores the loader's address instead of the
object's.
This is the AArch64 equivalent of `R_X86_64_IRELATIVE`, which specifies
a symbol whose address is determined by calling a local IFUNC resolver
function.
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
Instead of using a special case of the annotate_mapping syscall, let's
introduce a new prctl option to disallow further annotations of Regions
as new syscall Region(s).
This commit adds the used relocation types to elf.h, and handles the
types in DynamicLoader and DynamicObject. No new functionalitty has to
be added, as the same code can be reused between aarch64 and x86_64.
This commit adds R_AARCH64_RELATIVE to elf.h and uses it in
ELF::perform_relative_relocations to correctly verify the relocation
type. This is the only change needed to support relative relocations for
aarch64.
A lot of places were relying on AK/Traits.h to give it strnlen, memcmp,
memcpy and other related declarations.
In the quest to remove inclusion of LibC headers from Kernel files, deal
with all the fallout of this included-everywhere header including less
things.
These instances were detected by searching for files that include
AK/Memory.h, but don't match the regex:
\\b(fast_u32_copy|fast_u32_fill|secure_zero|timing_safe_compare)\\b
This regex is pessimistic, so there might be more files that don't
actually use any memory function.
In theory, one might use LibCPP to detect things like this
automatically, but let's do this one step after another.
These instances were detected by searching for files that include
AK/Concepts.h, but don't match the regex:
\\b(AnyString|Arithmetic|ArrayLike|DerivedFrom|Enum|FallibleFunction|Flo
atingPoint|Fundamental|HashCompatible|Indexable|Integral|IterableContain
er|IteratorFunction|IteratorPairWith|OneOf|OneOfIgnoringCV|SameAs|Signed
|SpecializationOf|Unsigned|VoidFunction)\\b
(Without the linebreaks.)
This regex is pessimistic, so there might be more files that don't
actually use any concepts.
In theory, one might use LibCPP to detect things like this
automatically, but let's do this one step after another.
To further protect all virtual memory regions of the loaded libraries,
don't allow to mutate these regions both in changing their annotations
nor the protection bits.
This syscall will be used later on to ensure we can declare virtual
memory mappings as immutable (which means that the underlying Region is
basically immutable for both future annotations or changing the
protection bits of it).
Some programs explicitly ask for a different initial stack size than
what the OS provides. This is implemented in ELF by having a
PT_GNU_STACK header which has its p_memsz set to the amount that the
program requires. This commit implements this policy by reading the
p_memsz of the header and setting the main thread stack size to that.
ELF::Image::validate_program_headers ensures that the size attribute is
a reasonable value.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Employ the same hardening that glibc and the Linux kernel use for
generating stack guards: zero the first byte of the guard such that
if C-style string functions read out of bounds on the stack, we do
not overwrite or potentially leak the stack guard.
We used size_t, which is a type that is guarenteed to be large
enough to hold an array index, but uintptr_t is designed to be used
to hold pointer values, which is the case of stack guards.
Both users of this function now have to do their resolving separately
before anyways, so let's just drop the resolving part inside the
function and require absolute paths to be fed in instead.
Having two functions that are named the same and whose behavior
regarding "should probably get a full path" and "does explicitly not
require a full path" is quite confusing, especially since that
difference is dictated through the other passed arguments.
