Security
Silicon's security model starts by removing everything that isn't the database.
No Attack Surface Below the Application
Silicon has no operating system, no kernel, no shell, no SSH, no package manager, no process table, no file utilities, no debugging tools. The attack surface is exactly:
- The Bolt database protocol (TCP)
- The HTTP/WebSocket API (TCP)
- The TLS handshake (TCP)
There is nothing else listening, nothing else running, nothing else installed. A vulnerability scanner pointed at a Silicon instance sees a database endpoint and nothing more.
Hardware Isolation
Each Silicon instance runs inside its own KVM virtual machine with dedicated:
- Virtual CPUs - no shared scheduling with other tenants
- Physical memory pages - no shared address space
- Virtual block device - no shared filesystem
- Virtual network interface - no shared network stack
The isolation boundary is the CPU's hardware virtualization extensions (Intel VT-x / AMD-V), enforced by the hypervisor. This is the same isolation technology used by major cloud providers to separate customer workloads.
No Privilege Escalation Path
Traditional operating systems have a clear privilege escalation path: user code runs at ring 3, kernel code at ring 0. Vulnerabilities that cross this boundary allow privilege escalation.
Silicon has no ring boundary. Everything runs at a single privilege level within the VM. There is no kernel to escalate to, no root user to become, no capabilities to acquire. The hypervisor boundary is the only security boundary, and it is enforced by hardware.
Compared to Containers
Containers share the host kernel. Every container on a machine runs inside the same Linux kernel, separated only by namespaces and cgroups - software boundaries that have been repeatedly bypassed by escape vulnerabilities.
Silicon runs inside a hardware-enforced VM boundary. There is no shared kernel to escape from. The isolation is enforced by the CPU itself, not by software policies.
| Container | Silicon | |
|---|---|---|
| Isolation | Namespaces + cgroups (software) | KVM hardware VM (CPU-enforced) |
| Shared kernel | Yes (single exploit = all containers) | No kernel at all |
| Shell access | /bin/sh, bash, exec into container | None |
| SSH | Often installed | None |
| Package manager | apt, dpkg, apk | None |
| Privilege escalation | sudo, setuid, capabilities | No privilege levels |
| Process visibility | Host can see all container processes | Opaque to host |
Stack Protection
Every thread stack has a hardware guard page at its base - a page mapped with no access permissions. If a stack overflow occurs, the CPU generates an immediate page fault. There is no silent corruption of adjacent memory, no buffer overrun into heap data.
The NX (No-Execute) bit is enabled: stack pages are marked non-executable, preventing code injection via stack buffer overflows.
Binary Hardening
Release binaries are built with:
- LTO (Link-Time Optimization) - whole-program optimization, dead code elimination
- Symbol stripping - all debug symbols removed, no function names in the binary
- Single codegen unit - maximum optimization across the entire codebase
No license keys, API keys, or credentials are compiled into the binary. All secrets are passed at runtime through the VM command line.
Data Integrity
SiliconFS checksums every data block with CRC32. Every read is verified before returning data. If a block is corrupted - by a disk error, firmware bug, DMA error, or bit flip - the filesystem detects it and returns an error instead of silently delivering corrupt data.
The superblock is stored in duplicate. Inodes, journal headers, and journal commits are individually checksummed. A 7-phase consistency checker runs on mount, automatically repairing any detected corruption.
See Technology for details on SiliconFS crash safety, journaling, and copy-on-write.