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 | emulator-bug-study-f2ec263023649e596c5076df32c2d328bc9393d2.tar.gz emulator-bug-study-f2ec263023649e596c5076df32c2d328bc9393d2.zip | |
add downloaded fex bug-reports
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 00000000..bfd8c6c2 --- /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 |