Jonas Vinck

dblp:304/2422 · DBLP profile ↗
← Back
4ranked-venue papers
2as first author
4since 2021 · last 2025
0000-0003-4428-9881ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 2 · 1 first-author · 2 since 2021Security and privacy · 2 · 1 first-author · 2 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Network and information security
3 papers
Systems and software security · 96% Hardware security and side channels · 4%
Computer architecture, parallel and distributed computing, and storage systems
1 paper
GPUs and heterogeneous computing · 100%
Software engineering, system software, and programming languages
1 paper
Operating systems · 100%

Topics — the 8 heaviest of 9, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Systems and software security › vulnerability discovery › fuzzing
driver fuzzing
0.912025
Moneta: Ex-Vivo GPU Driver Fuzzing by Recalling In-Vivo Execution States · NDSS 2025
Systems and software security
vulnerability discovery
0.912025
Moneta: Ex-Vivo GPU Driver Fuzzing by Recalling In-Vivo Execution States · NDSS 2025
Systems and software security › memory safety › memory isolation
in-process isolation
0.612022
You shall not (by)pass!: practical, secure, and fast PKU-based sandboxing · EuroSys 2022
Systems and software security › memory safety
memory corruption defense
0.612022
Sharing is caring: secure and efficient shared memory support for MVEEs · EuroSys 2022
Systems and software security
memory safety
0.612022
You shall not (by)pass!: practical, secure, and fast PKU-based sandboxing · EuroSys 2022
Systems and software security › software diversity
multi-variant execution
0.612022
Sharing is caring: secure and efficient shared memory support for MVEEs · EuroSys 2022
Hardware security and side channels › trusted execution environments
hardware isolation
0.212022
You shall not (by)pass!: practical, secure, and fast PKU-based sandboxing · EuroSys 2022
Operating systems › resource management
memory management
0.212022
Sharing is caring: secure and efficient shared memory support for MVEEs · EuroSys 2022

Methods — techniques the papers use, named apart from their topics

fuzzing · 1.7execution state recall · 1.7software diversity · 1.1lockstep execution · 1.1memory protection keys · 0.6control-flow integrity · 0.6
YearPublicationVenuePosition
2025 Divide and Conquer: Introducing Partial Multi-Variant Execution
abstract
After several decades of defensive research against the exploitation of memory errors, a wide range of techniques has been proposed, yet no silver bullet has been found. Multi-Variant eXecution (MVX) is one promising proposal for defending against a wide range of known and potentially unknown attacks. MVX systems run multiple program variants in parallel on the same inputs while monitoring their behavior and deduplicating their outputs. By constructing these program variants using automated software diversity techniques, we can ensure that the variants behave identically under normal operating conditions but diverge when attacked. The MVX system detects these divergences and reacts appropriately.State-of-the-art MVX systems have several fundamental problems that inhibit their real-world adoption. First, they often require full source code availability to construct variants and eliminate non-deterministic program behavior. Second, they incur significant resource overhead that linearly increases with the number of variants running in parallel.We propose Partial Multi-Variant eXecution (PMVX), a technique that can mitigate these problems by limiting the scope of MVX to certain well-delineated parts of a target application and by running the rest of the application in Single-Variant eXecution (SVX) mode. PMVX relaxes the source code availability requirement of traditional MVX systems and yields substantially reduced resource consumption while maintaining the strong security guarantees of these systems. However, PMVX implementations must address the non-trivial problem of ensuring all variants are in equivalent states whenever they switch from SVX to MVX mode.We designed and implemented a proof-of-concept PMVX system called FORTDIVIDE that solves this state-equivalency problem using state migration and resynchronization. We thoroughly evaluated the security and performance of our system as a whole, and of our state migration and synchro-nization mechanisms in isolation. We conclude that PMVX has great potential but needs to be applied with the utmost care since the added overhead of state resynchronization can quickly outweigh the benefits of running in SVX mode.
Jonas Vinck, Adriaan Jacobs, Alexios Voulimeneas, Stijn Volckaert
EuroS&P1
2025 Moneta: Ex-Vivo GPU Driver Fuzzing by Recalling In-Vivo Execution States
Joonkyo Jung, Jisoo Jang, Yongwan Jo, Jonas Vinck, Alexios Voulimeneas, Stijn Volckaert, Dokyung Song
NDSS4
2022 Sharing is caring: secure and efficient shared memory support for MVEEs
abstract
Multi-Variant Execution Environments (MVEEs) are a powerful tool for protecting legacy software against memory corruption attacks. MVEEs employ software diversity to run multiple variants of the same program in lockstep, whilst providing them with the same inputs and comparing their behavior. Well-constructed variants will behave equivalently under normal operating conditions but diverge when under attack. The MVEE detects these divergences and takes action before compromised variants can damage the host system.
Jonas Vinck, Bert Abrath, Bart Coppens 0001, Alexios Voulimeneas, Bjorn De Sutter, Stijn Volckaert
EuroSys1
2022 You shall not (by)pass!: practical, secure, and fast PKU-based sandboxing
abstract
Memory Protection Keys for Userspace (PKU) is a recent hardware feature that allows programs to assign virtual memory pages to protection domains, and to change domain access permissions using inexpensive, unprivileged instructions. Several in-process memory isolation approaches leverage this feature to prevent untrusted code from accessing sensitive program state and data. Typically, PKU-based isolation schemes need to be used in conjunction with mitigations such as CFI because untrusted code, when compromised, can otherwise bypass the PKU access permissions using unprivileged instructions or operating system APIs.
Alexios Voulimeneas, Jonas Vinck, Ruben Mechelinck, Stijn Volckaert
EuroSys2