linux-kernel - Re: ABI coupling to hypervisors via CONFIG

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: <45F1E008.5000000@goop.org>
Date:	Fri, 09 Mar 2007 14:30:32 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Chris Wright <chrisw@...s-sol.org>,
	Zachary Amsden <zach@...are.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>, akpm@...ux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: ABI coupling to hypervisors via CONFIG_PARAVIRT

Ingo Molnar wrote:
> yep. That's precisely my worry. And it doesnt have to be a 'great' thing 
> - just any random small change in the kernel that makes sense: what is 
> the likelyhood that it cannot be implemented, no matter what amount of 
> insight, paravirt_ops + hyper-ABI emulation hackery, for FoobieVisor, 
> because FoobieVisor messed up its ABI.
>
> that likelyhood is a pure function of how FoobieVisor's hypercall ABI is 
> shaped. Wow! So can you guess where my fixation about not having too 
> many ABIs could possibly originate from? ;-)
>   

OK, so its a problem that's happened before.  "It's a great idea, it's
so nice, but it breaks X."  Your options are:

   1. Well, nobody is really using X.  We can stop supporting it.
   2. X makes up 50% of the users, we'll just have to do without your
      great idea.
   3. Maybe we can get X updated so this idea works.

If X is a piece of hardware, then you're probably stuck with options 1
and 2.  If its something like firmware or a hypervisor, you might have a
chance with option 3.

The hypervisor interface is not at all special in this regard; you may
as well be arguing "We can't allow a port of Linux to the FoobieTron2000
CPU, because it might constrain some future development"; that's true,
it might.  But I don't think I've ever seen anyone make that argument
for not accepting a new architecture port.

I don't really understand what your overall argument is though.  Sure, I
guess its that if there's one ABI for all hypervisors, then you've only
got one hypervisor-related constraint to consider when evaluating a new
kernel change.  But that ABI is going to be as constraining as the its
most constraining hypervisor, so you're not really in a better position
than if you have N hypervisor ABIs.  In fact you're worse off, because
you have no flexibility to drop/adapt/whatever the real blocker.

> _Now_ at least i've got this minimal 
> admission that FoobieVisor _might_ break. Quite a breakthrough =B-)

If you went to all that typing to get that much of a concession, then
you have way too much time ;)

    J

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