From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4ABD2C433E4 for ; Thu, 23 Jul 2020 13:38:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 28F16207BB for ; Thu, 23 Jul 2020 13:38:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="rtHW9H+X" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729174AbgGWNiE (ORCPT ); Thu, 23 Jul 2020 09:38:04 -0400 Received: from wnew3-smtp.messagingengine.com ([64.147.123.17]:35671 "EHLO wnew3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728134AbgGWNiE (ORCPT ); Thu, 23 Jul 2020 09:38:04 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.west.internal (Postfix) with ESMTP id 961D2B7C; Thu, 23 Jul 2020 09:38:02 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 23 Jul 2020 09:38:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9mco5f JJTIwbB3aNFFiVQMevd5UiiUsgphoo0oYGF24=; b=rtHW9H+X9+1zQ3LSnXSHNT pblNyZl2noCXQzVcDENcy/SjYvwXx4UsTxmC3aBUHxX2jbcbyDTwe2FOqaloPIAX gqGF2AgdIHbnLOrtpI3a/rg35ifIhI5B7SzSc/WCn++leiddoW5lFwbM30lkBDsQ mTTb7wVX1KPS8TNF5B4IZdp2dDlnYmt3njGgKWiMxdQwTLL1AYjmuIZ82oXvkxP2 mnTzHpqYj8+5G+X8+WaoB1fQHzwOdpUWwfeKzOIFyrL2CJgV4CX6OmVgJyenfhu5 R4qmMLh2sIrGDIRe5CyWG5QCt9RszpeC3KkJ3sIKfAFV6bgFES5WAQLaGK9+LO0Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedugdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfveholhhi nhcuhggrlhhtvghrshdfuceofigrlhhtvghrshesvhgvrhgsuhhmrdhorhhgqeenucggtf frrghtthgvrhhnpeehgeehheeiledugeelleetkeeijeehueetteeggfeivdekudeghffh ueffledvvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpeifrghlthgvrhhssehvvghrsghumhdrohhrgh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DE5CD20061; Thu, 23 Jul 2020 09:38:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: In-Reply-To: <20200721155848.32xtze5ntvcmjv63@steredhat> References: <20200715171130.GG12769@casper.infradead.org> <7c09f6af-653f-db3f-2378-02dca2bc07f7@gmail.com> <48cc7eea-5b28-a584-a66c-4eed3fac5e76@gmail.com> <202007151511.2AA7718@keescook> <20200716131404.bnzsaarooumrp3kx@steredhat> <202007160751.ED56C55@keescook> <20200717080157.ezxapv7pscbqykhl@steredhat.lan> <20200721155848.32xtze5ntvcmjv63@steredhat> Date: Thu, 23 Jul 2020 09:37:40 -0400 From: "Colin Walters" To: "Stefano Garzarella" , "Andy Lutomirski" Cc: "Jens Axboe" , "Christoph Hellwig" , "Kees Cook" , "Pavel Begunkov" , "Miklos Szeredi" , "Matthew Wilcox" , "Jann Horn" , "Christian Brauner" , strace-devel@lists.strace.io, io-uring@vger.kernel.org, "Linux API" , "Linux FS Devel" , LKML , "Michael Kerrisk" , "Stefan Hajnoczi" Subject: Re: strace of io_uring events? Content-Type: text/plain Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Tue, Jul 21, 2020, at 11:58 AM, Stefano Garzarella wrote: > my use case concerns virtualization. The idea, that I described in the > proposal of io-uring restrictions [1], is to share io_uring CQ and SQ queues > with a guest VM for block operations. Virtualization being a strong security barrier is in eternal conflict with maximizing performance. All of these "let's add a special guest/host channel" are high risk areas. And this effort in particular - is it *really* worth it to expose a brand new, fast moving Linux kernel interface (that probably hasn't been fuzzed as much as it needs to be) to virtual machines? People who want maximum performance at the cost of a bit of security already have the choice to use Linux containers, where they can use io_uring natively.