From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br5Mm-00078o-Ka for qemu-devel@nongnu.org; Mon, 03 Oct 2016 11:41:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1br5Mj-0006np-Cp for qemu-devel@nongnu.org; Mon, 03 Oct 2016 11:41:20 -0400 Received: from mail-qk0-x236.google.com ([2607:f8b0:400d:c09::236]:35769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1br5Mj-0006nd-83 for qemu-devel@nongnu.org; Mon, 03 Oct 2016 11:41:17 -0400 Received: by mail-qk0-x236.google.com with SMTP id t7so166476962qkh.2 for ; Mon, 03 Oct 2016 08:41:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafael David Tinoco In-Reply-To: <20160927121841.GM3967@redhat.com> Date: Mon, 3 Oct 2016 12:41:10 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3F76E640-1E36-4C4A-8BB9-1DD1EF602FEF@canonical.com> References: <20160923110300.23502.55001.malonedeb@soybean.canonical.com> <20160927030621.20862-1-rafael.tinoco@canonical.com> <20160927083626.GC3967@redhat.com> <7220810B-7C81-4B51-BDE5-7BC0022F3605@canonical.com> <20160927121841.GM3967@redhat.com> Subject: Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 1626972 <1626972@bugs.launchpad.net> Cc: Rafael David Tinoco , qemu-devel , marcandre lureau , mst@redhat.com Sorry, I was only able to come back to this today. > On Sep 27, 2016, at 09:18, Daniel Berrange = <1626972@bugs.launchpad.net> wrote: >=20 >> There are numerous people relying on older kernels in openstack=20 >> deployments - sometimes with specific drivers (ovswitch, dpdk,=20 >> infiniband) holding kernel upgrades - but still in need of upgrading=20= >> userland (e.g. newer releases). Having a fallback mechanism seems=20 >> appropriate for those cases. >=20 > I'm not against some kind of fallback - just about the way it > silently creates files in /tmp. >=20 That is why memfd_create is used here I suppose: To allow = anonymous-backed-pages to have a descriptor and to be sealed. When = falling back this mechanism I don't see any other way other than = creating a temporary file. Of course one way would be something like: http://paste.ubuntu.com/23270379/ But this is pretty much the same, just solving the "where to place the = temporary file" (non configurable for this usage).=20 >>=20 >> Note that the filename, per se, is not as important as other files,=20= >> since qemu won't provide it for being accessed by external programs, = and, >> deletes the file, while keeping the descriptor, right after its = creation >> (due to its nature, that is probably why it was created in /tmp). >=20 > If it doesn't shared with other processes, and is deleted immediately, > why does the file need to be on disk at all ? Well, it unlinks the file but the references are still there while the = descriptor isn't closed by this process, or by the one that receives the = descriptor (that is why is the "unlink" so early).=20 If you check vhost_dev_log_resize(), it gets *possible* new vhost log = (if a new size is given) and informs the vhost dev driver about the new = log base (vhost_ops->vhost_set_log_base).=20 For vhost_user, this means that the file descriptors for vhost logs are = likely going to be passed to vhost backend (fds[] in = vhost_user_set_log_base). This is just one example, not sure about = others.=20 Probably the best approach here, like what Marc-Andr=C3=A9 said, is to = create some sort of TMPDIR, set by libvirt perhaps ? >=20 > Regards, > Daniel