{"id":"83719586-0c46-4334-b8e4-9f9e85b9ee5e","arxiv_id":"2505.10217","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A RISC-V port of syscall_intercept is presented, using gateway, middle, and small patches to intercept all syscalls despite the ISA's jump range limits.","lead":"This paper reports porting the syscall_intercept library to RISC-V using three patch types to work around the ISA's short jump range and lack of nop padding. It is a systems-engineering contribution that could make user-level file systems like AdHocFS work on European RISC-V hardware.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 'all syscalls are intercepted' guarantee is unproven: the 40/45/15 patch distribution is empirical, not a completeness proof, and isolated ecalls could remain unpatched.","rationale":"The reader's weakest assumption identifies exactly the same load-bearing concern: the claim that all syscalls are intercepted depends on an empirical patch distribution that is not shown to be universal. My stress-test confirms this is the single most important gap. The paper provides a plausible engineering design but no completeness argument, no methodology for the distribution numbers, and no test results confirming that every ecall in representative libc builds receives a valid patch. This is not an internal inconsistency or a disagreement with consensus; it is a missing verification of the central guarantee. Because the reader already issued a CONDITIONAL verdict pending verification, my conclusion does not move the verdict; it reinforces it. The proposed concrete test would settle the concern: if the patch planner leaves any ecall unpatched in a real libc build, the central claim fails; if it patches all ecalls and the test suite passes, the conditional acceptance is justified.","tokens_in":3909,"tokens_out":4260,"duration_ms":42730,"concrete_test":"Clone the linked riscv branch of syscall_intercept and run its disassembler/patch planner over several real RISC-V 64 libc builds (e.g., glibc 2.36, 2.38, musl 1.2.x). Enumerate every ecall, classify it as Gateway, Middle, Small, or unpatched, and verify that zero ecalls are unpatched and that every gateway is within jal range of the patches that use it. Then run the original library's full test suite on a RISC-V board; if any ecall is unpatched or any syscall test fails, the central claim does not hold.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that every syscall in RISC-V libc is intercepted. The patching scheme requires each ecall to have either 16 bytes of relocatable surrounding instructions (Gateway/Middle) or a nearby gateway reachable by jal and a way to preserve a7 (Small). The paper itself notes that 'this requirement is not always met' before introducing gateways, but it never shows the gateway construction is complete: a libc build could contain an ecall embedded in a 6-byte region whose nearest gateway is beyond the ±1MiB jal range, or whose neighboring instructions include branch targets that cannot be relocated without fix-up. The 'approximately 40% Gateway, 45% Small, 15% Middle' statement is a per-version empirical distribution, not a universal bound; no methodology, libc versions, or counts are given. Without a tool that enumerates ecalls and proves each is assigned a valid patch, 'ensures that all syscalls are intercepted' is not supported. The 'fully functional' claim is likewise not backed by test results; the paper lists missing test cases as a next step.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":4023,"tokens_out":3595,"duration_ms":36529,"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":[{"comment":"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.","section":"Solution"},{"comment":"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.","section":"Overhead compared to x86"},{"comment":"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.","section":"Solution"},{"comment":"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.","section":"Current status and next steps"}],"minor_comments":[{"comment":"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.","section":"Trade-offs"},{"comment":"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.","section":"Differences between the RISC-V and the x86 version"},{"comment":"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.","section":"Solution"},{"comment":"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.","section":"Introduction and motivation"}],"recommendation":"major_revision","confidential_remarks":"This is a poster-length systems paper with a useful engineering result, but the central completeness and performance claims need substantiation. The most important fixes are providing an ecall-site enumeration for the 'all syscalls' claim, a proper measurement methodology, and a register-level explanation of the Small Patch. If those are added, the paper could be acceptable for a workshop or short-paper venue; as is, the evidence is too thin for a full journal article."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a real port, not a slideware exercise, and the design solution is clever. But the paper's central claims are ahead of its evidence.\n\nWhat's new is the adaptation of syscall_intercept to RISC-V. The ISA-specific obstacles—short jal range, absence of nop-trampolines, and the kernel preserving caller-saved registers—are real, and the three patch types (Gateway, Middle, Small) are a sensible way around them. The shared entry point with dynamic patch identification is a meaningful difference from the x86/PowerPC/ARM ports, and the memory footprint reduction from 1.37MiB to 192KiB is concrete. This is useful engineering for the RISC-V ecosystem.\n\nThe paper also does some things well. It explains the constraints clearly, positions the work as an incremental port, and is honest about next steps. The trade-off section shows they thought about the design space.\n\nThe soft spots are in proportion. The load-bearing assertion that 'this system ensures that all syscalls are intercepted' is not backed up. The 40/45/15 patch distribution is presented without methodology; no libc versions, disassembly counts, or a proof that every ecall is covered. The stress-test note is right: an ecall could fall outside all patch types, and the paper does not show that cannot happen. The overhead numbers have no sample sizes, standard deviations, or benchmark description, so the -35% and +5% figures are hard to evaluate. Most noticeably, the text says the library is 'fully functional' and a 'cost-free replacement' two paragraphs before listing missing test cases as a next step. That is a real inconsistency. This does not mean the port is fake—the design is plausible, and the linked repository would let a competent group verify it—but the manuscript as written overstates the evidence.\n\nWho is this for? People building syscall-interception-based file systems on RISC-V, and the broader EU RISC-V software effort. It's a short poster paper, not a systems breakthrough. I'd send it to peer review because the engineering is real and the design is worth describing to a specialist audience, but I'd require the authors to add reproducibility details: how the distribution was measured, what benchmarks were run, and a version of the completeness claim qualified to the libc builds they actually tested.\n\nIf I were refereeing, I'd ask for a revised version that either provides the missing measurements or tones the claims down to match what is shown.","headline":"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.","tokens_in":4612,"tokens_out":2777,"would_cite":false,"duration_ms":24745,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"RISC-V syscall interception works by patching ecall sites with 16-byte redirects.","keywords":["syscall interception","RISC-V","binary patching","ecall","dynamic instrumentation","ephemeral file systems","user-level file systems","libc"],"falsifier":"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.","tokens_in":3641,"feed_emoji":"🐧","tokens_out":4178,"duration_ms":35965,"temperature":0.7,"pith_summary":"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.","feed_headline":"16-byte patches reroute every RISC-V syscall to one entry point","feed_subtitle":"User-level file systems can intercept syscalls on RISC-V without kernel changes.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[],"fun_headline_variants":["One entry point for all RISC-V syscalls via 16-byte patches","RISC-V syscall interception without kernel changes for user-level FS","Patching ecall sites to reroute RISC-V syscalls to a shared handler","Enabling AdHocFS on RISC-V: syscall interception via 16-byte patches"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["One entry point for all RISC-V syscalls via 16-byte patches","RISC-V syscall interception without kernel changes for user-level FS","Patching ecall sites to reroute RISC-V syscalls to a shared handler","Enabling AdHocFS on RISC-V: syscall interception via 16-byte patches"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000615,"raw_usage":{"total_tokens":2797,"prompt_tokens":825,"completion_tokens":1972,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":441,"completion_tokens_details":{"reasoning_tokens":1881}},"tokens_in":441,"tokens_out":1972,"duration_ms":15314,"temperature":1.0,"reasoning_tokens":1881,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T21:12:50.575692+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}