pith. sign in

arxiv: 1907.03710 · v1 · pith:QOCZKCKHnew · submitted 2019-07-08 · 💻 cs.CR

StackVault: Protection from Untrusted Functions

Qi Zhang , Zehra Sura , Ashish Kundu , Gong Su , Arun Iyengar , Ling Liu This is my paper

Pith reviewed 2026-05-25 01:04 UTC · model grok-4.3

classification 💻 cs.CR
keywords stack protectionintra-process securitykernel moduleuntrusted functionsdata exfiltrationaccess monitoringcompiler extensionsensitive data
0
0 comments X

The pith

StackVault blocks untrusted functions from accessing sensitive stack data using kernel-enforced spatial and temporal controls.

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

StackVault is a kernel-based system that stops sensitive data stored on the stack, or pointed to by stack variables, from being reached by untrusted functions running inside the same process. Developers mark the data to protect with simple APIs, after which a kernel module uses unforgeable function identities to monitor and restrict access, while an LLVM compiler extension inserts the checks automatically. The approach applies both spatial limits on memory locations and temporal limits on when access is allowed. If the enforcement holds, applications can incorporate third-party libraries without exposing stack secrets to data-exfiltration attacks. Tests on real programs show the added cost stays low.

Core claim

StackVault automatically enforces stack protection through spatial and temporal access monitoring and control over both sensitive stack data and untrusted functions.

What carries the argument

Kernel module that uses unforgeable function identities to carry out sensitive data protection.

If this is right

  • Marked sensitive stack data and any data reached through stack pointers stay inaccessible to untrusted functions.
  • Access control covers both the locations of the data and the timing of attempted reads or writes.
  • The LLVM extension places protection operations without requiring changes to application source code.
  • Runtime cost stays at or below 2.4 percent across the evaluated real-world programs.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Applications could safely load more third-party code without splitting into separate processes for isolation.
  • The same identity-tracking idea might extend to protecting data in other memory areas if the kernel module is updated.
  • Intra-process trust boundaries become enforceable at the function level rather than only at the process level.

Load-bearing premise

The kernel module can reliably identify and enforce controls using unforgeable function identities for all untrusted functions executing in the same process.

What would settle it

An untrusted function that successfully reads or writes a marked stack location despite the kernel module's identity checks would show the protection does not hold.

Figures

Figures reproduced from arXiv: 1907.03710 by Arun Iyengar, Ashish Kundu, Gong Su, Ling Liu, Qi Zhang, Zehra Sura.

