lkml.org 
[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

* Avi Kivity <avi@redhat.com> wrote:

> > It would be possible to further increase isolation there by also
> > passing the IO/MMIO decoding to the worker thread - but i'm not
> > sure that's truly needed. Most of the risk is where most of the
> > code is - and the code is in the worker task which interprets
> > on-disk data, protocols, etc.
>
> I've suggested in the past to add an "mmiofd" facility to kvm,
> similar to ioeventfd. This is how it would work:
>
> - userspace configures kvm with an mmio range and a pipe
> - guest writes to that range write a packet to the pipe describing the write
> - guest reads from that range write a packet to the pipe describing
> the read, then wait for a reply packet with the result
>
> The advantages would be
> - avoid heavyweight exit; kvm can simply wake up a thread on another
> core and resume processing
> - writes can be pipelined, similar to how PCI writes are posted
> - supports process separation

Yes, that was my exact thought, a per transport channel fd.

> So far no one has posted an implementation but it should be pretty
> simple.

tools/kvm/ could make quick use of it - and it's a performance
optimization mainly IMO, not primarily a security feature.

If you whip up a quick untested prototype for the KVM side we could
look into adding tooling support for it and could test it.

As long as it's provided as an opt-in ioctl() which if fails (on
older kernels) we fall back to the vcpu-fd, it should be relatively
straightforward to support on the tooling side as well AFAICS.

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-05-26 13:19    [W:0.075 / U:4.124 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site