Thank you so much. I really like the idea of the hypervisor-based verification approach as it would provide stronger isolation for the verification chain than the current in-kernel approach.
It also aligns really well with some of VEKOS's core components. For instance, the current verification chain (in verification.rs) already maintains an append-only log of system operations:
The current proof system could be extended (operation_proofs.rs) to communicate with a hypervisor-level verification layer.
About the ML, I actually had a previous scrapped component that would have allowed an ML model to run natively in the kernel by dividing the memory zones into 4 different components. Now for issues related to the memory, and for security concerns, I decided to not follow with it. ML are really good at detecting specific components, but I am afraid of the false alarms, as these could cause the system to have for example, spontaneous slow downs in the verifications.
pub struct VerificationRegistry { proofs: Vec<OperationProof>, current_state: AtomicU64, }
The current proof system could be extended (operation_proofs.rs) to communicate with a hypervisor-level verification layer.
About the ML, I actually had a previous scrapped component that would have allowed an ML model to run natively in the kernel by dividing the memory zones into 4 different components. Now for issues related to the memory, and for security concerns, I decided to not follow with it. ML are really good at detecting specific components, but I am afraid of the false alarms, as these could cause the system to have for example, spontaneous slow downs in the verifications.