diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-17 09:10:43 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-17 09:10:43 +0200 |
| commit | f2ec263023649e596c5076df32c2d328bc9393d2 (patch) | |
| tree | 5dd86caab46e552bd2e62bf9c4fb1a7504a44db4 /results/scraper/fex/documentation/1908 | |
| parent | 63d2e9d409831aa8582787234cae4741847504b7 (diff) | |
| download | qemu-analysis-main.tar.gz qemu-analysis-main.zip | |
Diffstat (limited to 'results/scraper/fex/documentation/1908')
| -rw-r--r-- | results/scraper/fex/documentation/1908 | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/results/scraper/fex/documentation/1908 b/results/scraper/fex/documentation/1908 new file mode 100644 index 000000000..bfd8c6c2e --- /dev/null +++ b/results/scraper/fex/documentation/1908 @@ -0,0 +1,34 @@ +Security Model and Implications +#### Overview +FEX may have a weaker security model vs typical posix. + +Namely, IR or OBJ cache assume that every FEX process is a trusted peer. + +As FEX shares address spaces and security tokens with the emulated application, there's no way to guarantee that a malicious application can't modify the behaviour of any other FEX process, as long as they share caches. + +This is even more important around setuid binaries that operate in a separate security context. As is execution of setuid executable through FEX could lead to privileged data leakage and privilege escalation. + +I have a mental note to tackle these issues as part of [2212](https://github.com/FEX-Emu/FEX/milestone/3), I will budget some time to create tickets and further document the situation latest during [2210](https://github.com/FEX-Emu/FEX/milestone/1). + +Also note that the FEX VM and IR don't offer any correctness or security guarantees right now. + +#### Brain Dump + +Sadly, linux has very limited support for in place context switching (only vfork), so zero/low cost security contexts are not an option. Maybe vfork is enough. + +Sadly, linux has only one granularity of page protection, no ASIDs, and in general the memory management api and infrastructure is extremely poor. + +Sadly, linux also has almost no apis for information management / data and metadata leakage mitigation (only madvise and very few options there iirc). + +#### What can we do + +##### For privilege and data protection +- Make cache management happen under a different uid, and ask a fexserver to compile. Complications: Linux induced overhead. +- Try to escalate a task during compilation via vfork: Complications vfork overhead,, questions of forked process privileges. +- Try to restrict the guest from accessing the FEX structures (48th address bit in aarch64 running x86_64, 32th+ bits in any running x86_32, segment registers in x86) +- Use caches in readonly mode + AOT +- ? + +#### For metadata protection +- AOT +- ? \ No newline at end of file |