OpenBSD Kernel Relinking Issue

The automatic and mandatory-by-default reordering of OpenBSD kernelsis NOT transactional and as a result, a local unpatched exploit existswhich allows tampering or replacement of the kernel. Arbitrary buildartifacts are cyclically relinked with no data integrity or provenancebeing maintained or verified for the objects being consumed withrespect to the running kernel before and during the execution of themandatory kernel_reorder process in the supplied /etc/rc and/usr/libexec scripts. The reordering occurs at the end of installationprocess and also automatically every reboot cycle thereafter unlessmanually bypassed by a knowledgable party.The kernel_reorder routine verifies a SHA256 signature for the linkedkernel from last boot but does not verify the integrity or provenanceof any objects kept in the kernel "link kit" installed in/usr/share/relink, so arbitrary objects can be injected andautomatically relinked at the next startup. I have verified that it isindeed the case that both valid kernels with a different uname andkernels which cause data destruction due to over-tuning of a subset ofthe components which were compiled manually and copied into/usr/share/relink and crash the system after being booted oncerelinked but which do not match the build of the running kernel at thetime they were copied into /usr/share/relink as workingproof-of-concept exploits.Install media are also open to tampering and exploitation as signedchecksum data are not carried with the install sets inside theinstallation image and an improperly-encapsulated poorly-documentedtarball of unverifiable (in the sense of SLSA) kernel objects isembedded in the base distribution and then relinked with a new randomordering of the objects cyclically between boot cycles.Sites with a strong security posture are advised that this is acritical vulnerability and likely deliberate back door into thesystem. Additionally, OpenBSD leaks the state of the pseudorandomnumber generator to predictable locations on disk and in system memoryat a fixed point during every start up and shutdown procedure. Thelack of build process hardening has been on-going for over threeyears. Theo de Raadt is disinterested in improving or reviewing thedesign or providing any further clarification, as he has stated on themailing list when shortfalls in the relinking process were reportedover the past ~3 years. I hope that this can come to the attention ofa third-party technical expert with standing in the computer securityindustry.Workaround:As the link kit is embedded in the base distribution and automaticallyrelinked without an option to disable it in the provided installationscript it requires manual removal at present.Cf.https://marc.info/?l=openbsd-bugs&m=159074964523007&w=2 (noted lack ofidempotency)https://marc.info/?l=openbsd-bugs&m=168688579123005&w=2 (noted lack ofintegrity or provenance verification and the consumption of invalidobjects)https://slsa.dev/spec/v1.0/levels#build-l2-hosted-build-platform:"Track/Level Requirements                 Focus Build L3       Hardened build platform      Tampering during the build"