[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fal
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism |
Date: |
Tue, 27 Sep 2016 13:18:41 +0100 |
User-agent: |
Mutt/1.7.0 (2016-08-17) |
On Tue, Sep 27, 2016 at 11:01:10AM -0000, Rafael David Tinoco wrote:
> > On Sep 27, 2016, at 05:36, Daniel P. Berrange <address@hidden> wrote:
> >
> > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote:
> >> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback
> >> mechanism for systems not supporting memfd_create syscall (started
> >> being supported since 3.17).
> >
> > This is really dubious code in general and IMHO should just
> > be reverted.
>
> There are numerous people relying on older kernels in openstack
> deployments - sometimes with specific drivers (ovswitch, dpdk,
> infiniband) holding kernel upgrades - but still in need of upgrading
> userland (e.g. newer releases). Having a fallback mechanism seems
> appropriate for those cases.
I'm not against some kind of fallback - just about the way it
silently creates files in /tmp.
>
> Note that the filename, per se, is not as important as other files,
> 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).
If it doesn't shared with other processes, and is deleted immediately,
why does the file need to be on disk at all ?
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|