linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Willy Tarreau <w@1wt.eu>,
	linux-kernel@vger.kernel.org, security@kernel.org,
	pmatouse@redhat.com, agk@redhat.com, jbottomley@parallels.com,
	mchristi@redhat.com, msnitzer@redhat.com
Subject: Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices
Date: Fri, 23 Dec 2011 15:15:00 +0100	[thread overview]
Message-ID: <4EF48CE4.3000104@redhat.com> (raw)
In-Reply-To: <CA+55aFxnOwkquH8tirqJnM_KTcavAejY8drL11jy2S+2PXmZuw@mail.gmail.com>

On 12/23/2011 10:22 AM, Linus Torvalds wrote:
> On Thu, Dec 22, 2011 at 10:26 PM, Willy Tarreau<w@1wt.eu>  wrote:
>>
>> Call me dumb, but why would someone use "eject" on a non-physically
>> ejectable device such as a memory stick ?
>
> Perhaps because that's the operation that works everywhere and is the
> simplest one?

But does it actually do anything?  For me, "eject /dev/sdf1" does 
nothing beyond unmounting the disk.  Yes, it sends a CDROMEJECT ioctl 
which becomes a start/stop unit SCSI command, but it has no effect on 
the USB stick I tried.

I tried it on a card reader, and indeed it started reporting "no medium 
found" after ejecting.

And actually there it fixes a potential data corruption.  Because yes, 
most USB sticks and cards have one partition.  But if you had two, 
"eject /dev/sdf1" would unmount one partition and CDROMEJECT the whole 
card.  Which means the other partition is left unclean.  (Invoked with 
"eject /dev/sdb", eject at least tries to go through the partitions and 
unmounts all of them.  Not bulletproof, but almost there).

So "eject /dev/sdb1" on USB sticks is just an unmount.  On card readers 
it will indeed be affected by the patch.  But the actual eject operation 
that it does after unmounting ought to fail.  It hasn't so far?  Just 
another instance of the bug I'm fixing.

> Just look at the icon on your desktop - it probably has "Eject" above
> the silly "Safely remove drive" when you right-click it. It has for
> me.

Assuming you're using GNOME3, for USB sticks the "Eject" button unmounts 
the volume, but it leaves the /dev/ files in place.  "Safely remove 
drive" unmounts the volume and also does what udisks calls "detach".  It 
sends a start/stop unit SCSI command (same as CDROMEJECT and the eject 
command) and then unplugs the device via sysfs.  To be precise, it also 
sends a cache flush, just in case the disk reported itself as 
writethrough but wasn't, so it is actually safer than eject.

But udisks never sends SCSI commands to partition devices, because 
udisks knows the distinction between disk and partition.  Even on an 
unpatched kernel, "udisks --detach /dev/sdf1" fails with "Detach failed: 
Device is not a drive".  In general, I looked at the source code for 
this throughout the GNOME stack (both GNOME2 and GNOME3), and everywhere 
they distinguish between "drive" and "volume" objects.  Eject maps to a 
method on the volume's eject method, while "safely remove drive" maps to 
the drive's stop method.

So, no, nothing I tried to do on USB sticks from a recent desktop 
environment will break with the patch.

Before udisks, HAL had "unmount" and "eject".  With or without the 
patch, on USB sticks they act the same.  They unmount the volume and 
leave /dev/ files in place.

> So yes, I claim that "eject" is actually the *natural* thing to do
> before you physically remove the medium, because it works across
> different media.

If you talk about ejecting the disk, yeah, "safely remove drive" is just 
paranoia.  But if you talk about ejecting a partition from the 
command-line, then no, not at all.

Paolo

  parent reply	other threads:[~2011-12-23 14:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-22 18:02 [PATCH 0/3] possible privilege escalation via SG_IO ioctl (CVE-2011-4127) Paolo Bonzini
2011-12-22 18:02 ` [PATCH 1/3] block: add and use scsi_blk_cmd_ioctl Paolo Bonzini
2011-12-22 18:02 ` [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices Paolo Bonzini
2011-12-22 18:37   ` Linus Torvalds
2011-12-22 19:11     ` Willy Tarreau
2011-12-22 19:18     ` Paolo Bonzini
2011-12-22 19:44       ` Linus Torvalds
2011-12-22 20:23         ` Paolo Bonzini
2011-12-22 20:52           ` Linus Torvalds
2011-12-22 22:08             ` Paolo Bonzini
2011-12-22 22:25               ` Linus Torvalds
2011-12-22 23:48                 ` Alasdair G Kergon
2011-12-23  0:07                   ` Linus Torvalds
2011-12-23  6:26                     ` Willy Tarreau
2011-12-23  9:22                       ` Linus Torvalds
2011-12-23  9:45                         ` Willy Tarreau
2011-12-23 14:15                         ` Paolo Bonzini [this message]
2011-12-23 22:46                           ` Linus Torvalds
2012-01-05 13:18                             ` Paolo Bonzini
2012-01-05 16:16                               ` Linus Torvalds
2012-01-05 16:40                                 ` Paolo Bonzini
2012-01-05 17:04                                   ` Linus Torvalds
2012-01-05 17:26                                     ` Paolo Bonzini
2012-01-05 23:49                               ` Linus Torvalds
2011-12-26  1:41                       ` Daniel Barkalow
2011-12-23  0:17                 ` H. Peter Anvin
2011-12-22 18:02 ` [PATCH 3/3] dm: do not forward ioctls from logical volumes to the underlying device Paolo Bonzini

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=4EF48CE4.3000104@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=agk@redhat.com \
    --cc=jbottomley@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchristi@redhat.com \
    --cc=msnitzer@redhat.com \
    --cc=pmatouse@redhat.com \
    --cc=security@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=w@1wt.eu \
    /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).