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]

Date:	Fri, 7 Oct 2011 14:10:18 -0400
From:	Josh Boyer <jwboyer@...il.com>
To:	Valdis.Kletnieks@...edu
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, Oct 7, 2011 at 12:22 PM,  <Valdis.Kletnieks@...edu> wrote:
> 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.

I haven't checked either, which is why I asked Frank directly since
I'm assuming he has ;).

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

Yeah, I'm familiar with that line of reasoning.  It can be beneficial
to vbox itself, but then we have situations like this where users are
picking up that single-source package and trying to run it on distros
that change kernel versions rather frequently and that doesn't seem to
benefit anyone.  The users are left with a buggy machine/vbox
instance, the distributions are left with unhappy users, and vbox is
left with unhappy users AND unhappy distribution maintainers.
(Somehow the distributions get the brunt of the blame from the users,
but I'm not going to go down that path.  I'm trying to be productive.)

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

Yes.  Which is why I asked Frank :).

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