@encthenet i guess i wasn't seeing your perspective much though too. i do actually believe it's righteous and good to do your best on crypto implementation in the corporate sphere even if you can't quite make hard mandates like i would like to here [e.g. "no attacker controlled queries" etc].
i really do feel the IETF should get more heat for that sort of thing though. one reason i started down this path a few months ago was finding a whole lot of issues with zstd https://amass.energy/rustdoc/yzx-unstable/yzx_core/frame/skippable/#privacy-risk-watermarking
@encthenet so my approach with the kernel is that scheduler control needs to be completely absolutely 100% redone. i think simply not doing any round robin that has both the attacker and the target in the same round has got to be a good start (which comes from not exposing a "round robin switching" semantics except to an immediate supervisor parent process).
but i also feel "let this run for N cycles and return" or "let this run until the ring buffer is mostly or completely filled up" are other ways to relate scheduling across processes in ways that work more like coroutines and with much less kernel work to switch around task_structs. these are another layer (not big) that i would add onto posix (i'm not implementing signals or pthreads whatsoever)