Pith. sign in

REVIEW 4 major objections 4 minor 3 references

Enabling Syscall Intercept for RISC-V

T0 review · 4 major / 4 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read RISC-V syscall interception works by patching ecall sites with 16-byte redirects.

desk verdict A genuine RISC-V port with a clever shared-entry-point design; the all-syscalls-intercepted guarantee and overhead numbers are asserted more strongly than the evidence supports. read the letter →

arxiv 2505.10217 v1 pith:ZYX6OVHQ submitted 2025-05-15 cs.OS cs.AR

Petar Andrić , Aaron Call , Ramon Nou This is my paper · ORCID
classification cs.OScs.AR
keywords syscallinterceptionRISC-Vbinarypatchingecalldynamicinstrumentationephemeralfilesystemsuser-levellibc
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper reports a port of a widely used syscall-interception library to RISC-V. The port had to solve three obstacles: the jal instruction's ±1MiB reach, the scarcity of nop instructions for trampolines, and the kernel's preservation of the full register context. The solution is a 16-byte patch that redirects every ecall to a single shared assembly entry point, using three patch shapes—Gateway, Middle, and Small—depending on how much relocatable code surrounds the ecall. The authors claim the library is fully functional, intercepts all syscalls, and serves as a drop-in replacement on RISC-V, opening user-level ephemeral file systems to RISC-V HPC systems.

What carries the argument

The load-bearing mechanism is a 16-byte patch inserted at each ecall site, formed from auipc+jalr plus the prologue and epilogue needed to preserve the jumping register. Because RISC-V compressed instructions are common, four to seven relocatable instructions are replaced. The design funnels every patched ecall into one shared entry point, asm_entry_point, and identifies which patch was taken from the return address, then hands execution to the corresponding relocated instructions. The three patch types—Gateway, Middle, and Small—are chosen by the amount of patch space available, and the syscall number for Small patches is captured statically during runtime disassembly.

What would settle it

Disassemble a complete RISC-V libc and enumerate the relocatable instructions immediately surrounding every ecall; if any ecall lacks a 16-byte patch opportunity and has no gateway within ±1MiB, interception of that syscall will fail, contradicting the claim that all syscalls are intercepted.

Watch

Extended reading notes

Core claim

The central claim is that syscall interception can be made to work on RISC-V despite the ISA's short-range jumps and lack of nop-trampolines. The implementation redirects all syscalls to a shared entry point, asm_entry_point, by patching each ecall site with one of three patch types: Gateway patches (auipc+jalr, roughly ±2GiB), Middle patches (jal ra to a gateway), and Small patches (jal a7 to a gateway, with the syscall number extracted from the immediate that sets a7 and later restored). Patch distribution is about 40 percent Gateway, 45 percent Small, and 15 percent Middle. The authors state that the library is fully functional and a cost-free replacement for the original library, with RISC-V overhead of -35 percent in user-mode interception and +5 percent in kernel-mode interception, and a memory footprint reduced to 192KiB versus 1.37MiB on x86.

Load-bearing premise

The claim depends on real-world RISC-V libc builds having enough relocatable instructions around each ecall to place a 16-byte patch, with roughly 40 percent gateway, 45 percent small, and 15 percent middle patches available; if a libc version has many isolated ecalls surrounded by only one compressed instruction, some syscalls would escape interception.

Editorial extensions

If this is right

  • A RISC-V application that bypasses libc can still be intercepted, because patching acts on the binary's ecall sites rather than on libc wrappers.
  • Ephemeral, per-job file systems can be deployed on RISC-V HPC nodes without kernel privileges, since the interception happens in user space.
  • All clone() variants and their results are visible to the interception layer, so thread-aware file-system hooks can be built on RISC-V.
  • The shared-entry-point design keeps memory use at O(n) in the number of patches, roughly one order of magnitude less than the x86 design.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the 40/45/15 patch distribution shifts in other libc builds, porting to musl or newer glibc may need a fourth patch type or a longer-range jump strategy; the paper only reports the distribution for the libc versions it tested.
  • The static extraction of the syscall number from the immediate that sets a7 could generalize to identifying syscall numbers on other RISC-V calling conventions, or to filtering which syscalls get patched, which the paper lists as future work.
  • Because all patches share one entry point and are identified by return address, the overhead could increase with patch density; an alternative direct-branch design might trade memory for speed on workloads dominated by intercepted syscalls.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper reports a port of the syscall_intercept dynamic binary patching library to RISC-V. Because RISC-V's jal instruction has a limited ±1MiB reach, instructions are naturally aligned with few nop-trampolines, and the Linux kernel preserves the full register context on interrupts, the authors propose three patch types—Gateway, Middle, and Small—all redirecting execution to a shared assembly entry point in syscall_intercept. The paper reports execution-time overhead and memory usage measurements, claims that the RISC-V implementation is 'fully functional' and a 'cost-free replacement' for the x86 version, and lists future work including missing test cases and a syscall filter.

