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]

Date:	Mon, 07 Aug 2006 17:42:23 -0700
From:	Zachary Amsden <zach@...are.com>
To:	Pavel Machek <pavel@...e.cz>
Cc:	Rik van Riel <riel@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>, greg@...ah.com,
	Andrew Morton <akpm@...l.org>,
	Christoph Hellwig <hch@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Jack Lo <jlo@...are.com>, Sahil Rihan <srihan@...are.com>
Subject: Re: A proposal - binary

Pavel Machek wrote:
> Well, I guess we'd like VMI to be buildable in normal kernel build
> tools ... and at that point, open sourcing it should be _really_ easy.
>
> And we'd prefer legal decisions not to influence technical ones. Maybe
> we will decide to use binary interface after all, but seeing GPLed,
> easily-buildable interface, first, means we can look at both solutions
> and decide which one is better.

I don't think you're actually arguing for the VMI ROM to be built into 
the kernel.  But since this could be a valid interpretation of what you 
said, let me address that point so other readers of this thread don't 
misinterpret.

On a purely technical level, the VMI layer must not be part of the 
normal kernel build.  It must be distributed by the hypervisor to which 
it communicates.  This is what provides hypervisor independence and 
hardware compatibility, and why it can't be distributed with the 
kernel.  The kernel interfaces for VMI that are part of the kernel 
proper are already completely open sourced and GPL'd.  The piece in 
question is the hypervisor specific VMI layer, which we have not yet 
released an open source distribution of.

We do use standard tools for building it, for the most part - although 
some perl scripting and elf munging magic is part of the build.  
Finally, since it is a ROM, we have to use a post-build tool to convert 
the extracted object to a ROM image and fix up the checksum.  We don't 
have a problem including any of those tools in an open source 
distribution of the VMI ESX ROM once we finish sorting through the 
license issues.  We've already fixed most of the problems we had with 
entangled header files so that we can create a buildable tarball that 
requires only standard GNU compilers, elf tools, and perl to run.  I 
believe the only technical issue left is fixing the makefiles so that 
building it doesn't require our rather complicated make system.

Hopefully we can have all this resolved soon so that you can build and 
distribute your own ROM images, see how the code operates, and use the 
base design framework as a blueprint for porting to other hypervisor 
implementations, porting other operating systems, or just as a general 
experimental layer that could be used for debugging or performance 
instrumentation.

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