linux-kernel - RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code

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]

Message-ID: <6E21E5352C11B742B20C142EB499E0481DF543@TK5EX14MBXC124.redmond.corp.microsoft.com>
Date:	Mon, 2 May 2011 19:48:38 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	Greg KH <greg@...ah.com>, "gregkh@...e.de" <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>
Subject: RE: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code



> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@...radead.org]
> Sent: Sunday, May 01, 2011 4:53 PM
> To: KY Srinivasan
> Cc: Greg KH; gregkh@...e.de; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; virtualization@...ts.osdl.org
> Subject: Re: [PATCH 00/25] Staging: hv: Cleanup vmbus driver code
> 
> On Sun, May 01, 2011 at 06:08:37PM +0000, KY Srinivasan wrote:
> > Could you elaborate on the problems/issues when the block driver registers for
> the
> > IDE majors. On the Qemu side, we have a mechanism to disable the emulation
> when
> > PV drivers load. I don't think there is an equivalent mechanism on the Windows
> side.
> > So, as far as I know, registering for the IDE majors is the only way to also
> prevent native
> > drivers in Linux from taking control of the emulated device.
> 
> What qemu are you talking about for the qemu side?  Upstream qemu
> doesn't have any way to provide the same image as multiple devices,
> nevermind dynamically unplugging bits in that case.  Nor does it support
> the hyperv devices.

I am talking about the qemu that was (is) shipping with Xen.  In Hyper-V,
the block devices configured as IDE devices for the guest will be taken over
by the native drivers if the PV drivers don't load first and  take over the IDE majors.
If you want to have the root device be managed by the PV drivers, this appears to be
the only way to ensure that native IDE drivers don't take over the root device. Granted,
this depends on ensuring the PV drivers load first, but I don't know if there is another way
to achieve this.

> 
> When you steal majors you rely on:
> 
>  a) loading earlier than the driver you steal them from
>  b) the driver not simple using other numbers
>  c) if it doesn't preventing it from working at all, also for
>     devices you don't "replace" with your PV devices.

These are exactly the issues that had to be solved to have the PV 
drivers manage the root device.

>  d) that the guest actually uses the minors your claim, e.g. any
>     current linux distribution uses libata anyway, so you old IDE
>     major claim wouldn't do anything.  Nor would claiming sd majors
>     as the low-level libata driver would still drive the hardware
>     even if SD doesn't bind to it.

By setting up appropriate modprobe rules, this can be addressed.

> 
> You really must never present the same device as two emulated devices
> instead of doing such hacks.

Agreed; I am not sure what the right solution for Hyper-V is other than 
(a) preventing the native IDE drivers from loading and (b) having
the right modprobe rules to ensure libata would not present these
same devices to the guest as scsi devices.

Regards,

K. Y
--
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/