Demo Data from EDBT 2026 / reviewers in the wild / expert
Alexandra E. Michael
dblp:327/9545
· DBLP profile ↗
2ranked-venue papers
1as first author
2since 2021 · last 2024
0000-0002-0305-5424ORCID · corroborated
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2 · 1 first-author · 2 since 2021Systems, architecture and hardware · 1 · 1 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
2 papers |
Hardware security and side channels · 54% Systems and software security · 46% | |
| Software engineering, system software, and programming languages
2 papers |
Compilers and program optimization · 82% Programming languages and type systems · 18% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Processor architecture and microarchitecture · 100% |
Topics — the 5 heaviest of 6, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Hardware security and side channels › microarchitectural side channel
microarchitectural timing channels |
0.8 | 1 | 2024 | Avoiding Instruction-Centric Microarchitectural Timing Channels Via Binary-Code Transformations · ASPLOS (2) 2024 |
Processor architecture and microarchitecture
microarchitecture optimization |
0.8 | 1 | 2024 | Avoiding Instruction-Centric Microarchitectural Timing Channels Via Binary-Code Transformations · ASPLOS (2) 2024 |
Systems and software security
memory safety |
0.7 | 1 | 2023 | MSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code · Proc. ACM Program. Lang. 2023 |
Compilers and program optimization
compiler correctness |
0.7 | 1 | 2023 | MSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code · Proc. ACM Program. Lang. 2023 |
Programming languages and type systems › language semantics
formal semantics |
0.2 | 1 | 2023 | MSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code · Proc. ACM Program. Lang. 2023 |
Methods — techniques the papers use, named apart from their topics
binary-code transformation · 2.3type system · 1.3hardware memory capabilities · 1.3formal semantics · 1.3
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2024 | Avoiding Instruction-Centric Microarchitectural Timing Channels Via Binary-Code TransformationsabstractWith the end of Moore's Law-based scaling, novel microarchitectural optimizations are being patented, researched, and implemented at an increasing rate. Previous research has examined recently published patents and papers and demonstrated ways these upcoming optimizations present new security risks via novel side channels. As these side channels are introduced by microarchitectural optimization, they are not generically solvable in source code. Michael Flanders, Reshabh K. Sharma, Alexandra E. Michael, Dan Grossman, David Kohlbrenner |
ASPLOS (2) | 3 |
| 2023 | MSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe CodeabstractMost programs compiled to WebAssembly (Wasm) today are written in unsafe languages like C and C++. Unfortunately, memory-unsafe C code remains unsafe when compiled to Wasm—and attackers can exploit buffer overflows and use-after-frees in Wasm almost as easily as they can on native platforms. Memory- Safe WebAssembly (MSWasm) proposes to extend Wasm with language-level memory-safety abstractions to precisely address this problem. In this paper, we build on the original MSWasm position paper to realize this vision. We give a precise and formal semantics of MSWasm, and prove that well-typed MSWasm programs are, by construction, robustly memory safe. To this end, we develop a novel, language-independent memory-safety property based on colored memory locations and pointers. This property also lets us reason about the security guarantees of a formal C-to-MSWasm compiler—and prove that it always produces memory-safe programs (and preserves the semantics of safe programs). We use these formal results to then guide several implementations: Two compilers of MSWasm to native code, and a C-to-MSWasm compiler (that extends Clang). Our MSWasm compilers support different enforcement mechanisms, allowing developers to make security-performance trade-offs according to their needs. Our evaluation shows that on the PolyBenchC suite, the overhead of enforcing memory safety in software ranges from 22% (enforcing spatial safety alone) to 198% (enforcing full memory safety), and 51.7% when using hardware memory capabilities for spatial safety and pointer integrity. More importantly, MSWasm’s design makes it easy to swap between enforcement mechanisms; as fast (especially hardware-based) enforcement techniques become available, MSWasm will be able to take advantage of these advances almost for free. Alexandra E. Michael, Anitha Gollamudi, Jay Bosamiya, Evan Johnson 0001, Aidan Denlinger, Craig Disselkoen, Conrad Watt, Bryan Parno, Marco Patrignani, Marco Vassena, Deian Stefan |
Proc. ACM Program. Lang. | 1 |