pith. machine review for the scientific record. sign in

arxiv: 2604.14357 · v1 · submitted 2026-04-15 · 💻 cs.PL · cs.CR

Recognition: unknown

Filament: Denning-Style Information Flow Control for Rust

Jeffrey C. Ching , Quan Zhou , Danfeng Zhang
Authors on Pith no claims yet

Pith reviewed 2026-05-10 11:19 UTC · model grok-4.3

classification 💻 cs.PL cs.CR
keywords information flow controlRuststatic securitylibrary-based IFCexplicit flowsimplicit flowsmacrostype inference
0
0 comments X

The pith

Filament adds information flow control to Rust without compiler changes

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

The paper shows how to build a fine-grained static information flow control system for Rust that works as a library instead of requiring compiler changes. It achieves this by using Rust type inference to check explicit flows with little annotation and by adding macros to manage implicit flows and calls to other code. This approach matters for developers who want to prevent secret data from leaking in their programs while still writing normal Rust code. It offers a less restrictive way to add security checks than earlier library-based methods. Readers would care because it makes strong compile-time security practical in a widely used language.

Core claim

Filament is a static information flow control library for Rust that enforces both explicit and implicit flows at compile time with no compiler modifications. It uses Rust's type inference to reduce annotation needs for explicit flows, introduces the pc_block! macro to track a program counter label for implicit flows, and supplies fcall! and mcall! macros to allow safe calls into standard and third-party libraries. Evaluation shows negligible compile-time overhead, modest annotation requirements, and a more permissive programming model that reduces the need for escape hatches.

What carries the argument

The pc_block!, fcall!, and mcall! macros working together with Rust type inference to track security labels on data and control flow at compile time.

Load-bearing premise

The macros and type inference are enough to block all explicit and implicit flows without missing leaks or creating new channels, even when third-party libraries are used.

What would settle it

A concrete Rust program that uses Filament yet compiles successfully while allowing a high-security value to influence a low-security output through control flow or a library call.

Figures

Figures reproduced from arXiv: 2604.14357 by Danfeng Zhang, Jeffrey C. Ching, Quan Zhou.

