kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Liu Shuo <shuo.a.liu@intel.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	"Zhang Yanmin" <yanmin_zhang@linux.intel.com>,
	"He Bo" <bo.he@intel.com>, "Liu Shuo" <shuox.liu@gmail.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH] KVM: release anon file in failure path of vm creation
Date: Fri, 15 Jul 2016 06:09:59 +0100	[thread overview]
Message-ID: <20160715050959.GH14480@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20160715031841.GA20887@shuo-desktop.sh.intel.com>

On Fri, Jul 15, 2016 at 11:18:41AM +0800, Liu Shuo wrote:

> If there is no such thread (who operates the descriptor based on
> guessing), i can think the changing is safe at the point. As the fd has
> not been delivered to userspace. Am i right?

<wry>
Expecting nice behaviour from userland code is something best avoided, really.
</wry>

All jokes aside, this other thread doesn't have to be malicious - just being
buggy would suffice.  Besides, you never know if something like userns won't
be dumped into the kernel, making your ioctl accessible to genuinely
malicious code.

The only sane approach is to treat descriptor tables as shared data structures
and postpone the insertion of struct file reference into descriptor table
until you are past all failure exits.  Including the ones related to copying
to userland - e.g. pipe(2) creates a pipe, sets up two struct file associated
with it, reserves two descriptors, copies them into userland array and only if
everything has succeeded proceeds to fd_install().  In your case passing the
descriptor to userland is not an issue (return value of ioctl(2) goes via
register and that can't fail), so the last failure exit is that after failed
attempt to create debugfs stuff.  We have to reserve the descriptor before
that (it's used as a part of debugfs directory name), so anon_inode_getfd()
is not an option - it combines reserving descriptor with fd_install().
Such situations are exactly the reason why anon_inode_getfile() is there;
anon_inode_getfd() is usable only when it is the very last thing we do
before returning the descriptor to userland.

FWIW, original code was not unreasonable - it simply treated debugfs stuff as
optional and ignored those failures.  That way anon_inode_getfd() is fine -
there's no failure exits after it.  If we want to fail when debugfs had
been enabled and we'd failed to populate it, we need to use the real primitives
behind anon_inode_getfd(), though.

  reply	other threads:[~2016-07-15  5:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-12  9:38 [PATCH] KVM: release anon file in failure path of vm creation Liu Shuo
2016-07-12 10:24 ` Paolo Bonzini
2016-07-14 16:46   ` Al Viro
2016-07-14 16:56     ` Paolo Bonzini
2016-07-15  2:22     ` Liu Shuo
2016-07-15  2:26       ` Al Viro
2016-07-15  3:18         ` Liu Shuo
2016-07-15  5:09           ` Al Viro [this message]
2016-07-15  7:04             ` Liu Shuo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160715050959.GH14480@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=bo.he@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=shuo.a.liu@intel.com \
    --cc=shuox.liu@gmail.com \
    --cc=yanmin_zhang@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).