linux-kernel - Re: [PATCH RFC 0/3] io_uring: add restrictions to support untrusted applications and guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200713092435.GC28639@stefanha-x1.localdomain>
Date:   Mon, 13 Jul 2020 10:24:35 +0100
From:   Stefan Hajnoczi <stefanha@...hat.com>
To:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:     Jens Axboe <axboe@...nel.dk>, Sargun Dhillon <sargun@...gun.me>,
        Kees Cook <keescook@...omium.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        Jann Horn <jannh@...gle.com>, Aleksa Sarai <asarai@...e.de>,
        Christian Brauner <christian.brauner@...ntu.com>,
        io-uring@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>,
        Jeff Moyer <jmoyer@...hat.com>,
        Stefano Garzarella <sgarzare@...hat.com>
Subject: Re: [PATCH RFC 0/3] io_uring: add restrictions to support untrusted
 applications and guests

On Fri, Jul 10, 2020 at 06:20:17PM +0200, Stefano Garzarella wrote:
> On Fri, Jul 10, 2020 at 11:33:09AM -0400, Konrad Rzeszutek Wilk wrote:
> > .snip..
> > > Just to recap the proposal, the idea is to add some restrictions to the
> > > operations (sqe, register, fixed file) to safely allow untrusted applications
> > > or guests to use io_uring queues.
> > 
> > Hi!
> > 
> > This is neat and quite cool - but one thing that keeps nagging me is
> > what how much overhead does this cut from the existing setup when you use
> > virtio (with guests obviously)?
> 
> I need to do more tests, but the preliminary results that I reported on
> the original proposal [1] show an overhead of ~ 4.17 uS (with iodepth=1)
> when I'm using virtio ring processed in a dedicated iothread:
> 
>   - 73 kIOPS using virtio-blk + QEMU iothread + io_uring backend
>   - 104 kIOPS using io_uring passthrough
> 
> >                                 That is from a high level view the
> > beaty of io_uring being passed in the guest is you don't have the
> > virtio ring -> io_uring processing, right?
> 
> Right, and potentially we can share the io_uring queues directly to the
> guest userspace applications, cutting down the cost of Linux block
> layer in the guest.

Another factor is that the guest submits requests directly to the host
kernel sqpoll thread. When a virtqueue is used the sqpoll thread cannot
poll it directly so another host thread (QEMU) needs to poll the
virtqueue. The same applies for the completion code path.

Stefan

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)