Figure 1
Figure 1. Figure 1: The implementation of player function of battleship game in [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Implicit flow in the calendar example. 3.2 Implicit Flows Figure 2a presents a code snippet from Cocoon’s implementation of a calendar program that determines the mutual availability of Alice and Bob, where each person’s calendar is considered confidential. Because Cocoon does not distinguish implicit flows from explicit flows, the entire branch between lines 6 and 9 must be enclosed within secret_block!, … view at source ↗
Figure 3
Figure 3. Figure 3: Comparison of set_device_id function. Cocoon requires declassify_ref() at every serde and I/O call boundary, and a secret_block_no_return! with unwrap_secret_mut_ref to mutate a single field. Our library uses fcall! and mcall! to thread the label through all calls. third party functions, and then (2) rewrap the returned values immediately afterward (line 2). However, this approach introduces a security ris… view at source ↗
Figure 4
Figure 4. Figure 4: Filament APIs. shown to the left. Note that since Filament treats all “unlabeled” types as public data (i.e., label Public in a lattice), we only need to define three non-public labels and their relation in Figure 5c. Moreover, the join operation is defined as a trait that computes the least upper bound of two security labels at compile time, producing an associated output type Out that represents the resu… view at source ↗
Figure 5
Figure 5. Figure 5: A four-element security lattice. (a) illustrates the lattice hierarchy (ℓ [PITH_FULL_IMAGE:figures/full_fig_p011_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Comparison of the random function implementation in the Battleship case study. similar restrictions only within pc_block!. Notably, this construct is required only for branches conditioned on sensitive values and is used only once in Spotify TUI. A second contributing factor is the introduction of the mcall!, fcall!, and relabel! macros, which eliminate the need to declassify labeled parameters when invoki… view at source ↗
read the original abstract

Existing language-based information-flow control (IFC) tools face a fundamental tension: Denning-style systems that track explicit and implicit flows at the variable level typically require compiler modifications, while more coarse-grained approaches, including recent work Cocoon, avoid compiler changes but impose more restrictive programming models. We present Filament, a Denning-style static IFC library for Rust that requires no compiler modifications. Filament addresses three key challenges in building a practical IFC library for Rust. First, it enables fine-grained explicit-flow checking with minimal annotation overhead by leveraging Rust's type inference. Second, it introduces pc_block!, a lightweight construct for enforcing implicit flows via a compile-time program counter label, without requiring compiler support. Third, it provides fcall! and mcall! macros to support seamless and safe interoperability with standard and third-party libraries. Our evaluation shows that Filament incurs negligible compile-time overhead and requires only modest annotations. Moreover, compared to Cocoon, Filament offers a more permissive programming model, reducing the need for frequent escape hatches that bypass security checks.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The manuscript presents Filament, a Denning-style static information-flow control library for Rust implemented without compiler modifications. It uses Rust type inference to minimize annotations for explicit flows, introduces the pc_block! macro to track implicit flows via a compile-time program-counter label, and supplies fcall! and mcall! macros to enable safe calls into standard and third-party libraries. The central claims are that the approach enforces both explicit and implicit flows, incurs negligible compile-time overhead, requires only modest annotations, and provides a more permissive programming model than Cocoon by reducing the need for escape hatches.

Significance. If the security properties hold for realistic code, Filament demonstrates a viable engineering path for fine-grained IFC in an existing systems language without language extensions. This is significant because it lowers the barrier to adoption compared with compiler-based IFC systems while addressing the restrictiveness of prior library-based approaches such as Cocoon. The emphasis on leveraging existing Rust features (type inference, macros) for both security and usability is a concrete contribution to practical secure programming.

major comments (2)
  1. [Design and Implementation (around the macro definitions)] The abstract and introduction assert that pc_block!, fcall!, and mcall! together with Rust type inference suffice to enforce both explicit and implicit flows without introducing new leakage channels or requiring runtime checks. However, the manuscript provides no formal argument or proof sketch showing that these macros close all implicit-flow channels when third-party libraries are involved or when control flow depends on labeled values. This is load-bearing for the central security claim.
  2. [Evaluation] Evaluation claims 'negligible compile-time overhead' and 'modest annotations' and a reduction in escape hatches relative to Cocoon, yet the provided text contains no quantitative data, benchmarks, or annotation counts. If §Evaluation does not report concrete numbers (e.g., compile-time deltas, lines of annotation per LOC, or escape-hatch counts on the evaluated programs), the comparative claims cannot be assessed.
minor comments (2)
  1. [Introduction] The threat model and attacker assumptions (e.g., whether the adversary controls third-party crates or can observe timing) are not stated explicitly; adding a short dedicated paragraph would clarify the scope of the guarantees.
  2. [Background] Notation for labels and the program-counter label is introduced informally; a small table or diagram summarizing the label lattice and how pc_block! updates it would improve readability.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the careful reading and constructive feedback. We address the two major comments point by point below and indicate the revisions we will make to strengthen the manuscript.

read point-by-point responses

  1. Referee: [Design and Implementation (around the macro definitions)] The abstract and introduction assert that pc_block!, fcall!, and mcall! together with Rust type inference suffice to enforce both explicit and implicit flows without introducing new leakage channels or requiring runtime checks. However, the manuscript provides no formal argument or proof sketch showing that these macros close all implicit-flow channels when third-party libraries are involved or when control flow depends on labeled values. This is load-bearing for the central security claim.

    Authors: We agree that an explicit argument for the absence of new leakage channels is necessary to support the central security claim. The current manuscript presents an informal argument grounded in the design of the macros and the guarantees of Rust's type system and borrow checker, but does not include a proof sketch. In the revised version we will add a dedicated subsection that sketches the security argument: pc_block! maintains a compile-time program-counter label that is joined into the label of every expression inside the block, fcall! and mcall! propagate labels through library boundaries by requiring explicit label annotations on the call site, and Rust's type inference together with the macro hygiene rules prevent label erasure. We will also discuss the assumptions under which third-party code cannot introduce leaks (i.e., that it respects the Rust type system and does not use unsafe code to bypass the macros). revision: yes

  2. Referee: [Evaluation] Evaluation claims 'negligible compile-time overhead' and 'modest annotations' and a reduction in escape hatches relative to Cocoon, yet the provided text contains no quantitative data, benchmarks, or annotation counts. If §Evaluation does not report concrete numbers (e.g., compile-time deltas, lines of annotation per LOC, or escape-hatch counts on the evaluated programs), the comparative claims cannot be assessed.

    Authors: The referee is correct that the current evaluation section states the qualitative claims without accompanying quantitative data. We will revise §Evaluation to include concrete measurements: (1) compile-time overhead reported as percentage increase over baseline Rust compilation for the evaluated programs, (2) annotation density expressed as number of label annotations and macro invocations per thousand lines of code, and (3) a side-by-side count of escape-hatch uses required by Filament versus Cocoon on the same case studies. These numbers will be obtained from the existing benchmark suite and will be presented in a new table. revision: yes

Circularity Check

0 steps flagged

No significant circularity; design is self-contained engineering contribution

full rationale

The paper presents Filament as a library-based IFC system for Rust that leverages existing language features (type inference, macros for pc_block!, fcall!, mcall!) to enforce Denning-style tracking without compiler changes. No equations, fitted parameters, predictions, or first-principles derivations are present that could reduce to inputs by construction. The central claims rest on the described implementation and empirical evaluation (compile-time overhead, annotation count, permissiveness vs. Cocoon), which are independent of any self-referential definitions or load-bearing self-citations. The approach is positioned as an engineering trade-off relying on Rust's type system rather than any circular justification.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 2 invented entities

The design rests on the assumption that Rust's macro and type systems can faithfully encode IFC labels and that the new macros correctly raise the program-counter label for implicit flows.

axioms (1)
  • domain assumption Rust's type inference and macro expansion can be used to propagate and check security labels without compiler modifications.
    Core premise stated in the abstract for achieving Denning-style checking.
invented entities (2)
  • pc_block! macro no independent evidence
    purpose: Enforce implicit flows at compile time via a program-counter label
    New construct introduced to avoid compiler changes.
  • fcall! and mcall! macros no independent evidence
    purpose: Provide safe interoperability with standard and third-party libraries
    New wrappers to prevent leakage through external calls.

pith-pipeline@v0.9.0 · 5481 in / 1326 out tokens · 34512 ms · 2026-05-10T11:19:30.110122+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

42 extracted references

  1. [1]

    [n. d.]. Filament Implementation. https://github.com/jeffreyccching/filament-ifc-proto

  2. [2]

    Cocoon-implementation

    2024. Cocoon-implementation. https://github.com/PLaSSticity/Cocoon-implementation/

    2024

  3. [3]

    Jif:Java+ Information Flow

    2026. Jif:Java+ Information Flow. https://www.cs.cornell.edu/jif/. Accessed: 2026-03-13

    2026

  4. [4]

    Vincent Beardsley, Chris Xiong, Ada Lamba, and Michael D Bond. 2025. Carapace: Static–Dynamic Information Flow Control in Rust.Proceedings of the ACM on Programming Languages9, OOPSLA1 (2025), 364–392

    2025

  5. [5]

    1973.Secure computer systems: Mathematical foundations

    D Elliot Bell and Leonard J LaPadula. 1973.Secure computer systems: Mathematical foundations. Technical Report

    1973

  6. [6]

    Pablo Buiras, Dimitrios Vytiniotis, and Alejandro Russo. 2015. HLIO: Mixing static and dynamic typing for information- flow control in Haskell. InProceedings of the 20th ACM SIGPLAN International Conference on Functional Programming. 289–301

    2015

  7. [7]

    Clarkson, Stephen Chong, and Andrew C

    Michael R. Clarkson, Stephen Chong, and Andrew C. Myers. 2008. Civitas: Toward a Secure Voting System. In2008 IEEE Symposium on Security and Privacy (SP 2008). IEEE, Oakland, CA, USA, 354–368

    2008

  8. [8]

    Will Crichton, Marco Patrignani, Maneesh Agrawala, and Pat Hanrahan. 2022. Modular information flow through ownership. InProceedings of the 43rd ACM SIGPLAN International Conference on Programming Language Design and Implementation. 1–14

    2022

  9. [9]

    Dorothy E Denning. 1976. A lattice model of secure information flow.Commun. ACM19, 5 (1976), 236–243

    1976

  10. [10]

    Dorothy E Denning and Peter J Denning. 1977. Certification of programs for secure information flow.Commun. ACM 20, 7 (1977), 504–513

    1977

  11. [11]

    Petros Efstathopoulos, Maxwell Krohn, Steve VanDeBogart, Cliff Frey, David Ziegler, Eddie Kohler, David Mazieres, Frans Kaashoek, and Robert Morris. 2005. Labels and event processes in the Asbestos operating system.ACM SIGOPS Operating Systems Review39, 5 (2005), 17–30

    2005

  12. [12]

    Earlence Fernandes, Justin Paupore, Amir Rahmati, Daniel Simionato, Mauro Conti, and Atul Prakash. 2016. {FlowFence}: Practical data protection for emerging{IoT} application frameworks. In25th USENIX security symposium (USENIX Security 16). 531–548

    2016

  13. [13]

    Simon Gregersen, Søren Eller Thomsen, and Aslan Askarov. 2019. A dependently typed library for static information- flow control in Idris. InInternational Conference on Principles of Security and Trust. Springer, 51–75

    2019

  14. [14]

    Stefan Heule, Deian Stefan, Edward Z Yang, John C Mitchell, and Alejandro Russo. 2015. IFC inside: Retrofitting languages with dynamic information flow control. InInternational Conference on Principles of Security and Trust. Springer, 11–31

    2015

  15. [15]

    Boniface Hicks, Kiyan Ahmadizadeh, and Patrick McDaniel. 2006. From languages to systems: Understanding practical application development in security-typed languages. In2006 22nd Annual Computer Security Applications Conference (ACSAC’06). IEEE, 153–164

    2006

  16. [16]

    Andrew Johnson, Lucas Waye, Scott Moore, and Stephen Chong. 2015. Exploring and enforcing security guarantees via program dependence graphs.ACM SIGPLAN Notices50, 6 (2015), 291–302

    2015

  17. [17]

    Elisavet Kozyri, Owen Arden, Andrew C Myers, and Fred B Schneider. 2019. JRIF: reactive information flow control for java. InFoundations of Security, Protocols, and Equational Reasoning: Essays Dedicated to Catherine A. Meadows. Springer, 70–88

    2019

  18. [18]

    Elisavet Kozyri and Fred B Schneider. 2020. RIF: Reactive information flow labels.Journal of Computer Security28, 2From dynamic to static and back: Ridi (2020), 191–228. 24 Jeffrey C. Ching, Quan Zhou, and Danfeng Zhang

    2020

  19. [19]

    Maxwell Krohn, Alexander Yip, Micah Brodsky, Natan Cliffer, M Frans Kaashoek, Eddie Kohler, and Robert Morris

  20. [20]

    Information flow control for standard OS abstractions.ACM SIGOPS Operating Systems Review41, 6 (2007), 321–334

    2007

  21. [21]

    Ada Lamba, Max Taylor, Vincent Beardsley, Jacob Bambeck, Michael D Bond, and Zhiqiang Lin. 2024. Cocoon: Static Information Flow Control in Rust.Proceedings of the ACM on Programming Languages8, OOPSLA1 (2024), 166–193

    2024

  22. [22]

    Peng Li and Steve Zdancewic. 2006. Encoding information flow in Haskell. In19th IEEE Computer Security Foundations Workshop (CSFW’06). IEEE, 12–pp

    2006

  23. [23]

    Peixuan Li and Danfeng Zhang. 2022. Towards a General-Purpose Dynamic Information Flow Policy. In2022 IEEE 35th Computer Security Foundations Symposium (CSF). IEEE, Haifa, Israel, 260–275

    2022

  24. [24]

    Jed Liu, Michael D George, Krishnaprasad Vikram, Xin Qi, Lucas Waye, and Andrew C Myers. 2009. Fabric: A platform for secure distributed computation and storage. InProceedings of the ACM SIGOPS 22nd symposium on Operating systems principles. 321–334

    2009

  25. [25]

    Andrew C Myers. 1999. JFlow: Practical mostly-static information flow control. InProceedings of the 26th ACM SIGPLAN-SIGACT symposium on Principles of programming languages. 228–241

    1999

  26. [26]

    Andrew C Myers and Barbara Liskov. 1997. A decentralized model for information flow control.ACM SIGOPS Operating Systems Review31, 5 (1997), 129–142

    1997

  27. [27]

    Nadia Polikarpova, Deian Stefan, Jean Yang, Shachar Itzhaky, Travis Hance, and Armando Solar-Lezama. 2020. Liquid information flow control.Proceedings of the ACM on Programming Languages4, ICFP (2020), 1–30

    2020

  28. [28]

    François Pottier and Vincent Simonet. 2002. Information flow inference for ML. InProceedings of the 29th ACM SIGPLAN-SIGACT symposium on Principles of programming languages. 319–330

    2002

  29. [29]

    Vineet Rajani, Iulia Bastys, Willard Rafnsson, and Deepak Garg. 2017. Type systems for information flow control: The question of granularity.ACM SIGLOG News4, 1 (2017), 6–21

    2017

  30. [30]

    Vineet Rajani and Deepak Garg. 2018. Types for information flow control: Labeling granularity and semantic models. In2018 IEEE 31st Computer Security Foundations Symposium (CSF). IEEE, 233–246

    2018

  31. [31]

    Vineet Rajani and Deepak Garg. 2020. On the expressiveness and semantics of information flow types.Journal of Computer Security28, 1 (2020), 129–156

    2020

  32. [32]

    Indrajit Roy, Donald E Porter, Michael D Bond, Kathryn S McKinley, and Emmett Witchel. 2009. Laminar: Practical fine- grained decentralized information flow control. InProceedings of the 30th ACM SIGPLAN conference on programming language design and implementation. 63–74

    2009

  33. [33]

    Alejandro Russo. 2015. Functional pearl: two can keep a secret, if one of them uses Haskell.ACM SIGPLAN Notices50, 9 (2015), 280–288

    2015

  34. [34]

    Alejandro Russo, Koen Claessen, and John Hughes. 2008. A library for light-weight information-flow security in Haskell.ACM Sigplan Notices44, 2 (2008), 13–24

    2008

  35. [35]

    Andrei Sabelfeld and Andrew C. Myers. 2003. Language-based information-flow security.IEEE Journal on Selected Areas in Communications21, 1 (January 2003), 5–19

    2003

  36. [36]

    Vincent Simonet. 2003. The flow caml system.Software release. Located at http://cristal. inria. fr/˜ simonet/soft/flowcaml 116 (2003), 119–156

    2003

  37. [37]

    Mitchell, and David Mazières

    Deian Stefan, Alejandro Russo, John C. Mitchell, and David Mazières. 2011. Flexible Dynamic Information Flow Control in Haskell. InProceedings of the 4th ACM Symposium on Haskell. ACM, Tokyo, Japan, 95–106

    2011

  38. [38]

    Marco Vassena, Alejandro Russo, Pablo Buiras, and Lucas Waye. 2018. Mac a verified static information-flow control library.Journal of logical and algebraic methods in programming95 (2018), 148–180

    2018

  39. [39]

    Marco Vassena, Alejandro Russo, Deepak Garg, Vineet Rajani, and Deian Stefan. 2019. From fine-to coarse-grained dynamic information flow control and back.Proceedings of the ACM on Programming Languages3, POPL (2019), 1–31

    2019

  40. [40]

    Dennis Volpano, Cynthia Irvine, and Geoffrey Smith. 1996. A sound type system for secure flow analysis.Journal of computer security4, 2-3 (1996), 167–187

    1996

  41. [41]

    Nickolai Zeldovich, Silas Boyd-Wickizer, and David Mazieres. 2008. Securing Distributed Systems with Information Flow Control.. InNSDI, Vol. 8. 293–308

    2008

  42. [42]

    Quan Zhou, Sixuan Dang, and Danfeng Zhang. 2024. CtCheker: A Precise, Sound and Efficient Static Analysis for Constant-Time Programming. In38th European Conference on Object-Oriented Programming (ECOOP 2024). Schloss Dagstuhl–Leibniz-Zentrum für Informatik, 46–1

    2024