Figure 1
Figure 1. Figure 1: Function-based data access attacks in sequential or a nested function call [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: StackVault system overview functions, they are specified using a supplementary file called SensitiveList. Alternatively, sensitive functions can be specified by an attribute directive inserted directly in the code at the point of the function definition, as follows: __attribute((annotate(“StackVault_Sensitive”))) void foo(int x, . . . ){. . . } By default, the entire stack frame of a sensitive function is … view at source ↗
Figure 3
Figure 3. Figure 3: Example code using StackVault protection masquerading as another. These function identities are reliable due to two reasons: first, the text sections in executable binaries are read-only and cannot be dynamically modified, and second, the value of PC registers cannot be modified by malicious user-level code. The kernel runtime maintains four data structures: a Function identity mapping table, a RegisterLis… view at source ↗
Figure 4
Figure 4. Figure 4: shows the example of [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 6
Figure 6. Figure 6: Normalized overhead breakdown - context switch v.s. StackVault [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Normalized overhead breakdown - per StackVault system call. [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: compares the compilation time of each application between the Native and the StackVault cases. The compilation overhead is significantly high (about 1.24 times longer) for the smaller applications (xmlstream, fileupload, and htmltidy), but it becomes much smaller for larger application sizes, taking about 0.47, 0.17, and 0.22 times longer for gRPC, minizip, and miniunz, respectively. The StackVault system … view at source ↗
read the original abstract

Data exfiltration attacks have led to huge data breaches. Recently, the Equifax attack affected 147M users and a third-party library - Apache Struts - was alleged to be responsible for it. These attacks often exploit the fact that sensitive data are stored unencrypted in process memory and can be accessed by any function executing within the same process, including untrusted third-party library functions. This paper presents StackVault, a kernel-based system to prevent sensitive stack-based data from being accessed in an unauthorized manner by intra-process functions. Stack-based data includes data on stack as well as data pointed to by pointer variables on stack. StackVault consists of three components: (1) a set of programming APIs to allow users to specify which data needs to be protected, (2) a kernel module which uses unforgeable function identities to reliably carry out the sensitive data protection, and (3) an LLVM compiler extension that enables transparent placement of stack protection operations. The StackVault system automatically enforces stack protection through spatial and temporal access monitoring and control over both sensitive stack data and untrusted functions. We implemented StackVault and evaluated it using a number of popular real-world applications, including gRPC. The results show that StackVault is effective and efficient, incurring only up to 2.4% runtime overhead.

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 paper presents StackVault, a kernel-based system to prevent sensitive stack-based data (including data pointed to by stack pointers) from unauthorized access by intra-process untrusted functions such as third-party libraries. It consists of user APIs for specifying protected data, a kernel module that uses unforgeable function identities for spatial/temporal monitoring and control, and an LLVM extension for transparent instrumentation. The abstract claims the system was implemented and evaluated on real-world applications including gRPC, showing it is effective with up to 2.4% runtime overhead.

Significance. If the enforcement mechanisms hold, the approach could address a practical gap in protecting against data exfiltration within a single process address space, complementing existing techniques for third-party library risks highlighted by incidents like Equifax. The combination of kernel-level identity enforcement with compiler support is a notable design point, though the evaluation details are needed to assess real impact.

major comments (2)
  1. [Abstract] Abstract: the claim of effectiveness and efficiency is based on evaluation of real-world apps (including gRPC) but provides no data, error bars, methodology, or specific results to support the central claims of protection and low overhead.
  2. [Kernel module component] Kernel module component (as described in abstract): the central claim requires reliable use of unforgeable function identities for spatial/temporal access control over untrusted functions in shared address space, but the description does not address how identities are bound to call sites, prevent pointer forgery by untrusted code, or handle third-party binaries/libraries arriving without LLVM instrumentation (e.g., Apache Struts example).
minor comments (2)
  1. [Abstract] The abstract states 'Stack-based data includes data on stack as well as data pointed to by pointer variables on stack' without clarifying how pointers to heap or other regions are tracked for temporal control.
  2. No mention of how the system interacts with existing stack protections (e.g., ASLR, stack canaries) or potential compatibility issues with multi-threaded applications.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. We address each major comment below.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the claim of effectiveness and efficiency is based on evaluation of real-world apps (including gRPC) but provides no data, error bars, methodology, or specific results to support the central claims of protection and low overhead.

    Authors: The abstract summarizes the evaluation results, citing implementation on real-world applications including gRPC and a maximum overhead of 2.4%. Full methodology, per-application results, and any variance measures appear in the evaluation section. We will revise the abstract to incorporate a concise summary of key quantitative results (e.g., overhead range across tested applications) while retaining its brevity. revision: partial

  2. Referee: [Kernel module component] Kernel module component (as described in abstract): the central claim requires reliable use of unforgeable function identities for spatial/temporal access control over untrusted functions in shared address space, but the description does not address how identities are bound to call sites, prevent pointer forgery by untrusted code, or handle third-party binaries/libraries arriving without LLVM instrumentation (e.g., Apache Struts example).

    Authors: Section 3 explains that function identities are kernel-managed and unforgeable, with the LLVM instrumentation inserting the necessary calls at function boundaries to bind identities to call sites; access decisions are made by the kernel using these identities rather than user-supplied pointers, which precludes forgery. The system requires recompilation of the application and its libraries with the LLVM pass; the Apache Struts reference in the introduction illustrates the general third-party risk motivating the work but is not presented as a target for StackVault (a C/C++-focused system). We will add explicit text clarifying the binding mechanism and forgery resistance in the revision. revision: yes

Circularity Check

0 steps flagged

No circularity; system description is self-contained

full rationale

The paper is a systems description of StackVault with three components (APIs, kernel module using unforgeable identities, LLVM extension) and empirical evaluation on applications like gRPC. No equations, fitted parameters, predictions, or derivation chains exist that could reduce to inputs by construction. Claims rest on implementation details and runtime measurements (up to 2.4% overhead), which are externally falsifiable and independent of any self-citation or self-definition. No load-bearing steps match the enumerated circularity patterns.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The central claim rests on standard assumptions about kernel capabilities for access control and compiler transparency; no free parameters or invented entities are introduced in the abstract.

axioms (2)
  • domain assumption The operating system kernel can enforce access controls using unforgeable function identities for intra-process functions.
    Invoked in the description of the kernel module component.
  • domain assumption The LLVM compiler extension can transparently insert stack protection operations without altering program semantics.
    Invoked in the description of the compiler extension component.

pith-pipeline@v0.9.0 · 5768 in / 1203 out tokens · 24932 ms · 2026-05-25T01:04:26.871841+00:00 · methodology

discussion (0)

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

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

52 extracted references · 52 canonical work pages

  1. [1]

    https://eur-lex .europa.eu/ legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN

    European general data privacy regulation. https://eur-lex .europa.eu/ legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN. Accessed: 2017-07-05

    work page 2017

  2. [2]

    https://www .hhs.gov/hipaa/ for-professionals/

    European general data privacy regulation. https://www .hhs.gov/hipaa/ for-professionals/. Accessed: 2017-07-05

    work page 2017

  3. [3]

    https://gcc .gnu.org/

    GCC, the gnu compiler collection. https://gcc .gnu.org/. Accessed: 2016-10-30

    work page 2016

  4. [4]

    https://software .intel.com/en-us/inspector- user-guide-linux-cross-thread-stack-access, accessed Aug

    Cross-thread stack access. https://software .intel.com/en-us/inspector- user-guide-linux-cross-thread-stack-access, accessed Aug. 5, 2018

    work page 2018

  5. [5]

    https: //curl.haxx.se/libcurl/c/fileupload.html, accessed August 2, 2018

    Fileupload - upload to a file to a specific url using libcurl. https: //curl.haxx.se/libcurl/c/fileupload.html, accessed August 2, 2018. 11

    work page 2018

  6. [6]

    https: //grpc.io/, accessed August 2, 2018

    gRPC - a high performance, open-source universal rpc framework. https: //grpc.io/, accessed August 2, 2018

    work page 2018

  7. [7]

    https: //curl.haxx.se/libcurl/c/htmltidy.html, accessed August 2, 2018

    Htmltidy - download a document and use libtidy to parse the html. https: //curl.haxx.se/libcurl/c/htmltidy.html, accessed August 2, 2018

    work page 2018

  8. [8]

    https://github .com/madler/ zlib/blob/master/contrib/minizip/miniunz.c, accessed August 2, 2018

    Miniunz - an open source file extraction tool. https://github .com/madler/ zlib/blob/master/contrib/minizip/miniunz.c, accessed August 2, 2018

    work page 2018

  9. [9]

    https://github .com/ madler/zlib/blob/master/contrib/minizip/minizip.c, accessed August 2, 2018

    Minizip - an open source file compression tool. https://github .com/ madler/zlib/blob/master/contrib/minizip/minizip.c, accessed August 2, 2018

    work page 2018

  10. [10]

    https://curl.haxx.se/libcurl/c/xmlstream.html, accessed August 2, 2018

    Xmlstream - stream-parse a document using the streaming expat parser. https://curl.haxx.se/libcurl/c/xmlstream.html, accessed August 2, 2018

    work page 2018

  11. [11]

    https://www.businessinsider.com/tesla-employee-engaged-in- sabotage-against-the-company-report-2018-6, accessed August 5, 2018

    Elon musk is accusing a tesla employee of trying to sabotage the company. https://www.businessinsider.com/tesla-employee-engaged-in- sabotage-against-the-company-report-2018-6, accessed August 5, 2018

    work page 2018

  12. [12]

    https://www.extremetech.com/computing/120981-github-hacked- millions-of-projects-at-risk-of-being-modified-or-deleted, accessed August 5, 2018

    Github hacked, millions of projects at risk of being modified or deleted. https://www.extremetech.com/computing/120981-github-hacked- millions-of-projects-at-risk-of-being-modified-or-deleted, accessed August 5, 2018

    work page 2018

  13. [13]

    https://www .zdnet.com/article/equifax-blames-open- source-software-for-its-record-breaking-security-breach, accessed July 5, 2018

    Equifax blames open-source software for its record-breaking security breach: Report. https://www .zdnet.com/article/equifax-blames-open- source-software-for-its-record-breaking-security-breach, accessed July 5, 2018

    work page 2018

  14. [14]

    https://www.geek.com/news/major-open-source-code-repository- hacked-for-months-says-fsf-551344, accessed July 5, 2018

    Major open source code repository hacked for months. https://www.geek.com/news/major-open-source-code-repository- hacked-for-months-says-fsf-551344, accessed July 5, 2018

    work page 2018

  15. [15]

    Control-flow integrity

    Martín Abadi, Mihai Budiu, Ulfar Erlingsson, and Jay Ligatti. Control-flow integrity. In Proceedings of the 12th ACM conference on Computer and communications security, pages 340–353. ACM, 2005

    work page 2005

  16. [16]

    Control-flow integrity principles, implementations, and applications

    Martín Abadi, Mihai Budiu, Úlfar Erlingsson, and Jay Ligatti. Control-flow integrity principles, implementations, and applications. ACM Transactions on Information and System Security (TISSEC) , 13(1):4, 2009

    work page 2009

  17. [17]

    Address obfuscation: An efficient approach to combat a broad range of memory error exploits

    Sandeep Bhatkar, Daniel C DuVarney, and Ron Sekar. Address obfuscation: An efficient approach to combat a broad range of memory error exploits. In USENIX Security Symposium , volume 12, pages 291–301, 2003

    work page 2003

  18. [18]

    Computer security: art and science

    Matt Bishop. Computer security: art and science . Addison-Wesley Professional, 2003

    work page 2003

  19. [19]

    Secureblue++: Cpu support for secure execution

    Rick Boivie and Peter Williams. Secureblue++: Cpu support for secure execution. IBM, IBM Research Division, RC25287 (WAT1205-070) , pages 1–9, 2012

    work page 2012

  20. [20]

    Linux kernel vulnerabilities: State-of-the-art defenses and open problems

    Haogang Chen, Yandong Mao, Xi Wang, Dong Zhou, Nickolai Zeldovich, and M Frans Kaashoek. Linux kernel vulnerabilities: State-of-the-art defenses and open problems. In Proceedings of the Second Asia-Pacific Workshop on Systems, page 5. ACM, 2011

    work page 2011

  21. [21]

    Stackarmor: Comprehensive protection from stack-based memory error vulnerabilities for binaries

    Xi Chen, Asia Slowinska, Dennis Andriesse, Herbert Bos, and Cristiano Giuffrida. Stackarmor: Comprehensive protection from stack-based memory error vulnerabilities for binaries. In NDSS, 2015

    work page 2015

  22. [22]

    Shreds: Fine-grained execution units with private memory

    Yaohui Chen, Sebassujeen Reymondjohnson, Zhichuang Sun, and Long Lu. Shreds: Fine-grained execution units with private memory. In Security and Privacy (SP), 2016 IEEE Symposium on , pages 56–71. IEEE, 2016

    work page 2016

  23. [23]

    Shredding your garbage: Reducing data lifetime through secure deallocation

    Jim Chow, Ben Pfaff, Tal Garfinkel, and Mendel Rosenblum. Shredding your garbage: Reducing data lifetime through secure deallocation. In USENIX Security, pages 22–22, 2005

    work page 2005

  24. [24]

    Intel sgx explained

    Victor Costan and Srinivas Devadas. Intel sgx explained. IACR Cryptology ePrint Archive, 2016:86, 2016

    work page 2016

  25. [25]

    Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks

    Crispan Cowan, Calton Pu, Dave Maier, Jonathan Walpole, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, Qian Zhang, and Heather Hinton. Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks. In Usenix Security , volume 98, pages 63–78, 1998

    work page 1998

  26. [26]

    Complete control-flow integrity for commodity operating system kernels

    J Criswell, N Dautenhahn, and V A Kcofi. Complete control-flow integrity for commodity operating system kernels. In 2014 IEEE Symposium on Security and Privacy (SP), pages 292–307

    work page 2014

  27. [27]

    The performance cost of shadow stacks and stack canaries

    Thurston HY Dang, Petros Maniatis, and David Wagner. The performance cost of shadow stacks and stack canaries. In Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security, pages 555–566. ACM, 2015

    work page 2015

  28. [28]

    Vanish: Increasing data privacy with self-destructing data

    Roxana Geambasu, Tadayoshi Kohno, Amit A Levy, and Henry M Levy. Vanish: Increasing data privacy with self-destructing data. In USENIX Security Symposium, pages 299–316, 2009

    work page 2009

  29. [29]

    Swipe: eager erasure of sensitive data in large scale systems software

    Kalpana Gondi, Prithvi Bisht, Praveen Venkatachari, A Prasad Sistla, and VN Venkatakrishnan. Swipe: eager erasure of sensitive data in large scale systems software. In Proceedings of the second ACM conference on Data and Application Security and Privacy, pages 295–306. ACM, 2012

    work page 2012

  30. [30]

    Minimizing lifetime of sensitive data in concurrent programs

    Kalpana Gondi, A Prasad Sistla, and VN Venkatakrishnan. Minimizing lifetime of sensitive data in concurrent programs. In Proceedings of the 4th ACM conference on Data and application security and privacy, pages 171–174. ACM, 2014

    work page 2014

  31. [31]

    Lest we remember: cold-boot attacks on encryption keys

    J Alex Halderman, Seth D Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A Calandrino, Ariel J Feldman, Jacob Appelbaum, and Edward W Felten. Lest we remember: cold-boot attacks on encryption keys. Communications of the ACM, 52(5):91–98, 2009

    work page 2009

  32. [32]

    Safedispatch: Securing c++ virtual calls from memory corruption attacks

    Dongseok Jang, Zachary Tatlock, and Sorin Lerner. Safedispatch: Securing c++ virtual calls from memory corruption attacks. In NDSS, 2014

    work page 2014

  33. [33]

    Countering code-injection attacks with instruction-set randomization

    Gaurav S Kc, Angelos D Keromytis, and Vassilis Prevelakis. Countering code-injection attacks with instruction-set randomization. In Proceedings of the 10th ACM conference on Computer and communications security , pages 272–280. ACM, 2003

    work page 2003

  34. [34]

    Comprehensively and efficiently protecting the heap

    Mazen Kharbutli, Xiaowei Jiang, Yan Solihin, Guru Venkataramani, and Milos Prvulovic. Comprehensively and efficiently protecting the heap. ACM Sigplan Notices, 41(11):207–218, 2006

    work page 2006

  35. [35]

    Kundu and E

    A. Kundu and E. Bertino. A new class of buffer overflow attacks. In 2011 31st International Conference on Distributed Computing Systems , pages 730–739, June 2011

    work page 2011

  36. [36]

    Unisan: Proactive kernel memory initialization to eliminate data leakages

    Kangjie Lu, Chengyu Song, Taesoo Kim, and Wenke Lee. Unisan: Proactive kernel memory initialization to eliminate data leakages. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 920–932. ACM, 2016

    work page 2016

  37. [37]

    Apache struts 2: how technical and development gaps caused the equifax breach

    Jeff Luszcz. Apache struts 2: how technical and development gaps caused the equifax breach. Network Security, 2018(1):5–8, 2018

    work page 2018

  38. [38]

    Cve-2014-0160: The heartbleed vulnerability

    Alyssa Milburn, Herbert Bos, and Cristiano Giuffrida. Cve-2014-0160: The heartbleed vulnerability. 2014

    work page 2014

  39. [39]

    SafeInit: Comprehensive and practical mitigation of uninitialized read vulnerabilities

    Alyssa Milburn, Herbert Bos, and Cristiano Giuffrida. SafeInit: Comprehensive and practical mitigation of uninitialized read vulnerabilities. 2017

    work page 2017

  40. [40]

    Heapsentry: kernel-assisted protection against heap overflows

    Nick Nikiforakis, Frank Piessens, and Wouter Joosen. Heapsentry: kernel-assisted protection against heap overflows. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, pages 177–196. Springer, 2013

    work page 2013

  41. [41]

    Dieharder: securing the heap

    Gene Novark and Emery D Berger. Dieharder: securing the heap. In Proceedings of the 17th ACM conference on Computer and communications security, pages 573–584. ACM, 2010

    work page 2010

  42. [42]

    Samurai: protecting critical data in unsafe languages

    Karthik Pattabiraman, Vinod Grover, and Benjamin G Zorn. Samurai: protecting critical data in unsafe languages. In ACM SIGOPS Operating Systems Review, volume 42, pages 219–232. ACM, 2008

    work page 2008

  43. [43]

    Know your open source code

    Mike Pittenger. Know your open source code. Network Security , 2016(5):11–15, 2016

    work page 2016

  44. [44]

    A practical dynamic buffer overflow detector

    Olatunji Ruwase and Monica S Lam. A practical dynamic buffer overflow detector. In NDSS, volume 4, pages 159–169, 2004

    work page 2004

  45. [45]

    On the effectiveness of address-space randomization

    Hovav Shacham, Matthew Page, Ben Pfaff, Eu-Jin Goh, Nagendra Modadugu, and Dan Boneh. On the effectiveness of address-space randomization. In Proceedings of the 11th ACM conference on Computer and communications security, pages 298–307. ACM, 2004

    work page 2004

  46. [46]

    Freeguard: A faster secure heap allocator

    Sam Silvestro, Hongyu Liu, Corey Crosser, Zhiqiang Lin, and Tongping Liu. Freeguard: A faster secure heap allocator. In CCS, 2017

    work page 2017

  47. [47]

    Transparent runtime shadow stack: Protection against malicious return address modifications, 2008

    Saravanan Sinnadurai, Qin Zhao, and Weng fai Wong. Transparent runtime shadow stack: Protection against malicious return address modifications, 2008

    work page 2008

  48. [48]

    Breaking the memory secrecy assumption

    Raoul Strackx, Yves Younan, Pieter Philippaerts, Frank Piessens, Sven Lachmund, and Thomas Walter. Breaking the memory secrecy assumption. In Proceedings of the Second European Workshop on System Security, EUROSEC ’09, pages 1–8, New York, NY , USA, 2009. ACM

    work page 2009

  49. [49]

    Between mutual trust and mutual distrust: practical fine-grained privilege separation in multithreaded applications

    Jun Wang, Xi Xiong, and Peng Liu. Between mutual trust and mutual distrust: practical fine-grained privilege separation in multithreaded applications. In 2015 USENIX Annual Technical Conference (USENIX ATC 15), pages 361–373, 2015

    work page 2015

  50. [50]

    David A. Wheeler. How to prevent the next heartbleed

    work page

  51. [51]

    The openacc data model: Preliminary study on its major challenges and implementations

    Michael Wolfe, Seyong Lee, Jungwon Kim, Xiaonan Tian, Rengan Xu, Barbara Chapman, and Sunita Chandrasekaran. The openacc data model: Preliminary study on its major challenges and implementations. Parallel Computing, 78:15 – 27, 2018

    work page 2018

  52. [52]

    Practical control flow integrity and randomization for binary executables

    Chao Zhang, Tao Wei, Zhaofeng Chen, Lei Duan, Laszlo Szekeres, Stephen McCamant, Dawn Song, and Wei Zou. Practical control flow integrity and randomization for binary executables. In Security and Privacy (SP), 2013 IEEE Symposium on , pages 559–573. IEEE, 2013

    work page 2013