Stefan Hajnoczi <stefa...@redhat.com> 于2019年4月23日周二 下午4:49写道:
> On Thu, Apr 18, 2019 at 06:47:18PM +0200, Philippe Mathieu-Daudé wrote: > > On 4/18/19 6:13 PM, Stefan Hajnoczi wrote: > > > +Virtualization Use Case > > > +~~~~~~~~~~~~~~~~~~~~~~~ > > > +The virtualization use case covers cloud and virtual private server > (VPS) > > > +hosting, as well as traditional data center and desktop > virtualization. These > > > +use cases rely on hardware virtualization extensions to execute guest > code > > > +safely on the physical CPU at close-to-native speed. > > > + > > > +The following entities are **untrusted**, meaning that they may be > buggy or > > > +malicious: > > > + > > > +* Guest > > > +* User-facing interfaces (e.g. VNC, SPICE, WebSocket) > > > +* Network protocols (e.g. NBD, live migration) > > > +* User-supplied files (e.g. disk images, kernels, device trees) > > > > What about pass-thru USB/PCI devices? > > Can you give a real-world example? > > Maybe Philippe means qemu maybe interact with the malicious USB/PCI devices. Just like usb-fuzzer recently added to syzkaller. I'm not sure how much qemu communicate with the real device in pass-thru(VFIO?). If there are too much, it may be take consideration. Thanks, Li Qiang > > > +Guest Isolation > > > +~~~~~~~~~~~~~~~ > > > +Guest isolation is the confinement of guest code to the virtual > machine. When > > > +guest code gains control of execution on the host this is called > escaping the > > > +virtual machine. Isolation also includes resource limits such as > CPU, memory, > > > +disk, or network throttling. Guests must be unable to exceed their > resource > > > > I'm unsure but I'd have written "... such as throttling of CPU, memory, > > disk or network". > > Will change in v2. > > > > +Unexpected Device Accesses > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > +The guest may access device registers in unusual orders or at > unexpected > > > +moments. Device emulation code must not assume that the guest > follows the > > > +typical "theory of operation" presented in driver writer manuals. > The guest > > > +may make nonsense accesses to device registers such as starting > operations > > > +before the device has been fully initialized. > > > + > > > +A related issue is that device emulation code must be prepared for > unexpected > > > +device register accesses while asynchronous operations are in > progress. A > > > +well-behaved guest might wait for a completion interrupt before > accessing > > > +certain device registers. Device emulation code must handle the case > where the > > > +guest overwrites registers or submits further requests before an > ongoing > > > +request completes. Unexpected accesses must not cause memory > corruption or > > > +leaks in QEMU. > > > > Might worth to tell such unexpected accesses might be logged with > > 'qemu_log_mask(LOG_GUEST_ERROR, ...) and audited with -d guest_errors? > > Will add in v2. > > Stefan >