linux-kernel - Re: Xen & VMI?

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: <20070306205351.GA10574@sequoia.sous-sol.org>
Date:	Tue, 6 Mar 2007 12:53:51 -0800
From:	Chris Wright <chrisw@...s-sol.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Chris Wright <chrisw@...s-sol.org>, Gerd Hoffmann <kraxel@...e.de>,
	virtualization <virtualization@...ts.osdl.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Roland McGrath <roland@...hat.com>
Subject: Re: Xen & VMI?

* Ingo Molnar (mingo@...e.hu) wrote:
> 
> * Chris Wright <chrisw@...s-sol.org> wrote:
> 
> > What are you driving at?  You seem to be arguing that abstractions are 
> > bad unless done via ABI's. [...]
> 
> i'm still arguing the same: that doing the same thing via overlapping, 
> conflicting, redundant ABIs is crazy and contrary to the basic interests 
> of Linux. It's like having 5 different, parallel variants of sys_open(), 
> interfaced via a convoluted open_ops.

I would've said 5 parallel implementations of inode->i_op simply given
the nature of the operations, which is entirely sane.

> having data ABI coupling is one thing (filesystems, network formats, 
> etc.). But having a 5-way function ABI coupling between system software 
> running on the /same piece of hardware/, doing the same thing in essence 
> is just madness in my book.

This is where I'm not understanding your argument.  The hardware is
somewhat irrelevant since the OS is running on a platform presented by the
hypervisor.  And the point is to allow multiple implementations of the OS
opertations that interact with the platform.  And in essence all network
stacks and file systems are doing the same thing with the same hardware.
Here's the reality.  None of these hypervisors will be ABI compliant in
the way syscalls are (namely trap insn and hypercall number).  So there's
a bunch of glue wherever you design the system.  Your arguement is that in
some (arguably random) instances it makes sense to push the glue into
the ROM.  This idea that lguest and KVM come from the same source tree
is irrelevant when the issues you site are about support matrices (which
means that guest and host may not have come from the same source afterall).
I still don't understand your issue.

thanks,
-chris
-
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/