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: <20070306212855.GB10574@sequoia.sous-sol.org>
Date:	Tue, 6 Mar 2007 13:28:55 -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:
> with the big freaking difference that the 5 parallel implementations of 
> inode->i_op are:
> 
> 	_internal to Linux_

Granted.  Until it's modprobe xen.ko, vmware.ko, viridian.ko...that's
not going to go away, even with the VMI.

> Doh. There's only a data ABI underneath them.

Perhaps from the syscall perspective.  But there's also things like
internal interactions with the page cache, VMA and pt updates, etc
which are much more functional/behavioural than purely moving data.
And when we're talking about page tables or simlar for hv, I think the
data vs. functional is an oversimplification.

> every time someone tried to impose a functional/behavioral ABI on core 
> bits of Linux we said: 'no way dude!'. Remember STREAMS? Remember the 
> module KABI? Remember ACPI? [doh, i guess we messed up on the latter 
> one. We regret that day ever since.]

Heheh, OK, now I know I'm lost when we've both used ACPI as a negative
example to argue our point.  Honestly, all of the above suggest no VMI
to me (in fact, I used those type of arguments against VMI about 1 year
ago ;-).

> (network file systems are a bit of an exception to the rule, but those 
> are pretty isolated themselves and in no way as wide and central as the 
> direction paravirt_ops appears to grow.)
> 
> > > 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. [...]
> 
> again, those are /DATA/ ABIs. Not function ABIs. Not behavioral ABIs. 
> The coupling is /FAR/ saner and far more plannable and far more 
> isolated. And even data ABIs are very non-trivial ...

I agree that changing the interface to the low-level platform is tricky
and less isolated.  But how does the VMI protect you from those changes?
It simply doesn't, the changes are still necessary.  And the inflexibility
means the tough corner cases swept under the VMI rug are more difficult
to debug, get right, etc...

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/