linux-kernel - Re: Ioctl warning for a partition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Jan 2012 17:28:17 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Michael Tokarev <mjt@....msk.ru>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jan Kara <jack@...e.cz>, Paolo Bonzini <pbonzini@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-scsi@...r.kernel.org,
	Jens Axboe <axboe@...nel.dk>,
	James Bottomley <JBottomley@...allels.com>, mmarek@...e.cz
Subject: Re: Ioctl warning for a partition

Hi Michael!

On Fri, 27 Jan 2012, Michael Tokarev wrote:

> On 27.01.2012 03:01, Linus Torvalds wrote:
> > On Thu, Jan 26, 2012 at 2:30 PM, Jan Kara <jack@...e.cz> wrote:
> >>
> >> It's easy enough to silence the warning the same way as
> >> CDROM_GET_CAPABILITY since the ioctl is safe but it's not so simple for
> >> 32-bit userspace.  MTIOCGET32 is defined only in fs/compat_ioctl.c so we
> >> cannot easily add it to scsi_verify_blk_ioctl(). Any opinion how to cleanly
> >> solve this? The only idea I had was to define compat structures and ioctl
> >> numbers in a special header and use it both in fs/compat_ioctl.c and in
> >> block/scsi_ioctl.c.
> > 
> > I suspect we can just remove the warning entirely - once we've gotten
> > enough coverage with the -rc kernels that people (me in particular)
> > are happy that no normal load really needs it, and returning an error
> > is fine.
> > 
> > So I don't really consider the warning to be something long-term - I
> > wanted it to make sure that some random binary in some odd
> > distribution wouldn't break in mysterious ways that would take a lot
> > of debugging to find. And so that we really know what we end up
> > blocking in practice.
> > 
> > I'm not sure how good the -rc kernel coverage is, but I think it's
> > good enough that we can drop the warning before doing a real 3.3
> > release. And I don't think the stable kernel versions ever got that
> > warning printout, did they? That would be great for coverage, of
> > course, if they did.
> 
> They did, 3.0 and 3.2.
> 
> For example, 3.0.18:
> 
> [  610.488489] kvm: sending ioctl 5326 to a partition!
> [  610.488540] kvm: sending ioctl 80200204 to a partition!
> 
> mdadm ioctls reported in various places apparently got fixed by
> ENOTTY/ENOIOCTLCMD change.

Does that fix still need to be backported to -stable?

Linux v3.0.18 + Debian stable userspace (mdadm v3.1.4) causes this on
boot (when mdadm runs in the initramfs):

mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 1261 to a partition!
mdadm: sending ioctl 800c0910 to a partition!
mdadm: sending ioctl 800c0910 to a partition!

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/