lkml.org 
[lkml]   [2020]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs
On Tue, Jun 16, 2020 at 12:09:16PM -0400, Peter Xu wrote:
> On Tue, Jun 16, 2020 at 04:49:28PM +0100, Stefan Hajnoczi wrote:
> > Isolation between applications is preserved but there is no isolation
> > between the device and the application itself. The application needs to
> > trust the device.
> >
> > Examples:
> >
> > 1. The device can snoop secret data from readable pages in the
> > application's virtual memory space.
> >
> > 2. The device can gain arbitrary execution on the CPU by overwriting
> > control flow addresses (e.g. function pointers, stack return
> > addresses) in writable pages.
>
> To me, SVA seems to be that "middle layer" of secure where it's not as safe as
> VFIO_IOMMU_MAP_DMA which has buffer level granularity of control (but of course
> we pay overhead on buffer setups and on-the-fly translations), however it's far
> better than DMA with no IOMMU which can ruin the whole host/guest, because
> after all we do a lot of isolations as process based.
>
> IMHO it's the same as when we see a VM (or the QEMU process) as a whole along
> with the guest code. In some cases we don't care if the guest did some bad
> things to mess up with its own QEMU process. It is still ideal if we can even
> stop the guest from doing so, but when it's not easy to do it the ideal way, we
> just lower the requirement to not spread the influence to the host and other
> VMs.

Makes sense.

Stefan
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2020-06-22 14:49    [W:0.058 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site