Significance. If the implementation is correct, this work is a useful engineering contribution for enabling syscall-interception-based ephemeral file systems on RISC-V, and the shared-entry-point design with reduced memory footprint is an interesting departure from the x86 design. The paper is honest about several architectural obstacles and provides concrete patch classifications. However, the central claims are supported by anecdotal distribution numbers and bare median overhead values rather than a repeatable evaluation, so the significance is currently limited by the lack of evidence.

major comments (4)
  1. [Solution] The paragraph beginning 'Patch distribution is approximately 40% Gateway, 45% Small, and 15% Middle' and the following sentence 'This system ensures that all syscalls are intercepted' are not justified by the evidence in the paper. No libc version, counting methodology, or completeness argument is given for the 40/45/15 distribution, and the paper itself notes that the required relocatable-instruction space 'is not always met.' The guarantee 'all syscalls are intercepted' requires either a formal argument that every ecall in a supported libc build has an eligible Gateway, Middle, or Small patch, or a tool that enumerates ecall sites and reports the assigned patch type. Please provide such an enumeration for at least one concrete libc version and state the exact condition under which the guarantee holds.
  2. [Overhead compared to x86] The overhead evaluation reports medians of -70%, 2%, -35%, and 5% but gives no measurement methodology: no benchmark harness, no number of iterations or samples, no standard deviations or confidence intervals, no warmup policy, and no description of how the 'Intercepted Cost (User Mode)' scenario bypasses the kernel. Without these details, the reader cannot assess whether the differences are statistically meaningful or whether the 'cost-free replacement' claim in 'Current status and next steps' is supported.
  3. [Solution] The Small Patch description raises a correctness question that is not resolved by the text. The paper states that 'The patch uses jal a7, <gateway address>' and that a7's original value 'is later restored inside syscall_intercept.' Since jal overwrites a7 with the return address, the text must explain how the original a7 value (the syscall number, or its source) is recovered before the relocated instructions execute. The paper says the syscall number is extracted and stored in the patch structure, but it does not provide a register-level trace showing where that stored value is loaded and into which register. Because Small patches are claimed to cover roughly 45% of ecall sites, this omission is load-bearing for the correctness claim.
  4. [Current status and next steps] The sentence 'The library is fully functional and is a cost-free replacement for the original library' is stronger than the evidence and is also internally qualified by the next sentence, which lists 'implementing all the missing test cases' as a next step. A library with missing test cases can still be functional, but 'fully functional' and 'cost-free' need precise definitions; in particular, 'cost-free' is inconsistent with the 5% kernel-mode overhead reported in the Overhead section. Please replace this sentence with a qualified statement that distinguishes functional completeness from performance cost.
