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: <45F1D8D7.9040207@goop.org>
Date:	Fri, 09 Mar 2007 13:59:51 -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:
> i am worried whether /any/ future change to the upstream kernel's design 
> can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i 
> mean truly any. And whether that can be done is not a function of the 
> flexibility of paravirt_ops, it's a function of the flexibility of the 
> VMI ABI.

Come on. You're talking as if these changes can be made in a vacuum,
with no regard to any external constraints.  In reality, any such change
is limited by concerns like:

   1. does it make sense in terms of kernel design?
   2. can all the (real) architectures support it?
   3. does it make sense on real hardware?
   4. does it require massive kernel-wide changes, or does it have
      limited scope?
   5. etc, etc

Obviously one of the things to be considered among the many other issues
is "what effect does this have on the paravirt_ops interface?".

Now it may be that you've got a change that's absolutely great for
everyone, and the only blocker is that the FoobieVisor can't deal with
it.  OK, great, then you'd have a point.

But are you really saying that one of your handwavy proposals is just
fine on a pre-apic i486/mmu-less m68k/whatever, but can't be made to
work on a hypervisor?

Come up with a specific proposal, and we'll work out the details.

    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/