linux-kernel - RE: allocate an official device major number for virtio device?

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:	Thu, 3 Mar 2016 03:52:20 +0000
From:	"Ning, Yu" <yu.ning@...el.com>
To:	Jin Qian <jinqian@...roid.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Jeff Sharkey" <jsharkey@...gle.com>,
	David Turner <digit@...gle.com>,
	"pprabhu@...gle.com" <pprabhu@...gle.com>
Subject: RE: allocate an official device major number for virtio device?

Well, virtio_blk does use dynamic major number allocation, but the allocated block major just happens to fall in the "experimental" range (240-254)...

In more detail:

virtio_blk calls register_blkdev() with major = 0 in init() (drivers/block/virtio_blk.c:872):

	major = register_blkdev(0, "virtblk");

This line has been there since day one.  And register_blkdev() implements dynamic major allocation pretty straightforwardly:

	/* temporary */
	if (major == 0) {
		for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
			if (major_names[index] == NULL)
				break;
		}

So it goes from index = 254 to 1 and picks the first unused.  Apparently, there's a good chance that the allocated major is between 240-254 (although lower numbers are also possible, theoretically).  Indeed, we always get 253 for virtio_blk with the x86_64 Android emulator kernel.

But "dynamic" means we can't rely on checking major == 253 to detect virtio_blk.  That's why we are doing a fnmatch() using pattern /sys/devices/*/block/vd* instead.  Is that the recommended approach?

Thanks,
Yu

> -----Original Message-----
> From: Jin Qian [mailto:jinqian@...roid.com]
> Sent: Thursday, March 3, 2016 9:48
> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Cc: linux-kernel@...r.kernel.org; Jeff Sharkey <jsharkey@...gle.com>; David
> Turner <digit@...gle.com>; pprabhu@...gle.com; Ning, Yu
> <yu.ning@...el.com>
> Subject: Re: allocate an official device major number for virtio device?
> 
> Do you mean detecting device name string as in /dev/...?
> 
> Just checked latest virtio_blk code, it's dynamic but not using anything specific
> to experimental range. I guess we're fine here but Yu can confirm.
> 
> Thanks,
> jin
> 
> On Wed, Mar 2, 2016 at 5:25 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Wed, Mar 02, 2016 at 05:08:00PM -0800, Jin Qian wrote:
> >> Hi -
> >>
> >> Can we allocate an official device major number for virtio devices?
> >> Currently it's using 240-254 (LOCAL/EXPERIMENTAL USE). The reason we
> >> ask for this is because userspace will need to treat virtio block
> >> devices differently and need a way to detect such device. For
> >> example, it checks major number to detect scsi and mmc device.
> >>
> >> https://android-review.googlesource.com/#/c/195240
> >>
> >> With dynamic major numbers 240-254, we might treat other devices as
> >> virtio block device incorrectly.
> >
> > You shouldn't treat them incorrectly, devtmpfs handles this for you
> > automatically, so I'd recommend using the dynamic majors please.
> >
> > And what in-kernel code is using the "experimental" range today?  Do
> > you have a pointer to that?  We should fix that now...
> >
> > thanks,
> >
> > greg k-h