From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Decker, Schorschi" Subject: Re: Guest kernel device compatability auto-detection Date: Thu, 25 Aug 2011 16:25:28 +0000 Message-ID: <559DD0FA4608774CA06F6DFA0F16FE830C96C30D@ex2k.bankofamerica.com> References: <1314249688.3459.23.camel@lappy> <4E55DE90.2020503@redhat.com> <20110825073212.GD3905@amd.home.annexia.org> <1314258034.3692.7.camel@lappy> <20110825074825.GA1106@amd.home.annexia.org> <20110825100124.GA3197@amd.home.annexia.org> Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Avi Kivity , kvm To: "Richard W.M. Jones" , "qemu-devel@nongnu.org" Return-path: In-reply-to: <20110825100124.GA3197@amd.home.annexia.org> Content-language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org >>From a security perspective, this not a great idea. Security isolation in virtualization is gaining ground, so anything that breaches the hypervisor/guest vale is by your typical enterprise/company security team considered completely illegal, a number of firms I have talked with all are talking about how their respective security teams are raising all kinds of hell/red flags, demanding disablement of features that breach the vale. I would ask two things be done in the design if it goes forward, 1) have an explicit way to disable this feature, where the hypervisor cannot interact with the guest OS directly in any way if disablement is selected. 2) implement the feature as an agent in the guest OS where the hypervisor can only query the guest OS agent, using a standard TCP/IP methodology. Any under the hood, under the covers methodology, I can tell you for a fact, security teams will quash, or demand the feature is disabled. This goes for VM to VM communication as well that does not use a formal TCP/IP stack based method as well. Security teams want true OS isolation, point blank. Schorschi Decker VP; Sr. Consultant Engineer ECT&O Emerging Technologies / Virtualization Platform Engineering Team Bank of America Office 213-345-4714 -----Original Message----- From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On Behalf Of Richard W.M. Jones Sent: Thursday, 25 August, 2011 03:01 To: qemu-devel@nongnu.org Cc: Avi Kivity; kvm Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection On Thu, Aug 25, 2011 at 08:48:25AM +0100, Richard W.M. Jones wrote: > On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote: > > From what I gathered libguestfs only provides access to the guests' > > image. > > Correct. > > > Which part is doing the IKCONFIG or System.map probing? Or is it > > done in a different way? > > You'll have to see what Matt's doing in the virt-v2v code for the > details, but in general we have full access to: > > - grub.conf (to determine which kernel will boot) > - the kernel image > - the corresponding System.map and config > - the modules directory > - the Xorg config > - boot.ini or BCD (to determine which NT kernel will boot) > - the Windows Registry > - the list of packages installed (to see if VMware-tools or some other > guest agent is installed) > > So working out what drivers are available is just a tedious matter of > iterating across each of these places in the filesystem. We had some interesting discussion on IRC about this. Detecting if a guest "supports virtio" is a tricky problem, and it goes beyond what the guest kernel can do. For Linux guests you also need to check what userspace can do. This means unpacking the initrd and checking for virtio drivers [in the general case this is intractable, but you can do it for specific distros]. You also need to check that udev has the correct rules and that LVM is configured to see VGs on /dev/vd* devices. Console and Xorg configuration may also need to be checked (for virtio-console and Cirrus/QXL support resp.) virt-v2v does quite a lot of work to *enable* virtio drivers including: - possibly installing a new kernel and updating grub - rebuilding the initrd to include virtio drivers - adjusting many different config files - removing other guest tools and Xen drivers - reconfiguring SELinux - adding viostor driver to Windows and adjusting the Windows Registry Critical Device Database Of course virt-v2v confines itself to specific known guests, and we test it like crazy. Here is the code: http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/RedHat.pm;hb=HEAD http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/Windows.pm;hb=HEAD Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwckN-00054Y-6w for qemu-devel@nongnu.org; Thu, 25 Aug 2011 12:25:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwckL-00018D-Km for qemu-devel@nongnu.org; Thu, 25 Aug 2011 12:25:39 -0400 Received: from txmx08.bankofamerica.com ([171.161.160.26]:32387 helo=txdmzmailmx08.bankofamerica.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwckL-00017i-FD for qemu-devel@nongnu.org; Thu, 25 Aug 2011 12:25:37 -0400 Date: Thu, 25 Aug 2011 16:25:28 +0000 From: "Decker, Schorschi" In-reply-to: <20110825100124.GA3197@amd.home.annexia.org> Message-id: <559DD0FA4608774CA06F6DFA0F16FE830C96C30D@ex2k.bankofamerica.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-language: en-US Content-transfer-encoding: 7BIT References: <1314249688.3459.23.camel@lappy> <4E55DE90.2020503@redhat.com> <20110825073212.GD3905@amd.home.annexia.org> <1314258034.3692.7.camel@lappy> <20110825074825.GA1106@amd.home.annexia.org> <20110825100124.GA3197@amd.home.annexia.org> Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" , "qemu-devel@nongnu.org" Cc: Avi Kivity , kvm >>From a security perspective, this not a great idea. Security isolation in virtualization is gaining ground, so anything that breaches the hypervisor/guest vale is by your typical enterprise/company security team considered completely illegal, a number of firms I have talked with all are talking about how their respective security teams are raising all kinds of hell/red flags, demanding disablement of features that breach the vale. I would ask two things be done in the design if it goes forward, 1) have an explicit way to disable this feature, where the hypervisor cannot interact with the guest OS directly in any way if disablement is selected. 2) implement the feature as an agent in the guest OS where the hypervisor can only query the guest OS agent, using a standard TCP/IP methodology. Any under the hood, under the covers methodology, I can tell you for a fact, security teams will quash, or demand the feature is disabled. This goes for VM to VM communication as well that does not use a formal TCP/IP stack based method as well. Security teams want true OS isolation, point blank. Schorschi Decker VP; Sr. Consultant Engineer ECT&O Emerging Technologies / Virtualization Platform Engineering Team Bank of America Office 213-345-4714 -----Original Message----- From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On Behalf Of Richard W.M. Jones Sent: Thursday, 25 August, 2011 03:01 To: qemu-devel@nongnu.org Cc: Avi Kivity; kvm Subject: Re: [Qemu-devel] Guest kernel device compatability auto-detection On Thu, Aug 25, 2011 at 08:48:25AM +0100, Richard W.M. Jones wrote: > On Thu, Aug 25, 2011 at 10:40:34AM +0300, Sasha Levin wrote: > > From what I gathered libguestfs only provides access to the guests' > > image. > > Correct. > > > Which part is doing the IKCONFIG or System.map probing? Or is it > > done in a different way? > > You'll have to see what Matt's doing in the virt-v2v code for the > details, but in general we have full access to: > > - grub.conf (to determine which kernel will boot) > - the kernel image > - the corresponding System.map and config > - the modules directory > - the Xorg config > - boot.ini or BCD (to determine which NT kernel will boot) > - the Windows Registry > - the list of packages installed (to see if VMware-tools or some other > guest agent is installed) > > So working out what drivers are available is just a tedious matter of > iterating across each of these places in the filesystem. We had some interesting discussion on IRC about this. Detecting if a guest "supports virtio" is a tricky problem, and it goes beyond what the guest kernel can do. For Linux guests you also need to check what userspace can do. This means unpacking the initrd and checking for virtio drivers [in the general case this is intractable, but you can do it for specific distros]. You also need to check that udev has the correct rules and that LVM is configured to see VGs on /dev/vd* devices. Console and Xorg configuration may also need to be checked (for virtio-console and Cirrus/QXL support resp.) virt-v2v does quite a lot of work to *enable* virtio drivers including: - possibly installing a new kernel and updating grub - rebuilding the initrd to include virtio drivers - adjusting many different config files - removing other guest tools and Xen drivers - reconfiguring SELinux - adding viostor driver to Windows and adjusting the Windows Registry Critical Device Database Of course virt-v2v confines itself to specific known guests, and we test it like crazy. Here is the code: http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/RedHat.pm;hb=HEAD http://git.fedorahosted.org/git/?p=virt-v2v.git;a=blob;f=lib/Sys/VirtConvert/Converter/Windows.pm;hb=HEAD Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.