Some platforms and configurations do not allow user code to change the
value of the register used for TLS. On these architectures a syscall can
be used to allow the kernel to update the register on their behalf.
This does not immediately update the value in the user context on many
configurations as the values are only stored in the user context on a
context switch.
Instead of processing each platform CMake file during the arch's
config.cmake file, we process all of the platform CMake files first.
This is primarily motivated by wanting to move platform configuration
into a config file that is processed via a -C argument to the initial
build initialisation command.
Now a platform config is responsible for setting the kernel architecture
and it's own platform/arch specific config settings. Where previously a
platform was chosen in an arch specific way via either setting
KernelARMPlatform or KernelX86Sel4Arch or KernelRiscVPlatform, a
platform can now be set by KernelPlatform. In cases where a platform may
further parameterise its configuration it is free to choose its own
config options to query. Platforms that support multiple seL4
architectures should use KernelSel4Arch to query this. Platforms that
provide sub platforms such as exynos5 and subplatforms exynos5250,
exynos5410 and exynos5422 can be selected by specifying
KernelPlatform=exynos5, KernelARMPlatform=exynos5410 for example.
The DTS compilation was arm platforms only. Moving it to the top level
config file, making it available to RISCV platforms. The generated files
are almost identical with minor differences. A new argument(--arch) is
added to the hardware_gen.py for the differences.
The previous minimum (4) was actually too small to fit more than 1
capability, which would not allow the kernel to boot. A 4K minimum means
on 32-bit, an 8 size is the minimum (256 slots) and on 64-bit, 7 (128
slots).
In addition to being a more practical minimum, this also allows for
simplification of the boot code for future commits.
Introduces a kernel option that, when enabled, reduces the kernel window in a user address
space to just be Static Kernel Image and Microstate (SKIM), instead of the full kernel
address space. This isolates the important kernel data from the user preventing a
Meltdown style attack being able to violate secrecy. The kernel text and read only data,
i.e. anything that is static from boot, is not secret and can be allowed in the SKIM window
and potentially read by the user. Additionally to switch to and from the actual kernel
address space a small amount of state needs to also be in the SKIM window.
This is only an implementation for x86-64, although the same design is applicable to ia32
TOPLEVELTYPES is not intended to be configurable by the user, rather is a reflection
on the types defined by the source. This changes the TOPLEVELTYPES argument to be
a property, allowing it to be constructed as a generator expression when generating
BF files. By being a property, and not something like a global property, it removes
the need to ensure that additions to TOPLEVELTYPES are done prior to any bitfield
target definitions.
Defines an empty custom target whose purpose is to hold properties and configuration
data that can be retrieved using generator expressions in the build phase.
Using the `INTERNAL` attribute implied `FORCE` overriding any value the user may have set
for these. This was not the intention, and they should merely set a `CACHE` value if one
does not already exist.
