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] [day] [month] [year] [list]

Date:	Wed, 9 Aug 2006 09:43:52 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	Zachary Amsden <zach@...are.com>
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

Hi!

> >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.

I actually was arguing for VMI ROM to be built into kernel. You have
pretty strong arguments why it will not work, but Xen is doing that,
and it would be at least very interesting to see how it works for
vmware. (And perhaps to decide that it does not work :-).

> 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 

Oh yes, it can be part of kernel build. #ifdef vmware_version_3_0_4 is
ugly, but at least it would force you not to change the interfaces too
often, which might be good thing.

> 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.

Good, nice, so you are close. Now get us GPLed release ;-).
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/