linux-kernel - Re: RFC: virtualbox tainting.

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: <14824.1318004546@turing-police.cc.vt.edu>
Date:	Fri, 07 Oct 2011 12:22:26 -0400
From:	Valdis.Kletnieks@...edu
To:	Josh Boyer <jwboyer@...il.com>
Cc:	Frank Mehnert <frank.mehnert@...cle.com>,
	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andy Hall <andy.hall@...cle.com>
Subject: Re: RFC: virtualbox tainting.

On Fri, 07 Oct 2011 11:16:13 EDT, Josh Boyer said:
> In all seriousness, is there a reason these modules haven't been
> submitted to the staging tree?  Perhaps this was attempted in the past
> and I'm just not finding references to it.

I haven't actually checked what the churn rate of the kernel side of VirtualBox is, but
there *is* some benefit if you have a package that includes both userspace and kernel
code, to keep them in sync.

Currently, VirtualBox is at 4.1.4.  Now, if they decide they need to change/fix/extend
the API for some reason, they can just ship a 4.1.6 and be happy.  If the code is
in-tree, then they are basically stuck with the API - they can't ship a 4.1.6 that can
get away with assuming that all the kernel API is there.  So you have to carry around
workarounds and test-for-features code and all that stuff.

I don't know - maybe the Oracle crew think the API is stable enough now that they can
afford to do that.  But Frank would probably be the one to speak to how in/out of tree
would affect their development/support methodology.

Content of type "application/pgp-signature" skipped