It sounds like you are looking for kexec
Example from the docs:
For example, if the kernel image you want to reboot to is /boot/vmlinux, the contents of /proc/cmdline is root=/dev/hda1, and the path to the initrd is /boot/initrd, then you would use the following command to load the kernel:
kexec -l /boot/vmlinux --append=root=/dev/hda1 --initrd=/boot/...
The kernel build allows you to specify the tools you want to use; for example, to specify the C compiler, set the CC and HOSTCC variables:
make CC=clang HOSTCC=clang
The build is only expected to succeed with GCC, but there are people interested in using Clang instead, and it is known to work in some circumstances (some Android kernels are built with Clang)...
This has been taken from https://wiki.chotaire.net/vbox-test-warning-messages. Kudos to them. If it helps you, please consider visiting them and letting them know it was helpful.
The source code for Virtual Box 6.0.6 shows kernel print statements that have been accidentally left in the production release. If you're using rsyslog you can filter them out by ...
Thanks to Stephen Kitt's answer. It's possible to compile the Linux kernel with Clang. But you need Clang v9.0.
If you are using Arch Linux, there's a nice way to clang v9.0 without compiling yourself:
# Enable the testing repository (if not already enabled):
echo -e "[testing]\nInclude = /etc/pacman.d/mirrorlist" | sudo tee -a /etc/pacman.conf
You could use efibootmgr to check the number of the boot entry, BootNext (which usually contains 4 digits), and run the following command:
# efibootmgr --bootnext BootNext
• BootNext - the boot entry which is scheduled to be run on next boot. This supercedes BootOrder for one boot only, and is deleted by the boot manager after first ...
concerning "as in shutdown":
it's only almost as in shutdown: all processes including pid 1 are wiped, of course, since even the kernel is wiped out and reloaded. But some firmware stuff (EFI variables) can hang around, because kexec is not a full reboot.
If you are not (compiling and) testing one kernel after the other, kexec is of limited use. It is "...
This is a good but very difficult to answer question because it is very open.
Focusing on the "code may execute in the root namespace" part, it depends on what you mean by "code":
The userspace part should be isolated even without namespaces. I.e. all the code that you write is executed separately from everything else, regardless of namespaces
The kernel ...
A vulnerability, but not of the type you mention.
A user that can create and run an arbitrary docker container, can create a container with a mapped part of the host file-system. They can then in the container, running as root create a setuid root program on disk. Then from the host, they can run this to gain root privileges.