|
|
|
|
|
|
by boscillator
564 days ago
|
|
|
Interesting. I think it would be good if you added a section to your README explaining who the target user for this is. Is it for systems that need extensive auditing? Also, what kind of performance hit do you get by doing cryptography for every allocation? |
|
|
The primary target users would be systems where integrity verification and auditing are critical requirements, such as:
- Financial/banking systems that need cryptographic proof of all operations
- Medical devices where operation verification is essential for safety
- High-security environments requiring complete system attestation
- Research systems that need reproducible and verifiable execution paths
Though, my end goal with this to be sincere is making it general purpose in the future. I am a firm believer in the privacy of the user, and that's really what I wanted to achieve with this. An OS that can be run anywhere, including hardware that can't be trusted, having the confidence that there won't be a third actor watching every action the user takes.
Regarding the performance impact: The verification system is actually quite efficient since it uses hardware-accelerated operations where available (SHA-256 instructions on modern CPUs) and an optimized FNV-1a fallback implementation. The proof generation adds roughly 3-5% overhead for memory operations and 7-9% for filesystem operations in the benchmarks.
This is achieved by:
- Batching proof generation for small allocations
- Using a zone-based memory allocator that pre-verifies large memory regions
- Implementing an efficient proof storage system with automatic pruning
- Taking advantage of modern CPU crypto acceleration
You're absolutely right about adding this to the README - I'll create a dedicated section covering use cases and performance characteristics.