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 09:35:11 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Jan Kara <jack@...e.cz>, 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

On 01/27/2012 12:01 AM, Linus Torvalds wrote:
> 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.

Here is the list I put together from people who contacted me about the 
warning:

BLKFLSBUF, BLKROSET:
	These two can be passed down to ops->ioctl even though
	they are generic block layer ioctls.  Nothing overrides them
	*and* calls scsi_verify_blk_ioctl so we aren't breaking
	anything.  However, these ioctls are obviously good for
	partitions so we should add them to the whitelist.

CDROM_DRIVE_STATUS, FDGETPRM, MTIOCGET32:
	These three are used for detection of devices that do not
	support	partitions.  They can be handled the same as
	CDROM_GET_CAPABILITY, i.e. we can fail them and not break
	anything.

RAID_VERSION:
	Also used for detection, however (unlike floppies and CD-ROMs)
	RAID devices do have partitions.  RAID partitions do not
	support SCSI ioctls and thus do not call scsi_verify_blk_ioctl,
	which means we can fail this one right away too.

I was preparing a patch to update the whitelist, but I think I will wait 
a couple more weeks and remove the warning altogether.

Paolo
--
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/