[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] memory separation for qemu-fast

From: Piotr Krysik
Subject: [Qemu-devel] memory separation for qemu-fast
Date: Sat, 7 Aug 2004 16:09:07 -0700 (PDT)


It's possible to improve qemu-fast security by 
providing separation between host and target address 
space when running on x86 host. The idea is to use 
segment limit to protect non-guest memory from access 
by guest code.

If my understanding is correct, qemu-fast avoids 
expensive emulation of MMU address translation on 
every memory access by modifying qemu-fast process 
address space to correspond to virtual address 
space of emulated CPU. The problem with this approach 
is that usually it's not possible to reserve 
continuous range of addresses in qemu-fast process 
as large as emulated CPU virtual address space 
(this problem would not exit if we would like to 
emulate 32-bit CPU on 64-bit host CPU).

Current implementation of qemu-fast reserves range 
[MMAP_AREA_START = 0, MMAP_AREA_END = 0xa8000000) 
to represent virtual address space of emulated CPU. 
If translated guest code is trying to access virtual 
address outside of this range and the corresponding 
page is not mapped or is protected, the invalid 
access is detected via SIGSEGV and guest code 
is recompiled to use emulation of MMU address 
translation (softmmu). But some of the pages contain 
qemu-fast code, data and stack, so access to these 
pages from translated guest code is not detected. 
It means that guest code could e.g. modify qemu-fast 
data or stack by writing to these pages.

On x86 host it's possible to protect addresses 
outside of the reserved range by providing segment 
with base = MMAP_AREA_START and limit = MMAP_AREA_END 
- MMAP_AREA_START and using this segment for memory 
access in compiled guest code.

The segment could be created by modify_ldt system 
call on Linux. Probably it could be possible to 
allocate dedicate segment register just for this. 
If for some reason it's impossible, then maybe 
a specific segment register could be loaded before 
calling translation block and reset on exit.

Does anyone see any problems with this approach? 
Are there any issues with portability (modify_ldt 
on older kernels, other OSes)?



Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]