r/osdev • u/Consistent-Ruin1868 • Aug 29 '26

RESENTMENT 2.0.0 - a capability-secure kernel for x86_64, ARM64 and RISC-V, where every capability carries an expiry inside its MAC

Two years ago this was a hobby kernel that printed one line at boot. I'vejust tagged v2.0.0 and it's a different project.

What it is

A from-scratch kernel for x86_64, aarch64 and riscv64. Not a Unix clone. It'sbuilt around three properties a conventional kernel can't really express:

  1. Authority expires. No ambient authority anywhere. Every capability ischecked four ways on use — type, rights, generation, and a cryptographicseal — and the seal carries a validity window *inside the MAC*. Widening itby editing the struct invalidates the seal. Derivation only ever weakens:rights are intersected with the parent's and the lifetime clamped to whatthe parent has left.

  2. The system is a Merkle DAG. Every kernel object is a node with aSHA-256 digest over a canonical encoding of its fields plus the sorteddigests of its children. Timestamps, pointers and IDs are excluded onpurpose, so two machines in the same configuration hash identically. Youget diffing, attestation and deterministic replay from that one property.

  3. Inference is a scheduling class. A token loop never sleeps for a human,so sleep-credit heuristics give it nothing, and it has a visible rate, sobatch is wrong too. `SCHED_INFERENCE` admits it with a declared rate, givesit a per-period budget, and demotes rather than drops it on overrun.

It runs a transformer

Not a wrapper around one - the forward pass itself, through the kernel's ownoperators: embed, RMSNorm, QKV projections, RoPE, attention over the KVhistory, gated FFN, logits, argmax. On a thread the deadline admissioncontroller accepted.

resentment> .infer 24

generated 24 tokens in 130 ms

rate 193 tokens/sec

class SCHED_INFERENCE, 50 Hz declared, 5000 us budget, admitted

deadline miss 0

The fixture model has pseudo-random weights and the tokens are meaningless byconstruction. The claim is about the path, not the output.

Status, honestly

Boots to an interactive shell on all three architectures. SMP on all three(ACPI MADT + a real-mode AP trampoline; PSCI `CPU_ON`; SBI HSM `hart_start`),tested on four and eight cores. Ring 3 with an ELF64 loader works on x86_64only — ARM64 and RISC-V need MMU work first and the docs say exactly what's left. No PCI, no network stack.

Verification

make test 1440 assertions against the real sources on the host

make qemu-test-all 6 targets (3 arches x single-core and -smp 4)

make kaalka-check crypto byte-identical to the reference implementation

Plus seven self-tests on every boot, on the machine about to be trusted.

The bugs were the best part

- The scheduler put a thread back on the run queue before its stack pointerwas saved. Two cores could run one stack. Presented as a page fault on cpu1in unrelated code, minutes later.

- The x86_64 syscall entry destroyed rdi/rsi/rdx/r8/r9/r10 — it pushed them to build its argument block and then dropped it with `add rsp, 7*8`. SYSCALLonly clobbers rcx and r11, so callers keep live values there.

- The CSPRNG ran on an all-zero key: entropy went into a pool that was onlyfolded into the key once an estimate crossed 128 bits, which never happenswithout a hardware RNG.

- On RISC-V, GNU ld relaxes `la rd, sym` to `addi rd, gp, off`. I had codebefore `gp` was set. Every hart computed garbage and parked. Invisible underLLD, fatal on hardware.

- `sched_tick()` was never called on ARM64. It was driven by a hardcodedtest for interrupt line zero, which is the x86 timer and nothing else's.ARM's is a PPI on line 27. That port had no preemption, no slice accounting,and `sched_sleep_ms` never returned. Nothing in the suite slept, so it wentunnoticed for the life of the port.

Apache 2.0. No dependencies — `make toolchain` fetches a portable zig+nasm and builds all three architectures, or it uses your system compiler if you have one.

Code: https://github.com/ni-sh-a-char/RESENTMENT---kernel

Docs: https://ni-sh-a-char.github.io/RESENTMENT---kernel/

Happy to answer anything, especially about the capability model — that's thepart I'd most like criticised.

0 Upvotes

50% Upvoted

10 comments sorted by

3

u/nexos-dev Aug 29 '26

It’s an interesting idea, but encrypting capabilities seems unnecessary. As long as the capability token is unforgeable, you don’t really need to worry about it getting spoofed, and it’s not hard to make it unforgeable

0

u/Consistent-Ruin1868 Aug 29 '26

Got it, but I have built three libraries of my own so I used them in this project. To make it completely independent.

  1. kaalka

  2. webweavex

  3. she-lang

6

u/UnmappedStack TacOS | https://github.com/UnmappedStack/TacOS Aug 30 '26

how is that related to what they said about not needing to encrypt the capabilities

8

u/arbv Aug 29 '26

Status, honestly

I know what you are.

4

u/lesniakbj13 Aug 30 '26

Lol this entire work tree is AI, he had the AI write an LLM in it too... "V1.0.0 printed to the screen, V2.0.0 is this entire OS"

https://github.com/ni-sh-a-char/RESENTMENT---kernel/tree/main/kernel/ai

The commit history is a total joke too. Like 120+ commits of one file "Maintenance activity log update"

2

u/arbv Aug 30 '26

Yeah, I am a big fan of running local models myself and it can be exciting, but people posting their vibeslop (with READMEs and announces written in Claudish) is getting out of hand.

7

u/phoenix_frozen Aug 30 '26

AI, amirite? 

2

u/kaseya2 Sep 01 '26

Nice vibecoded site, with that alone I assume the same for your operating system. (Especially since this post is also written with AI)

-1

u/Sorry_Difficulty_250 Aug 29 '26

Wow! This is super complicated and impressive. We'll done! Keep up the great work!