linux-kernel - Re: A proposal

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: <Pine.LNX.4.63.0608041325280.18862@qynat.qvtvafvgr.pbz>
Date:	Fri, 4 Aug 2006 13:31:47 -0700 (PDT)
From:	David Lang <dlang@...italinsight.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Antonio Vargas <windenntw@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Morton <akpm@...l.org>, jeremy@...source.com,
	greg@...ah.com, zach@...are.com, linux-kernel@...r.kernel.org,
	torvalds@...l.org, hch@...radead.org, jlo@...are.com,
	xen-devel@...ts.xensource.com, simon@...source.com,
	ian.pratt@...source.com
Subject: Re: A proposal - binary

On Fri, 4 Aug 2006, Jeremy Fitzhardinge wrote:

>> so if I understand this correctly we are saying that a kernel compiled to 
>> run on hypervisor A would need to be recompiled to run on hypervisor B, and 
>> recompiled again to run on hypervisor C, etc
>> 
>> where A could be bare hardware, B could be Xen 2, C could be Xen 3, D could 
>> be vmware, E could be vanilla Linux, etc.
>
> Yes, but you can compile one kernel for any set of hypervisors, so if you 
> want both Xen and VMI, then compile both in.  (You always get bare hardware 
> support.)

how can I compile in support for Xen4 on my 2.6.18 kernel? after all xen 2 and 
xen3 are incompatable hypervisors so why wouldn't xen4 (and I realize there is 
no xen4 yet, but there is likly to be one during the time virtual servers 
created with 2.6.18 are still running)

>> this sounds like something that the distros would not support, they would 
>> pick their one hypervisor to support and leave out the others. the big 
>> problem with this is that the preferred hypervisor will change over time 
>> and people will be left with incompatable choices (or having to compile 
>> their own kernels, including having to recompile older kernels to support 
>> newer hypervisors)
>
> Why?  That's like saying that distros will only bother to compile in one scsi 
> driver.
>
> The hypervisor driver is tricker than a normal kernel device driver, because 
> in general it needs to be present from very early in boot, which precludes it 
> from being a normal module.  There's hope that we'll be able to support 
> hypervisor drivers as boot-time grub/multiboot modules, so you'll be able to 
> compile up a new hypervisor driver for a particular kernel and use it without 
> recompiling the whole thing.

distros don't offer kernels with all options today, why would they in the future 
(how many distros offer seperate 486/586/K6/K7/Pentium/P2/P3/P4 kernels, none. 
they offer a least-common denominator kernel or two instead)

I also am missing something here. how can a system be compiled to do several 
different things for the same privilaged opcode (including running that opcode) 
without turning that area of code into a performance pig as it checks for each 
possible hypervisor being present?

David Lang
-
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/