minor comments (4)
  1. [Trade-offs] The phrase 'slightly increases runtime overhead' is vague; please quantify with a reference to the Overhead section or state that a quantitative comparison will be provided.
  2. [Differences between the RISC-V and the x86 version] The function syscall_no_intercept() is mentioned without a definition or a pointer to its role in the original syscall_intercept API; a brief explanation would help readers unfamiliar with the library.
  3. [Solution] Footnote 5 about the 2's complement bias gives exact hexadecimal bounds but does not state whether these bounds apply to the auipc+jalr sequence or to the full patch offset; please clarify the address arithmetic.
  4. [Introduction and motivation] The list of prior ports (ARM by RIKEN, PowerPC by the authors' institution) should include the repository URLs or references for those ports, since the reader may want to compare the RISC-V changes against them.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports an engineering port with measured overheads and no derivation that reduces to its own inputs.

full rationale

The paper is a systems/engineering report on porting the syscall_intercept library to RISC-V. It contains no fitted parameters, no equations whose outputs reproduce their inputs, and no predictive claim derived from a model that was itself calibrated on the claimed result. The central assertions are implementation claims: that a 16-byte patch can be constructed from relocatable instructions, that gateway/middle/small patch types handle less spacious ecall sites, and that the resulting library intercepts syscalls. These are supported by code-level reasoning and by overhead measurements benchmarked against a normal syscall baseline, not by a self-referential derivation. The stated patch distribution of approximately 40% Gateway, 45% Small, and 15% Middle is an empirical observation about particular libc builds, not a fitted parameter later renamed as a prediction; even if the distribution is incomplete as a universal guarantee, that is a correctness/evidence concern, not circularity. The only self-references are URLs to prior porting efforts on ARM and PowerPC, and these are acknowledgments of lineage rather than load-bearing justification for the RISC-V port's correctness. No uniqueness theorem, ansatz, or known result is imported via self-citation. I therefore find no step in which the paper's conclusions are equivalent, by construction or by citation, to its own assumptions.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The port rests on hardware and kernel behavior assumptions that are standard for RISC-V, plus an empirical claim about libc layout that is not backed by a reproducible measurement. The paper does not introduce new theoretical constructs, fitted parameters, or invented entities.

assumptions (3)
  • domain assumption RISC-V jal has a range of approximately ±1MiB, and auipc+jalr provides approximately ±2GiB
    Stated as a hardware constraint in the Obstacles and Solution sections; this is a well-known ISA property, but the paper does not state the exact encoding details or the 4KiB offset bias.
  • domain assumption The Linux kernel on RISC-V saves the full register context during interrupts, so caller-saved registers cannot be safely overwritten
    Given as Obstacles point 3, and used to justify preserving the calling convention with explicit prologue and epilogue code. This is a plausible kernel behavior claim, but no kernel source reference is given.
  • domain assumption Real-world RISC-V libc builds contain a sufficient number of relocatable instructions around each ecall, and the patch opportunities are distributed approximately 40% Gateway, 45% Small, and 15% Middle
    Stated in the Solution section without measurement methodology or version-specific data. The entire patching strategy depends on this empirical distribution holding across libc versions.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Enabling Syscall Intercept for RISC-V." pith.science (2026). https://pith.science/paper/ZYX6OVHQ

@misc{pith2026250510217,
  author       = {Pith},
  title        = {Pith review of: Enabling Syscall Intercept for RISC-V},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZYX6OVHQ}},
  note         = {Machine review of arXiv:2505.10217}
}
read the original abstract

The European Union technological sovereignty strategy centers around the RISC-V Instruction Set Architecture, with the European Processor Initiative leading efforts to build production-ready processors. Focusing on realizing a functional RISC-V ecosystem, the BZL initiative (www.bzl.es) is making an effort to create a software stack along with the hardware. In this work, we detail the efforts made in porting a widely used syscall interception library, mainly used on AdHocFS (i.e., DAOS, GekkoFS), to RISC-V and how we overcame some of the limitations encountered.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

3 extracted references · 1 canonical work pages

  1. [1]

    European Processor Initiative: The In- dustrial Cornerstone of EuroHPC for Exascale Era

    Mario Kovač. “European Processor Initiative: The In- dustrial Cornerstone of EuroHPC for Exascale Era”. In: Proceedings of the 16th ACM International Conference on Computing Frontiers . CF ’19. Alghero, Italy: Asso- ciation for Computing Machinery, 2019, p. 319. isbn: 9781450366854. doi: 10 . 1145 / 3310273 . 3323432. url: https://doi.org/10.1145/3310273.3323432

    arXiv 2019

  2. [2]

    Ad Hoc File Systems for High- Performance Computing

    André Brinkmann et al. “Ad Hoc File Systems for High- Performance Computing”. In:Journal of Computer Sci- ence and Technology 35.1 (2020), pp. 4–26.doi: 10.1007/ s11390 - 020 - 9801 - 1. url: https : / / www . sciopen . com / article/10.1007/s11390-020-9801-1

    work page doi:10.1007/s11390-020-9801-1 2020

  3. [3]

    Understanding and Predicting Cross-Application I/O Interference in HPC Storage Sys- tems

    Chris Egersdoerfer et al. “Understanding and Predicting Cross-Application I/O Interference in HPC Storage Sys- tems”. In: SC24-W: Workshops of the International Con- ference for High Performance Computing, Networking, Storage and Analysis . 2024, pp. 1330–1339.doi: 10.1109/ SCW63240.2024.00174. 3

    arXiv 2024

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.