Re: [Qemu-devel] [PATCH] security.rst: add Security Guide to developer docs

[Li Qiang]

Stefan Hajnoczi <address@hidden> 于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
>