arXiv subjects

Vasily A. Sartakov

Publications and source records attributed to Vasily A. Sartakov.

4 recordsLinked to original sources

arXiv2026

From C to Idiomatic Rust: A Ship-of-Theseus Agentic Translation

C underpins operating systems, embedded platforms, and network infrastructure as its abstractions map directly to machine behaviour. Its explicit memory model, predictable data representations, and minimal runtime allow compilers to generate fast, deterministic code. These properties also leave correctness and memory safety entirely to the programmer, making undefined behaviour, pointer misuse, and lifetime errors persistent sources of defects and security vulnerabilities in long-lived C codebases. Rust eliminates most failure modes through a static ownership and borrowing model that enforces memory safety and aliasing constraints at compile time. However, mature C systems cannot be translated directly: implicit layout assumptions, aliasing patterns, and undefined behaviour must be reconstructed before safe Rust can be produced. This paper presents a migration methodology that first generates a semantics-preserving, non-idiomatic Rust baseline and then incrementally rewrites it into idiomatic Rust using agentic AI, validating each step through compilation and behavioural testing. Applied to iodine, a real-world DNS tunnel, the approach demonstrates that reliable C-to-Rust migration is a structured transformation workflow rather than a single translation step.

cs.SE↗

arXiv2026

Complets: Universal Compartmentalisation and Programming Model For Arm Permission Overlay Extension 2

Arm Permission Overlay Extension (POE) is an intra-process isolation mechanism based on memory protection keys. This mechanism partitions virtual memory into regions whose access permissions can be reconfigured without invoking higher exception levels. Because POE does not enforce privilege separation, POE-based protection domains are applicable only as a software fault-isolation technique. The POE2 is an isolation mechanism that substantially extends POE1. Dealing with memory protection keys, it also introduces new registers and tables that regulate the operations permitted for code executing within protection domains associated with different keys. A permission is determined by the spatial index of the executing code (i.e., the protection key associated with code), the spatial index of the accessed memory, the operation type, and a new attribute of the thread context: its temporal index. POE2 provides stronger security guarantees than POE1, but also introduces considerable architectural complexity. Effective permissions arise from the interaction of multiple hardware components, making direct programming non-trivial and prone to subtle errors. In the paper, we present a detailed analysis of POE2 and introduce a universal programming model with a strong security model for POE2-based systems. The model abstracts the complexity of spatial and temporal indices while enabling typical patterns of partitioned software constructed using intra-process isolation.

cs.OS↗

arXiv2022

CAP-VMs: Capability-Based Isolation and Sharing for Microservices

Cloud stacks must isolate application components, while permitting efficient data sharing between components deployed on the same physical host. Traditionally, the MMU enforces isolation and permits sharing at page granularity. MMU approaches, however, lead to cloud stacks with large TCBs in kernel space, and page granularity requires inefficient OS interfaces for data sharing. Forthcoming CPUs with hardware support for memory capabilities offer new opportunities to implement isolation and sharing at a finer granularity. We describe cVMs, a new VM-like abstraction that uses memory capabilities to isolate application components while supporting efficient data sharing, all without mandating application code to be capability-aware. cVMs share a single virtual address space safely, each having only capabilities to access its own memory. A cVM may include a library OS, thus minimizing its dependency on the cloud environment. cVMs efficiently exchange data through two capability-based primitives assisted by a small trusted monitor: (i) an asynchronous read-write interface to buffers shared between cVMs; and (ii) a call interface to transfer control between cVMs. Using these two primitives, we build more expressive mechanisms for efficient cross-cVM communication. Our prototype implementation using CHERI RISC-V capabilities shows that cVMs isolate services (Redis and Python) with low overhead while improving data sharing.

cs.OS↗

arXiv2020

SGX-LKL: Securing the Host OS Interface for Trusted Execution

Hardware support for trusted execution in modern CPUs enables tenants to shield their data processing workloads in otherwise untrusted cloud environments. Runtime systems for the trusted execution must rely on an interface to the untrusted host OS to use external resources such as storage, network, and other functions. Attackers may exploit this interface to leak data or corrupt the computation. We describe SGX-LKL, a system for running Linux binaries inside of Intel SGX enclaves that only exposes a minimal, protected and oblivious host interface: the interface is (i) minimal because SGX-LKL uses a complete library OS inside the enclave, including file system and network stacks, which requires a host interface with only 7 calls; (ii) protected because SGX-LKL transparently encrypts and integrity-protects all data passed via low-level I/O operations; and (iii) oblivious because SGX-LKL performs host operations independently of the application workload. For oblivious disk I/O, SGX-LKL uses an encrypted ext4 file system with shuffled disk blocks. We show that SGX-LKL protects TensorFlow training with a 21% overhead.

cs.OS↗