Development #178
Development #178
Conversation
WalkthroughThe PR bumps project version to 0.0.2.4 and expands the project DESCRIPTION to list C/C++ Assembly Rust. CMake changes: standardized toolchain messaging, removed automatic CMAKE_BUILD_TYPE initialization, added executable build dependencies, and removed two Cerberus CMake options; stack-protector flag changed to -fstack-protector-all. README and docs update build flows and prerequisites. Kernel changes: larger preallocated pools for spinlocks/MCS nodes; scheduler refactor introducing Scheduler Integrated Security (SIS), per-process locks, atomic runqueue/state updates, and a new sis_seal field in the PCB; IPC no longer calls Yield after blocking; Cerberus VFS logging and threat reporting removed; compositor returns early if VBE uninitialized. Poem
Pre-merge checks❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
kernel/atomic/rust/src/ffi.rs (3)
41-48: Restore spinlock free-loop bounds before merging.
rust_spinlock_freestill scans only the first 64 entries even though the storage/usage arrays were expanded to 256. Any spinlock allocated in indices ≥64 will never be marked reusable, so after 64 allocations the pool is permanently exhausted and subsequent callers receive null. Please update the loop bound (and ideally share a constant) so we actually visit all 256 slots.- for i in 0..64 { + for i in 0..256 { if &mut SPINLOCK_STORAGE[i] as *mut SpinLock == lock { SPINLOCK_USED[i] = false; break; } }
138-146: Fix MCS lock free bounds to match the new pool size.
rust_mcs_lock_freestill iterates0..32, so any lock allocated from slots ≥32 can never be freed, eventually exhausting the enlarged pool. Bump the loop limit to 128 (and ideally dedupe via a constant) so locks are actually returned to the allocator.- for i in 0..32 { + for i in 0..128 { if &mut MCS_LOCK_STORAGE[i] as *mut McsLock == lock { MCS_LOCK_USED[i] = false; break; } }
166-173: Allow all 512 MCS nodes to be freed.After increasing
MCS_NODE_STORAGEto 512 entries, the free path still walks only the first 128. Nodes handed out from indices ≥128 stay marked in use forever, eventually preventing new node allocations. Please update the loop bound accordingly.- for i in 0..128 { + for i in 0..512 { if &mut MCS_NODE_STORAGE[i] as *mut McsNode == node { MCS_NODE_USED[i] = false; break; } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (6)
CMakeLists.txt(3 hunks)README.md(3 hunks)docs/DEVELOPMENT.md(1 hunks)kernel/atomic/rust/src/ffi.rs(4 hunks)kernel/sched/EEVDF.c(22 hunks)kernel/sched/EEVDF.h(1 hunks)
🧰 Additional context used
🧠 Learnings (33)
📓 Common learnings
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 101
File: kernel/etc/Shell.c:829-837
Timestamp: 2025-08-31T07:06:37.003Z
Learning: assembler-0 is working on optimizing ramfs performance in VoidFrame kernel and wants to implement proper filesystem characteristics like faster lookups, better memory management, and advanced features like copy-on-write and caching.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 132
File: arch/x86_64/syscall/Syscall.c:12-19
Timestamp: 2025-09-19T11:55:43.328Z
Learning: In the VoidFrame kernel project, assembler-0 is implementing basic POSIX-compliant syscalls in ring 0 without user/kernel memory protection, prioritizing getting basic functionality working before adding full security features.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 82
File: kernel/process/Process.h:0-0
Timestamp: 2025-08-14T02:11:27.395Z
Learning: In VoidFrame kernel, FastMemcpy was using SSE2 movdqu instructions without preserving XMM registers, causing crashes when called from interrupt context (like the scheduler's FastSchedule function). The fix is to use only general-purpose registers with 64-bit unrolled copies to maintain performance while being interrupt-safe.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: The VoidFrame kernel has critical issues with PID allocation - it uses a simple incrementing counter without recycling freed PIDs, causing PID 4 to become PID 5 after death instead of reusing slot 4.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 70
File: kernel/process/Process.c:1224-1228
Timestamp: 2025-08-11T09:51:32.713Z
Learning: In the VoidFrame kernel (kernel/process/Process.c), avoid using floating-point arithmetic in kernel space. Use fixed-point arithmetic instead with integer scaling (e.g., multiplying by 1000 for 3 decimal places) to avoid FPU state management overhead and potential exceptions.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 80
File: README.md:7-8
Timestamp: 2025-08-13T08:43:54.750Z
Learning: User assembler-0 is working on VoidFrame kernel with a tight deadline (2-3 days before summer ends) and specifically requested runtime safety checks similar to __stack_chk_fail but for deadlocks and other kernel issues. The kernel already has extensive safety mechanisms including stack canaries, guard pages, heap integrity checks, and process security validation.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 72
File: arch/x86_64/syscall/SyscallEntry.asm:24-30
Timestamp: 2025-08-12T01:43:39.847Z
Learning: User prefers to defer syscall implementation complexity until next year and is considering making a ring 0 kernel instead of continuing with user-mode syscall approach in the VoidFrame kernel project.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.c:691-694
Timestamp: 2025-09-02T00:55:58.224Z
Learning: The VoidFrame MLFQ scheduler has a critical bug where ProcessRuntimePath uses FormatS() which returns a static buffer, causing all processes to share the same path string. This results in process directory cleanup operations affecting the wrong directories - killing one process can delete another process's /Runtime/Processes directory because they all point to the same FormatS static buffer.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 82
File: kernel/process/Process.h:0-0
Timestamp: 2025-08-14T02:11:58.963Z
Learning: In VoidFrame kernel's FastMemcpy implementation (kernel/memory/MemOps.c), memory corruption occurs under high load due to interrupts occurring between SSE2 movdqu load and store instructions, corrupting XMM register state. The fix requires disabling interrupts around SSE operations and adding memory barriers (sfence) to ensure stores complete atomically.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 70
File: kernel/process/Process.c:1224-1228
Timestamp: 2025-08-11T09:51:51.217Z
Learning: In VoidFrame kernel, avoid using floating-point arithmetic in kernel space functions like SystemService. Use fixed-point arithmetic instead (e.g., 16.16 format with integer operations) to prevent FPU state corruption, improve performance, and ensure predictable behavior. This is especially important for system-level processes running with PROC_PRIV_SYSTEM privileges.
Learnt from: assembler-0
Repo: assembler-0/autocc PR: 33
File: include/utils.hpp:138-190
Timestamp: 2025-08-04T13:24:48.984Z
Learning: The user assembler-0 tends to create wrapper functions during refactoring and sometimes accidentally leaves duplicate implementations. They have a casual, self-aware attitude about coding mistakes and are receptive to feedback about code duplication issues.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: docs/ARCHITECHTURE.md:1-3
Timestamp: 2025-08-31T14:19:11.366Z
Learning: assembler-0 wants to implement deep fault tracing for VoidFrame kernel exceptions (Page Fault, General Protection Fault, Invalid Opcode) instead of just panicking. The current interrupt handler has complete register state available in the Registers struct (defined in arch/x86_64/cpu/Cpu.h) including RBP for stack walking, RIP for fault location, and error codes for analysis.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 72
File: arch/x86_64/syscall/SyscallEntry.asm:24-30
Timestamp: 2025-08-12T02:13:46.266Z
Learning: User assembler-0 has existing ELF infrastructure in VoidFrame kernel with Elf.h header definitions and CreateProcess() function that properly sets up process context including stack allocation, ProcessExitStub return address, and register initialization. The issue was missing ELF loader implementation, not compilation problems.
📚 Learning: 2025-09-01T05:15:45.860Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 104
File: kernel/process/Process.c:1074-1075
Timestamp: 2025-09-01T05:15:45.860Z
Learning: In the VoidFrame kernel Process.c, the ProcessRuntimePath field uses FormatS() which returns a static buffer. While technically this creates a race condition where all processes could share the same path memory, the user has tested alternatives and they cause system failures. The current implementation works reliably in practice because the path is used immediately after assignment before FormatS() is called again.
Applied to files:
kernel/sched/EEVDF.h
📚 Learning: 2025-08-14T02:11:27.395Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 82
File: kernel/process/Process.h:0-0
Timestamp: 2025-08-14T02:11:27.395Z
Learning: In VoidFrame kernel, FastMemcpy was using SSE2 movdqu instructions without preserving XMM registers, causing crashes when called from interrupt context (like the scheduler's FastSchedule function). The fix is to use only general-purpose registers with 64-bit unrolled copies to maintain performance while being interrupt-safe.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-07-16T01:04:23.790Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 47
File: kernel/core/Kernel.c:434-434
Timestamp: 2025-07-16T01:04:23.790Z
Learning: VMemAlloc() in VoidFrame kernel fails with error code -2 (VMEM_ERROR_INVALID_ADDR) due to virtual address space layout conflict where the heap start address (_bss_end + KERNEL_VIRTUAL_OFFSET + 1MB margin) exceeds VIRT_ADDR_SPACE_END (0xFFFFFFFF80000000ULL), causing VMemMap validation to fail.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-13T07:19:55.274Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 79
File: drivers/PCI/PCI.c:154-154
Timestamp: 2025-08-13T07:19:55.274Z
Learning: VMemUnmapMMIO in VoidFrame kernel should use the same page table access pattern as the working VMemUnmap function: `uint64_t* pt_table = (uint64_t*)(pt_phys + KERNEL_VIRTUAL_OFFSET);` rather than PHYS_TO_VIRT macro or identity mapping checks.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-17T08:16:43.539Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 93
File: kernel/memory/VMem.c:72-79
Timestamp: 2025-08-17T08:16:43.539Z
Learning: In VoidFrame kernel, VMemGetPhysAddr and related page table walking functions were causing panics because they assumed identity mapping existed for physical addresses < IDENTITY_MAP_SIZE (4GB), but the bootloader doesn't provide this 1:1 mapping. The fix is to remove all identity mapping assumptions and always use PHYS_TO_VIRT() for page table access in functions like VMemGetPageTablePhys, VMemMap, VMemMapHuge, VMemGetPhysAddr, VMemUnmap, VMemMapMMIO, and VMemUnmapMMIO.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-01T01:10:22.123Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: README.md:9-9
Timestamp: 2025-09-01T01:10:22.123Z
Learning: The current VoidFrame Registers struct in arch/x86_64/cpu/Cpu.h only saves basic GPRs, segment registers, and exception context (interrupt_number, error_code, rip, cs, rflags, rsp, ss). It's missing critical registers for deep fault tracing: SIMD registers (XMM/YMM/ZMM), control registers (CR0/CR2/CR3/CR4), debug registers (DR0-DR7), and extended FPU state. The struct has a "DO NOT TOUCH" comment indicating it must match interrupt ASM stack layout.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-14T02:11:58.963Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 82
File: kernel/process/Process.h:0-0
Timestamp: 2025-08-14T02:11:58.963Z
Learning: In VoidFrame kernel's FastMemcpy implementation (kernel/memory/MemOps.c), memory corruption occurs under high load due to interrupts occurring between SSE2 movdqu load and store instructions, corrupting XMM register state. The fix requires disabling interrupts around SSE operations and adding memory barriers (sfence) to ensure stores complete atomically.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-13T07:17:35.941Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 79
File: drivers/PCI/PCI.c:154-154
Timestamp: 2025-08-13T07:17:35.941Z
Learning: In VoidFrame kernel, VMemGetPageTablePhys uses a 3-level hierarchy: Level 0 = PML4->PDP, Level 1 = PDP->PD, Level 2 = PD->PT. To access Page Tables, always use level=2, not level=1.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-14T11:01:02.698Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 130
File: kernel/core/InitRD.c:25-35
Timestamp: 2025-09-14T11:01:02.698Z
Learning: In VoidFrame kernel's InitRD.c, multiboot modules should be mapped using VMemMap() with PAGE_PRESENT | PAGE_WRITABLE flags instead of VMemMapMMIO(), as the latter applies cache-disabling flags (PAGE_NOCACHE | PAGE_WRITETHROUGH) that can corrupt data when reading regular RAM content.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-09T10:31:44.439Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 58
File: drivers/VesaBIOSExtension.c:77-85
Timestamp: 2025-08-09T10:31:44.439Z
Learning: In VoidFrame kernel, process stacks are allocated using VMemAllocWithGuards() which returns virtual addresses, but TerminateProcess incorrectly uses FreePage() (which expects physical addresses) to free them, causing "Page index out of bounds" errors. The correct function to use is VMemFreeWithGuards(proc->stack, STACK_SIZE).
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-11T09:51:32.713Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 70
File: kernel/process/Process.c:1224-1228
Timestamp: 2025-08-11T09:51:32.713Z
Learning: In the VoidFrame kernel (kernel/process/Process.c), avoid using floating-point arithmetic in kernel space. Use fixed-point arithmetic instead with integer scaling (e.g., multiplying by 1000 for 3 decimal places) to avoid FPU state management overhead and potential exceptions.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-01T01:10:22.123Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: README.md:9-9
Timestamp: 2025-09-01T01:10:22.123Z
Learning: VoidFrame's interrupt handlers in arch/x86_64/interrupts/Interrupts.asm only save basic GPRs and segment registers, missing critical registers for deep fault tracing: control registers (CR0/CR2/CR3/CR4), SIMD state (XMM/YMM/ZMM), debug registers (DR0-DR7), and extended FPU state. The CPU initialization code enables SSE/AVX/XSAVE features but interrupt handlers don't preserve this extended state. Enhanced fault tracing requires selective extended state saving for critical exceptions (ISR 6, 8, 13, 14) while keeping lightweight handling for regular interrupts.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: In VoidFrame's Process.c, PIDs are allocated using `__sync_fetch_and_add(&next_pid, 1)` which only increments and never reuses freed PIDs, causing PID exhaustion after MAX_PROCESSES terminations.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: The VoidFrame kernel has critical issues with PID allocation - it uses a simple incrementing counter without recycling freed PIDs, causing PID 4 to become PID 5 after death instead of reusing slot 4.
Applied to files:
kernel/sched/EEVDF.cREADME.md
📚 Learning: 2025-09-01T08:17:56.769Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 105
File: meson.build:252-257
Timestamp: 2025-09-01T08:17:56.769Z
Learning: In VoidFrame's Cerberus security system, CerberusRegisterProcess() causes kernel panics because CerberusInstallStackCanary() performs direct memory writes (*canary_ptr = STACK_CANARY_VALUE) during process creation. The stack memory may not be fully mapped/accessible at this point, causing page faults in critical kernel context. The fix is to either defer canary installation, add memory mapping validation, or skip canary installation during process registration.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-02T01:55:54.511Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.c:691-694
Timestamp: 2025-09-02T01:55:54.511Z
Learning: In VoidFrame's Cerberus system, CerberusInstallStackCanary fails because it incorrectly calculates the canary address. VMemAllocStack returns stack_top (highest address) but the canary calculation uses stack_base + stack_size - 8, which results in an address beyond the allocated stack region. The correct canary location should be calculated as actual_stack_base + sizeof(uint64_t) where actual_stack_base = stack_top - stack_size, placing the canary just above the unmapped guard page.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-12T02:13:46.266Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 72
File: arch/x86_64/syscall/SyscallEntry.asm:24-30
Timestamp: 2025-08-12T02:13:46.266Z
Learning: User assembler-0 has existing ELF infrastructure in VoidFrame kernel with Elf.h header definitions and CreateProcess() function that properly sets up process context including stack allocation, ProcessExitStub return address, and register initialization. The issue was missing ELF loader implementation, not compilation problems.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-11T07:18:24.614Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 69
File: kernel/etc/Shell.c:82-86
Timestamp: 2025-08-11T07:18:24.614Z
Learning: The order of operations in VoidFrame's `TerminateProcess()` is critical: the process state must be set to PROC_ZOMBIE before adding to the termination queue with a memory barrier between them, otherwise CleanupTerminatedProcesses may process the entry before the zombie state is set.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: VoidFrame's TerminateProcess function in Process.c only checks if the caller has PROC_PRIV_SYSTEM privilege but doesn't compare caller vs target privilege levels, allowing supervisor processes like the shell to incorrectly kill system-level processes.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-02T02:37:06.993Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.h:153-154
Timestamp: 2025-09-02T02:37:06.993Z
Learning: In VoidFrame MLFQ.c, the ProcessRuntimePath cleanup should happen for both normal exit (ProcessExitStub → TerminateProcess with TERM_NORMAL) and kill (MLFQKillProcess → TerminateProcess with TERM_KILLED) since both go through the same TerminateProcess function which has VfsDelete cleanup code when VF_CONFIG_PROCINFO_AUTO_CLEANUP is enabled. If normal exit leaves directories but kill doesn't, this suggests VfsDelete might be failing silently for normal exits, or there's a race condition in the cleanup logic.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: The VoidFrame kernel's KillProcess function lacks proper privilege enforcement - supervisor-level processes can incorrectly kill system-level processes and vice versa, indicating missing privilege validation checks.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-11T07:18:24.614Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 69
File: kernel/etc/Shell.c:82-86
Timestamp: 2025-08-11T07:18:24.614Z
Learning: In VoidFrame's process cleanup system, `CleanupTerminatedProcesses()` must skip (using `continue`) when encountering non-zombie processes in the termination queue, as continuing with `FastMemset()` on non-zombie processes causes memory corruption and kernel crashes.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-07T11:41:54.644Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 119
File: kernel/sched/MLFQ.c:1607-1621
Timestamp: 2025-09-07T11:41:54.644Z
Learning: Cerberus causes processes to get "stuck" rather than crash because it performs blocking VFS I/O operations (VfsCreateDir, VfsAppendFile, VfsWriteFile) in critical scheduler paths like CerberusPreScheduleCheck() and CerberusTick(), causing page faults and hangs during context switches instead of clean termination.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-12T03:19:52.873Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 73
File: kernel/elf/ELFloader.c:0-0
Timestamp: 2025-08-12T03:19:52.873Z
Learning: VoidFrame kernel now has complete UEFI boot support with hybrid BIOS/UEFI ISO creation capability. The existing VBE framebuffer implementation requires no changes as it uses Multiboot2 framebuffer tags and direct memory-mapped access, making it inherently UEFI-compatible. Build process: ninja + ./scripts/build_hybrid_iso.sh creates dual-platform bootable ISO.
Applied to files:
docs/DEVELOPMENT.mdREADME.md
📚 Learning: 2025-09-19T11:55:43.328Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 132
File: arch/x86_64/syscall/Syscall.c:12-19
Timestamp: 2025-09-19T11:55:43.328Z
Learning: In the VoidFrame kernel project, assembler-0 is implementing basic POSIX-compliant syscalls in ring 0 without user/kernel memory protection, prioritizing getting basic functionality working before adding full security features.
Applied to files:
docs/DEVELOPMENT.mdREADME.mdCMakeLists.txt
📚 Learning: 2025-08-12T03:19:52.873Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 73
File: kernel/elf/ELFloader.c:0-0
Timestamp: 2025-08-12T03:19:52.873Z
Learning: User assembler-0 has successfully implemented UEFI boot support for VoidFrame kernel. The VBE framebuffer implementation is fully UEFI-compatible using Multiboot2 framebuffer tags and direct memory-mapped access, requiring no kernel code changes - only bootloader configuration updates.
Applied to files:
docs/DEVELOPMENT.mdREADME.md
📚 Learning: 2025-08-31T07:06:37.003Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 101
File: kernel/etc/Shell.c:829-837
Timestamp: 2025-08-31T07:06:37.003Z
Learning: assembler-0 is working on optimizing ramfs performance in VoidFrame kernel and wants to implement proper filesystem characteristics like faster lookups, better memory management, and advanced features like copy-on-write and caching.
Applied to files:
README.md
📚 Learning: 2025-08-12T01:43:39.847Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 72
File: arch/x86_64/syscall/SyscallEntry.asm:24-30
Timestamp: 2025-08-12T01:43:39.847Z
Learning: User prefers to defer syscall implementation complexity until next year and is considering making a ring 0 kernel instead of continuing with user-mode syscall approach in the VoidFrame kernel project.
Applied to files:
README.md
📚 Learning: 2025-08-13T08:43:54.750Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 80
File: README.md:7-8
Timestamp: 2025-08-13T08:43:54.750Z
Learning: User assembler-0 is working on VoidFrame kernel with a tight deadline (2-3 days before summer ends) and specifically requested runtime safety checks similar to __stack_chk_fail but for deadlocks and other kernel issues. The kernel already has extensive safety mechanisms including stack canaries, guard pages, heap integrity checks, and process security validation.
Applied to files:
README.md
📚 Learning: 2025-08-31T14:19:11.366Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: docs/ARCHITECHTURE.md:1-3
Timestamp: 2025-08-31T14:19:11.366Z
Learning: assembler-0 wants to implement deep fault tracing for VoidFrame kernel exceptions (Page Fault, General Protection Fault, Invalid Opcode) instead of just panicking. The current interrupt handler has complete register state available in the Registers struct (defined in arch/x86_64/cpu/Cpu.h) including RBP for stack walking, RIP for fault location, and error codes for analysis.
Applied to files:
README.md
📚 Learning: 2025-08-09T04:47:56.883Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 53
File: kernel/core/Kernel.c:256-259
Timestamp: 2025-08-09T04:47:56.883Z
Learning: The VoidFrame kernel memory crash occurs when VIRT_ADDR_SPACE_START is set to 0xFFFF800000000000ULL instead of 0xFFFFFFFF80000000ULL, causing the heap to allocate 128TB away from where the kernel is mapped, resulting in page faults when accessing heap memory.
Applied to files:
README.md
📚 Learning: 2025-08-11T09:51:51.217Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 70
File: kernel/process/Process.c:1224-1228
Timestamp: 2025-08-11T09:51:51.217Z
Learning: In VoidFrame kernel, avoid using floating-point arithmetic in kernel space functions like SystemService. Use fixed-point arithmetic instead (e.g., 16.16 format with integer operations) to prevent FPU state corruption, improve performance, and ensure predictable behavior. This is especially important for system-level processes running with PROC_PRIV_SYSTEM privileges.
Applied to files:
README.md
🧬 Code graph analysis (2)
kernel/sched/EEVDF.c (4)
crypto/CRC32.c (2)
CRC32(20-35)CRC32Init(5-18)kernel/atomic/Atomics.c (10)
AtomicInc64(76-78)AtomicRead64(94-96)AtomicCmpxchg64(91-93)AtomicFetchAnd64(125-127)AtomicInc(10-12)AtomicRead(20-22)AtomicCmpxchg(16-19)AtomicFetchOr64(122-124)AtomicStore(34-36)AtomicDec(13-15)kernel/atomic/rust/src/ffi.rs (5)
rust_spinlock_lock_irqsave(261-272)rust_spinlock_unlock_irqrestore(275-282)rust_spinlock_new(27-37)rust_spinlock_lock(54-58)rust_spinlock_unlock(61-65)fs/procfs/ProcFS.c (2)
ProcFSRegisterProcess(18-27)ProcFSUnregisterProcess(29-46)
kernel/atomic/rust/src/ffi.rs (2)
kernel/atomic/rust/src/mcs.rs (4)
new(21-26)new(52-56)new(124-131)new(154-159)kernel/atomic/rust/src/spinlock.rs (3)
new(69-77)new(218-224)new(248-253)
🪛 Clang (14.0.6)
kernel/sched/EEVDF.c
[warning] 34-34: variable 'sis_global_nonce' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 35-35: variable 'sis_boot_entropy' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 36-36: variable 'sis_process_keys' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 62-62: variable 'process_locks' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 65-65: variable 'processes' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 66-66: variable 'pid_bitmap' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 67-67: variable 'current_process' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 68-68: variable 'process_count' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 69-69: variable 'need_schedule' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 70-70: variable 'pid_lock' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 70-70: variable 'pid_lock' provides global access to a non-const object; consider making the pointed-to data 'const'
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 71-71: variable 'runqueue_lock' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 71-71: variable 'runqueue_lock' provides global access to a non-const object; consider making the pointed-to data 'const'
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 74-74: variable 'eevdf_security_manager_pid' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 75-75: variable 'security_violation_count' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 78-78: variable 'active_process_bitmap' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 79-79: variable 'ready_process_bitmap' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 82-82: variable 'eevdf_scheduler' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 83-83: variable 'rb_node_pool' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 84-84: variable 'rb_node_pool_bitmap' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 87-87: variable 'termination_queue' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 88-88: variable 'term_queue_head' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 89-89: variable 'term_queue_tail' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 90-90: variable 'term_queue_count' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 93-93: variable 'context_switches' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 94-94: variable 'scheduler_calls' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 96-96: variable 'APIC_HZ' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 97-97: variable 'APICticks' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 104-104: 2 adjacent parameters of 'SISFastHash' of similar type ('int') are easily swapped by mistake
(bugprone-easily-swappable-parameters)
[note] 104-104: the first parameter in the range is 'a'
(clang)
[note] 104-104: the last parameter in the range is 'b'
(clang)
[warning] 110-110: 2 adjacent parameters of 'SISGenerateProcessKey' of similar type ('int') are easily swapped by mistake
(bugprone-easily-swappable-parameters)
[note] 110-110: the first parameter in the range is 'slot'
(clang)
[note] 110-110: the last parameter in the range is 'pid'
(clang)
[warning] 125-125: parameter 'slot' is unused
(misc-unused-parameters)
[warning] 126-126: statement should be inside braces
(readability-braces-around-statements)
[warning] 634-634: function 'FindFreeSlotFast' is within a recursive call chain
(misc-no-recursion)
[note] 634-634: example recursive call chain, starting from function 'FindFreeSlotFast'
(clang)
[note] 656-656: Frame #1: function 'FindFreeSlotFast' calls function 'FindFreeSlotFast' here:
(clang)
[note] 656-656: ... which was the starting point of the recursive call chain; there may be other cycles
(clang)
[warning] 647-647: variable 'slot' is not initialized
(cppcoreguidelines-init-variables)
[note] 752-752: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 756-756: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 756-756: +1
(clang)
[note] 757-757: +1
(clang)
[note] 760-760: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 761-761: +1
(clang)
[note] 771-771: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 780-780: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 780-780: +1
(clang)
[note] 784-784: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 784-784: +1
(clang)
[warning] 746-746: variable name 'rq' is too short, expected at least 3 characters
(readability-identifier-length)
[warning] 747-747: variable 'prev' is not initialized
(cppcoreguidelines-init-variables)
[warning] 755-755: variable 'state' is not initialized
(cppcoreguidelines-init-variables)
[note] 803-803: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 805-805: +1, nesting level increased to 2
(clang)
[note] 810-810: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 810-810: +1
(clang)
[note] 818-818: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 822-822: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 822-822: +1
(clang)
[note] 824-824: +1
(clang)
[note] 843-843: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[warning] 819-819: variable 'new_proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 852-852: statement should be inside braces
(readability-braces-around-statements)
[warning] 857-857: statement should be inside braces
(readability-braces-around-statements)
[warning] 985-985: variable 'idx' is not initialized
(cppcoreguidelines-init-variables)
[warning] 986-986: variable 'bit' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1096-1096: parameter 'slot' is unused
(misc-unused-parameters)
[warning] 1097-1097: statement should be inside braces
(readability-braces-around-statements)
[warning] 1098-1098: statement should be inside braces
(readability-braces-around-statements)
[warning] 1108-1108: parameter 'slot' is unused
(misc-unused-parameters)
[warning] 1109-1109: statement should be inside braces
(readability-braces-around-statements)
[warning] 1111-1111: variable 'proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1133-1133: parameter 'slot' is unused
(misc-unused-parameters)
[warning] 1134-1134: statement should be inside braces
(readability-braces-around-statements)
[warning] 1136-1136: variable 'proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1151-1151: 3 adjacent parameters of 'EEVDFTerminateProcess' of convertible types are easily swapped by mistake
(bugprone-easily-swappable-parameters)
[note] 1151-1151: the first parameter in the range is 'pid'
(clang)
[note] 1151-1151: the last parameter in the range is 'exit_code'
(clang)
[note] 1151-1151:
(clang)
[note] 1151-1151: 'int' and 'TerminationReason' may be implicitly converted
(clang)
[warning] 1151-1151: parameter 'pid' is unused
(misc-unused-parameters)
[warning] 1151-1151: parameter 'exit_code' is unused
(misc-unused-parameters)
[warning] 1152-1152: variable 'proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1153-1153: statement should be inside braces
(readability-braces-around-statements)
[warning] 1156-1156: statement should be inside braces
(readability-braces-around-statements)
[warning] 1161-1161: variable 'state' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1267-1267: parameter 'pid' is unused
(misc-unused-parameters)
[warning] 1267-1267: parameter 'reason' is unused
(misc-unused-parameters)
[warning] 1268-1268: variable 'proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1269-1269: statement should be inside braces
(readability-braces-around-statements)
[warning] 1272-1272: statement should be inside braces
(readability-braces-around-statements)
[warning] 1284-1284: 666 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
🪛 markdownlint-cli2 (0.18.1)
docs/DEVELOPMENT.md
105-105: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
106-106: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
107-107: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
109-109: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
110-110: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
111-111: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
112-112: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
113-113: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
115-115: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
116-116: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
117-117: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
118-118: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
119-119: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
vfcompositor/Compositor.c (1)
427-437: Fix resource leak: spinlock not freed on early return.The spinlock allocated at line 428 is never freed when returning early at line 437. This leaks kernel memory and can accumulate if VFCompositor is retried.
Apply this diff to properly clean up before returning:
if (!VBEIsInitialized()) { PrintKernel("VFCompositor: VBE not initialized, waiting...\n"); + VFCompositorShutdown(&g_compositor_ctx); return; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (8)
cmake/configuration.cmake(0 hunks)cmake/features.cmake(0 hunks)cmake/flags.cmake(1 hunks)kernel/ipc/Ipc.c(0 hunks)kernel/sched/EEVDF.c(23 hunks)kernel/sched/MLFQ.c(0 hunks)mm/security/Cerberus.c(10 hunks)vfcompositor/Compositor.c(1 hunks)
💤 Files with no reviewable changes (4)
- cmake/configuration.cmake
- cmake/features.cmake
- kernel/sched/MLFQ.c
- kernel/ipc/Ipc.c
🧰 Additional context used
🧠 Learnings (26)
📓 Common learnings
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 101
File: kernel/etc/Shell.c:829-837
Timestamp: 2025-08-31T07:06:37.003Z
Learning: assembler-0 is working on optimizing ramfs performance in VoidFrame kernel and wants to implement proper filesystem characteristics like faster lookups, better memory management, and advanced features like copy-on-write and caching.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 132
File: arch/x86_64/syscall/Syscall.c:12-19
Timestamp: 2025-09-19T11:55:43.328Z
Learning: In the VoidFrame kernel project, assembler-0 is implementing basic POSIX-compliant syscalls in ring 0 without user/kernel memory protection, prioritizing getting basic functionality working before adding full security features.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 105
File: meson.build:252-257
Timestamp: 2025-09-01T08:01:39.969Z
Learning: Cerberus memory protection system causes kernel panics not because of fault analysis but because it performs VFS operations (VfsCreateDir, VfsAppendFile, VfsWriteFile) in critical scheduler paths. CerberusPreScheduleCheck() runs before every context switch and CerberusTick() runs every 10 scheduler ticks, both potentially triggering VFS I/O that can cause page faults. VFS operations should be deferred or made optional to avoid crashes in scheduler context.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 119
File: kernel/sched/MLFQ.c:1607-1621
Timestamp: 2025-09-07T11:41:54.644Z
Learning: Cerberus causes processes to get "stuck" rather than crash because it performs blocking VFS I/O operations (VfsCreateDir, VfsAppendFile, VfsWriteFile) in critical scheduler paths like CerberusPreScheduleCheck() and CerberusTick(), causing page faults and hangs during context switches instead of clean termination.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 105
File: meson.build:252-257
Timestamp: 2025-09-01T08:17:56.769Z
Learning: In VoidFrame's Cerberus security system, CerberusRegisterProcess() causes kernel panics because CerberusInstallStackCanary() performs direct memory writes (*canary_ptr = STACK_CANARY_VALUE) during process creation. The stack memory may not be fully mapped/accessible at this point, causing page faults in critical kernel context. The fix is to either defer canary installation, add memory mapping validation, or skip canary installation during process registration.
Learnt from: assembler-0
Repo: assembler-0/autocc PR: 33
File: include/utils.hpp:138-190
Timestamp: 2025-08-04T13:24:48.984Z
Learning: The user assembler-0 tends to create wrapper functions during refactoring and sometimes accidentally leaves duplicate implementations. They have a casual, self-aware attitude about coding mistakes and are receptive to feedback about code duplication issues.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: docs/ARCHITECHTURE.md:1-3
Timestamp: 2025-08-31T14:19:11.366Z
Learning: assembler-0 wants to implement deep fault tracing for VoidFrame kernel exceptions (Page Fault, General Protection Fault, Invalid Opcode) instead of just panicking. The current interrupt handler has complete register state available in the Registers struct (defined in arch/x86_64/cpu/Cpu.h) including RBP for stack walking, RIP for fault location, and error codes for analysis.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 80
File: README.md:7-8
Timestamp: 2025-08-13T08:43:54.750Z
Learning: User assembler-0 is working on VoidFrame kernel with a tight deadline (2-3 days before summer ends) and specifically requested runtime safety checks similar to __stack_chk_fail but for deadlocks and other kernel issues. The kernel already has extensive safety mechanisms including stack canaries, guard pages, heap integrity checks, and process security validation.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 72
File: arch/x86_64/syscall/SyscallEntry.asm:24-30
Timestamp: 2025-08-12T02:13:46.266Z
Learning: User assembler-0 has existing ELF infrastructure in VoidFrame kernel with Elf.h header definitions and CreateProcess() function that properly sets up process context including stack allocation, ProcessExitStub return address, and register initialization. The issue was missing ELF loader implementation, not compilation problems.
📚 Learning: 2025-09-01T08:01:39.969Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 105
File: meson.build:252-257
Timestamp: 2025-09-01T08:01:39.969Z
Learning: Cerberus memory protection system causes kernel panics not because of fault analysis but because it performs VFS operations (VfsCreateDir, VfsAppendFile, VfsWriteFile) in critical scheduler paths. CerberusPreScheduleCheck() runs before every context switch and CerberusTick() runs every 10 scheduler ticks, both potentially triggering VFS I/O that can cause page faults. VFS operations should be deferred or made optional to avoid crashes in scheduler context.
Applied to files:
mm/security/Cerberus.ckernel/sched/EEVDF.c
📚 Learning: 2025-09-01T08:17:56.769Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 105
File: meson.build:252-257
Timestamp: 2025-09-01T08:17:56.769Z
Learning: In VoidFrame's Cerberus security system, CerberusRegisterProcess() causes kernel panics because CerberusInstallStackCanary() performs direct memory writes (*canary_ptr = STACK_CANARY_VALUE) during process creation. The stack memory may not be fully mapped/accessible at this point, causing page faults in critical kernel context. The fix is to either defer canary installation, add memory mapping validation, or skip canary installation during process registration.
Applied to files:
mm/security/Cerberus.ckernel/sched/EEVDF.c
📚 Learning: 2025-09-07T11:41:54.644Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 119
File: kernel/sched/MLFQ.c:1607-1621
Timestamp: 2025-09-07T11:41:54.644Z
Learning: Cerberus causes processes to get "stuck" rather than crash because it performs blocking VFS I/O operations (VfsCreateDir, VfsAppendFile, VfsWriteFile) in critical scheduler paths like CerberusPreScheduleCheck() and CerberusTick(), causing page faults and hangs during context switches instead of clean termination.
Applied to files:
mm/security/Cerberus.ckernel/sched/EEVDF.c
📚 Learning: 2025-09-02T01:55:54.511Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.c:691-694
Timestamp: 2025-09-02T01:55:54.511Z
Learning: In VoidFrame's Cerberus system, CerberusInstallStackCanary fails because it incorrectly calculates the canary address. VMemAllocStack returns stack_top (highest address) but the canary calculation uses stack_base + stack_size - 8, which results in an address beyond the allocated stack region. The correct canary location should be calculated as actual_stack_base + sizeof(uint64_t) where actual_stack_base = stack_top - stack_size, placing the canary just above the unmapped guard page.
Applied to files:
mm/security/Cerberus.ckernel/sched/EEVDF.c
📚 Learning: 2025-08-09T10:31:44.439Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 58
File: drivers/VesaBIOSExtension.c:77-85
Timestamp: 2025-08-09T10:31:44.439Z
Learning: In VoidFrame kernel, process stacks are allocated using VMemAllocWithGuards() which returns virtual addresses, but TerminateProcess incorrectly uses FreePage() (which expects physical addresses) to free them, causing "Page index out of bounds" errors. The correct function to use is VMemFreeWithGuards(proc->stack, STACK_SIZE).
Applied to files:
mm/security/Cerberus.ckernel/sched/EEVDF.c
📚 Learning: 2025-08-31T02:11:29.291Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 100
File: kernel/memory/VMem.h:44-47
Timestamp: 2025-08-31T02:11:29.291Z
Learning: VoidFrame kernel's ValidateMemoryLayout() function in Kernel.c produces false positive "Stack overlaps with kernel code" warnings because the static kernel_stack array is correctly allocated within the kernel's physical memory region. This overlap is expected and normal behavior, not an error.
Applied to files:
mm/security/Cerberus.c
📚 Learning: 2025-08-10T09:50:21.823Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T09:50:21.823Z
Learning: VoidFrame's VBE graphics can be optimized by using FastMemcpy for entire scanlines instead of pixel-by-pixel VBEPutPixel calls, reducing function calls from millions to thousands for full-screen operations.
Applied to files:
vfcompositor/Compositor.c
📚 Learning: 2025-08-14T02:11:27.395Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 82
File: kernel/process/Process.h:0-0
Timestamp: 2025-08-14T02:11:27.395Z
Learning: In VoidFrame kernel, FastMemcpy was using SSE2 movdqu instructions without preserving XMM registers, causing crashes when called from interrupt context (like the scheduler's FastSchedule function). The fix is to use only general-purpose registers with 64-bit unrolled copies to maintain performance while being interrupt-safe.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-07-16T01:04:23.790Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 47
File: kernel/core/Kernel.c:434-434
Timestamp: 2025-07-16T01:04:23.790Z
Learning: VMemAlloc() in VoidFrame kernel fails with error code -2 (VMEM_ERROR_INVALID_ADDR) due to virtual address space layout conflict where the heap start address (_bss_end + KERNEL_VIRTUAL_OFFSET + 1MB margin) exceeds VIRT_ADDR_SPACE_END (0xFFFFFFFF80000000ULL), causing VMemMap validation to fail.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-13T07:19:55.274Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 79
File: drivers/PCI/PCI.c:154-154
Timestamp: 2025-08-13T07:19:55.274Z
Learning: VMemUnmapMMIO in VoidFrame kernel should use the same page table access pattern as the working VMemUnmap function: `uint64_t* pt_table = (uint64_t*)(pt_phys + KERNEL_VIRTUAL_OFFSET);` rather than PHYS_TO_VIRT macro or identity mapping checks.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-17T08:16:43.539Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 93
File: kernel/memory/VMem.c:72-79
Timestamp: 2025-08-17T08:16:43.539Z
Learning: In VoidFrame kernel, VMemGetPhysAddr and related page table walking functions were causing panics because they assumed identity mapping existed for physical addresses < IDENTITY_MAP_SIZE (4GB), but the bootloader doesn't provide this 1:1 mapping. The fix is to remove all identity mapping assumptions and always use PHYS_TO_VIRT() for page table access in functions like VMemGetPageTablePhys, VMemMap, VMemMapHuge, VMemGetPhysAddr, VMemUnmap, VMemMapMMIO, and VMemUnmapMMIO.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-01T01:10:22.123Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: README.md:9-9
Timestamp: 2025-09-01T01:10:22.123Z
Learning: The current VoidFrame Registers struct in arch/x86_64/cpu/Cpu.h only saves basic GPRs, segment registers, and exception context (interrupt_number, error_code, rip, cs, rflags, rsp, ss). It's missing critical registers for deep fault tracing: SIMD registers (XMM/YMM/ZMM), control registers (CR0/CR2/CR3/CR4), debug registers (DR0-DR7), and extended FPU state. The struct has a "DO NOT TOUCH" comment indicating it must match interrupt ASM stack layout.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-14T02:11:58.963Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 82
File: kernel/process/Process.h:0-0
Timestamp: 2025-08-14T02:11:58.963Z
Learning: In VoidFrame kernel's FastMemcpy implementation (kernel/memory/MemOps.c), memory corruption occurs under high load due to interrupts occurring between SSE2 movdqu load and store instructions, corrupting XMM register state. The fix requires disabling interrupts around SSE operations and adding memory barriers (sfence) to ensure stores complete atomically.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-13T07:17:35.941Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 79
File: drivers/PCI/PCI.c:154-154
Timestamp: 2025-08-13T07:17:35.941Z
Learning: In VoidFrame kernel, VMemGetPageTablePhys uses a 3-level hierarchy: Level 0 = PML4->PDP, Level 1 = PDP->PD, Level 2 = PD->PT. To access Page Tables, always use level=2, not level=1.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-14T11:01:02.698Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 130
File: kernel/core/InitRD.c:25-35
Timestamp: 2025-09-14T11:01:02.698Z
Learning: In VoidFrame kernel's InitRD.c, multiboot modules should be mapped using VMemMap() with PAGE_PRESENT | PAGE_WRITABLE flags instead of VMemMapMMIO(), as the latter applies cache-disabling flags (PAGE_NOCACHE | PAGE_WRITETHROUGH) that can corrupt data when reading regular RAM content.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-11T09:51:32.713Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 70
File: kernel/process/Process.c:1224-1228
Timestamp: 2025-08-11T09:51:32.713Z
Learning: In the VoidFrame kernel (kernel/process/Process.c), avoid using floating-point arithmetic in kernel space. Use fixed-point arithmetic instead with integer scaling (e.g., multiplying by 1000 for 3 decimal places) to avoid FPU state management overhead and potential exceptions.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-01T01:10:22.123Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: README.md:9-9
Timestamp: 2025-09-01T01:10:22.123Z
Learning: VoidFrame's interrupt handlers in arch/x86_64/interrupts/Interrupts.asm only save basic GPRs and segment registers, missing critical registers for deep fault tracing: control registers (CR0/CR2/CR3/CR4), SIMD state (XMM/YMM/ZMM), debug registers (DR0-DR7), and extended FPU state. The CPU initialization code enables SSE/AVX/XSAVE features but interrupt handlers don't preserve this extended state. Enhanced fault tracing requires selective extended state saving for critical exceptions (ISR 6, 8, 13, 14) while keeping lightweight handling for regular interrupts.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: In VoidFrame's Process.c, PIDs are allocated using `__sync_fetch_and_add(&next_pid, 1)` which only increments and never reuses freed PIDs, causing PID exhaustion after MAX_PROCESSES terminations.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: The VoidFrame kernel has critical issues with PID allocation - it uses a simple incrementing counter without recycling freed PIDs, causing PID 4 to become PID 5 after death instead of reusing slot 4.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-12T02:13:46.266Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 72
File: arch/x86_64/syscall/SyscallEntry.asm:24-30
Timestamp: 2025-08-12T02:13:46.266Z
Learning: User assembler-0 has existing ELF infrastructure in VoidFrame kernel with Elf.h header definitions and CreateProcess() function that properly sets up process context including stack allocation, ProcessExitStub return address, and register initialization. The issue was missing ELF loader implementation, not compilation problems.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-11T07:18:24.614Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 69
File: kernel/etc/Shell.c:82-86
Timestamp: 2025-08-11T07:18:24.614Z
Learning: The order of operations in VoidFrame's `TerminateProcess()` is critical: the process state must be set to PROC_ZOMBIE before adding to the termination queue with a memory barrier between them, otherwise CleanupTerminatedProcesses may process the entry before the zombie state is set.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: VoidFrame's TerminateProcess function in Process.c only checks if the caller has PROC_PRIV_SYSTEM privilege but doesn't compare caller vs target privilege levels, allowing supervisor processes like the shell to incorrectly kill system-level processes.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-09-02T02:37:06.993Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.h:153-154
Timestamp: 2025-09-02T02:37:06.993Z
Learning: In VoidFrame MLFQ.c, the ProcessRuntimePath cleanup should happen for both normal exit (ProcessExitStub → TerminateProcess with TERM_NORMAL) and kill (MLFQKillProcess → TerminateProcess with TERM_KILLED) since both go through the same TerminateProcess function which has VfsDelete cleanup code when VF_CONFIG_PROCINFO_AUTO_CLEANUP is enabled. If normal exit leaves directories but kill doesn't, this suggests VfsDelete might be failing silently for normal exits, or there's a race condition in the cleanup logic.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: The VoidFrame kernel's KillProcess function lacks proper privilege enforcement - supervisor-level processes can incorrectly kill system-level processes and vice versa, indicating missing privilege validation checks.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-11T07:18:24.614Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 69
File: kernel/etc/Shell.c:82-86
Timestamp: 2025-08-11T07:18:24.614Z
Learning: In VoidFrame's process cleanup system, `CleanupTerminatedProcesses()` must skip (using `continue`) when encountering non-zombie processes in the termination queue, as continuing with `FastMemset()` on non-zombie processes causes memory corruption and kernel crashes.
Applied to files:
kernel/sched/EEVDF.c
🧬 Code graph analysis (2)
mm/security/Cerberus.c (1)
kernel/etc/Console.c (4)
PrintKernelErrorF(290-297)PrintKernelF(272-279)PrintKernelWarningF(281-288)PrintKernelSuccessF(299-306)
kernel/sched/EEVDF.c (7)
crypto/CRC32.c (1)
CRC32(20-35)kernel/atomic/Atomics.c (10)
AtomicInc64(76-78)AtomicRead64(94-96)AtomicCmpxchg64(91-93)AtomicFetchAnd64(125-127)AtomicInc(10-12)AtomicRead(20-22)AtomicCmpxchg(16-19)AtomicFetchOr64(122-124)AtomicStore(34-36)AtomicDec(13-15)kernel/sched/MLFQ.c (1)
FastFFS(72-74)mm/security/Cerberus.c (4)
CerberusInit(34-58)CerberusRegisterProcess(60-91)CerberusPreScheduleCheck(194-215)CerberusUnregisterProcess(93-117)mm/MemOps.c (1)
FastMemcpy(55-80)kernel/atomic/rust/src/ffi.rs (5)
rust_spinlock_lock_irqsave(261-272)rust_spinlock_unlock_irqrestore(275-282)rust_spinlock_new(27-37)rust_spinlock_lock(54-58)rust_spinlock_unlock(61-65)fs/procfs/ProcFS.c (2)
ProcFSRegisterProcess(18-27)ProcFSUnregisterProcess(29-46)
🪛 Clang (14.0.6)
mm/security/Cerberus.c
[warning] 170-170: variable 'canary_ptr' is not initialized
(cppcoreguidelines-init-variables)
kernel/sched/EEVDF.c
[warning] 34-34: variable 'sis_global_nonce' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 35-35: variable 'sis_boot_entropy' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 36-36: variable 'sis_process_keys' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 62-62: variable 'process_locks' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 65-65: variable 'processes' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 66-66: variable 'pid_bitmap' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 67-67: variable 'current_process' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 68-68: variable 'process_count' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 69-69: variable 'need_schedule' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 70-70: variable 'pid_lock' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 70-70: variable 'pid_lock' provides global access to a non-const object; consider making the pointed-to data 'const'
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 71-71: variable 'runqueue_lock' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 71-71: variable 'runqueue_lock' provides global access to a non-const object; consider making the pointed-to data 'const'
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 74-74: variable 'eevdf_security_manager_pid' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 75-75: variable 'security_violation_count' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 78-78: variable 'active_process_bitmap' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 79-79: variable 'ready_process_bitmap' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 82-82: variable 'eevdf_scheduler' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 83-83: variable 'rb_node_pool' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 84-84: variable 'rb_node_pool_bitmap' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 87-87: variable 'termination_queue' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 88-88: variable 'term_queue_head' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 89-89: variable 'term_queue_tail' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 90-90: variable 'term_queue_count' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 93-93: variable 'context_switches' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 94-94: variable 'scheduler_calls' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 96-96: variable 'APIC_HZ' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 97-97: variable 'APICticks' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 104-104: 2 adjacent parameters of 'SISFastHash' of similar type ('int') are easily swapped by mistake
(bugprone-easily-swappable-parameters)
[note] 104-104: the first parameter in the range is 'a'
(clang)
[note] 104-104: the last parameter in the range is 'b'
(clang)
[warning] 110-110: 2 adjacent parameters of 'SISGenerateProcessKey' of similar type ('int') are easily swapped by mistake
(bugprone-easily-swappable-parameters)
[note] 110-110: the first parameter in the range is 'slot'
(clang)
[note] 110-110: the last parameter in the range is 'pid'
(clang)
[warning] 125-125: parameter 'slot' is unused
(misc-unused-parameters)
[warning] 126-126: statement should be inside braces
(readability-braces-around-statements)
[warning] 634-634: function 'FindFreeSlotFast' is within a recursive call chain
(misc-no-recursion)
[note] 634-634: example recursive call chain, starting from function 'FindFreeSlotFast'
(clang)
[note] 656-656: Frame #1: function 'FindFreeSlotFast' calls function 'FindFreeSlotFast' here:
(clang)
[note] 656-656: ... which was the starting point of the recursive call chain; there may be other cycles
(clang)
[warning] 647-647: variable 'slot' is not initialized
(cppcoreguidelines-init-variables)
[note] 752-752: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 756-756: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 756-756: +1
(clang)
[note] 757-757: +1
(clang)
[note] 760-760: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 761-761: +1
(clang)
[note] 771-771: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 780-780: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 780-780: +1
(clang)
[note] 784-784: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 784-784: +1
(clang)
[warning] 746-746: variable name 'rq' is too short, expected at least 3 characters
(readability-identifier-length)
[warning] 747-747: variable 'prev' is not initialized
(cppcoreguidelines-init-variables)
[warning] 755-755: variable 'state' is not initialized
(cppcoreguidelines-init-variables)
[note] 803-803: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 805-805: +1, nesting level increased to 2
(clang)
[note] 810-810: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 810-810: +1
(clang)
[note] 818-818: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 822-822: +2, including nesting penalty of 1, nesting level increased to 2
(clang)
[note] 822-822: +1
(clang)
[note] 824-824: +1
(clang)
[note] 843-843: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[warning] 819-819: variable 'new_proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 852-852: statement should be inside braces
(readability-braces-around-statements)
[warning] 857-857: statement should be inside braces
(readability-braces-around-statements)
[warning] 988-988: variable 'idx' is not initialized
(cppcoreguidelines-init-variables)
[warning] 989-989: variable 'bit' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1099-1099: parameter 'slot' is unused
(misc-unused-parameters)
[warning] 1100-1100: statement should be inside braces
(readability-braces-around-statements)
[warning] 1101-1101: statement should be inside braces
(readability-braces-around-statements)
[warning] 1111-1111: parameter 'slot' is unused
(misc-unused-parameters)
[warning] 1112-1112: statement should be inside braces
(readability-braces-around-statements)
[warning] 1114-1114: variable 'proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1136-1136: parameter 'slot' is unused
(misc-unused-parameters)
[warning] 1137-1137: statement should be inside braces
(readability-braces-around-statements)
[warning] 1139-1139: variable 'proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1154-1154: 3 adjacent parameters of 'EEVDFTerminateProcess' of convertible types are easily swapped by mistake
(bugprone-easily-swappable-parameters)
[note] 1154-1154: the first parameter in the range is 'pid'
(clang)
[note] 1154-1154: the last parameter in the range is 'exit_code'
(clang)
[note] 1154-1154:
(clang)
[note] 1154-1154: 'int' and 'TerminationReason' may be implicitly converted
(clang)
[warning] 1154-1154: parameter 'pid' is unused
(misc-unused-parameters)
[warning] 1154-1154: parameter 'exit_code' is unused
(misc-unused-parameters)
[warning] 1155-1155: variable 'proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1156-1156: statement should be inside braces
(readability-braces-around-statements)
[warning] 1159-1159: statement should be inside braces
(readability-braces-around-statements)
[warning] 1164-1164: variable 'state' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1270-1270: parameter 'pid' is unused
(misc-unused-parameters)
[warning] 1270-1270: parameter 'reason' is unused
(misc-unused-parameters)
[warning] 1271-1271: variable 'proc' is not initialized
(cppcoreguidelines-init-variables)
[warning] 1272-1272: statement should be inside braces
(readability-braces-around-statements)
[warning] 1275-1275: statement should be inside braces
(readability-braces-around-statements)
[warning] 1287-1287: 666 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
🔇 Additional comments (3)
mm/security/Cerberus.c (2)
9-9: LGTM! VFS removal fixes critical scheduler issues.The removal of VFS operations and standardization of logging prefixes with "Cerberus: " is appropriate. This eliminates blocking I/O in critical scheduler paths that previously caused kernel panics and process hangs.
Based on learnings
Also applies to: 29-30, 89-89, 116-116, 127-128, 133-133, 142-142, 153-153, 166-166, 202-202, 208-208, 213-213, 235-235
1-9: CerberusReportThreat removal verified—no callers found.Verification confirms the function has no remaining callers in the codebase. The function declaration remains conditionally guarded in mm/security/Cerberus.h but is unused. Safe to proceed.
cmake/flags.cmake (1)
15-15: ****The review comment assumes a change from
-fstack-protector-strongto-fstack-protector-all, but this cannot be verified from the repository history. Git log search across cmake/flags.cmake shows no evidence of this transition occurring. The current state contains-fstack-protector-all, but the prior state cannot be confirmed from available history.Additionally, the concerns about Cerberus stack canary operations causing kernel panics in critical contexts are based on outdated learnings (September 2025). The current
CerberusInstallStackCanaryimplementation includes proper memory validation viaVMemGetPhysAddr(), test writes, and error handling—addressing the safety issues previously flagged.Without confirmation that an actual change from
-fstack-protector-strongoccurred, the review comment's performance impact analysis and recommendations cannot be substantiated.Likely an incorrect or invalid review comment.
| #ifdef VF_CONFIG_USE_CERBERUS | ||
| CerberusPreScheduleCheck(slot); | ||
| #endif |
There was a problem hiding this comment.
Fix Cerberus preflight PID regression.
CerberusPreScheduleCheck is keyed by PID—the Cerberus state arrays (process_info, watch regions, violation counters) are indexed by pid. Passing the scheduler slot index instead means we look up the wrong entry (typically an unmonitored slot), silently skipping stack-canary/violation checks and leaving compromised processes running. In the best case this neuters Cerberus; in the worst case a real violation goes undetected or we trip over unrelated state. Restore the PID here so we hit the correct record.
-#ifdef VF_CONFIG_USE_CERBERUS
- CerberusPreScheduleCheck(slot);
+#ifdef VF_CONFIG_USE_CERBERUS
+ CerberusPreScheduleCheck(proc->pid);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| #ifdef VF_CONFIG_USE_CERBERUS | |
| CerberusPreScheduleCheck(slot); | |
| #endif | |
| #ifdef VF_CONFIG_USE_CERBERUS | |
| CerberusPreScheduleCheck(proc->pid); | |
| #endif |
🤖 Prompt for AI Agents
In kernel/sched/EEVDF.c around lines 1129-1131, CerberusPreScheduleCheck is
being called with the scheduler slot index which is incorrect because the
Cerberus state arrays are keyed by PID; change the call to pass the process PID
(the pid variable or the current process's pid in this scope) instead of slot so
the lookup uses the correct Cerberus record and restores proper pre-schedule
checks.
| Snooze(); | ||
|
|
||
| if (!VBEIsInitialized()) { | ||
| PrintKernel("VFCompositor: VBE not initialized, waiting...\n"); |
There was a problem hiding this comment.
Update misleading log message.
The message says "waiting..." but the function returns immediately at line 437 without actually waiting for VBE initialization.
Apply this diff to make the message accurate:
- PrintKernel("VFCompositor: VBE not initialized, waiting...\n");
+ PrintKernel("VFCompositor: VBE not initialized, exiting early\n");📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| PrintKernel("VFCompositor: VBE not initialized, waiting...\n"); | |
| PrintKernel("VFCompositor: VBE not initialized, exiting early\n"); |
🤖 Prompt for AI Agents
In vfcompositor/Compositor.c around line 436, the log message incorrectly says
"VFCompositor: VBE not initialized, waiting..." while the function returns
immediately; change the printed string to accurately reflect behavior (for
example "VFCompositor: VBE not initialized, returning" or "VFCompositor: VBE not
initialized, aborting") so the log matches the actual control flow.
Summary by CodeRabbit
New Features
Chores
Documentation