linux-kernel - Re: A proposal

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: <Pine.LNX.4.63.0608041239430.18862@qynat.qvtvafvgr.pbz>
Date:	Fri, 4 Aug 2006 12:45:50 -0700 (PDT)
From:	David Lang <dlang@...italinsight.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
cc:	Antonio Vargas <windenntw@...il.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Morton <akpm@...l.org>, jeremy@...source.com,
	greg@...ah.com, zach@...are.com, linux-kernel@...r.kernel.org,
	torvalds@...l.org, hch@...radead.org, jlo@...are.com,
	xen-devel@...ts.xensource.com, simon@...source.com,
	ian.pratt@...source.com, jeremy@...p.org
Subject: Re: A proposal - binary

On Fri, 4 Aug 2006, Arjan van de Ven wrote:

> David Lang wrote:
>> I'm not commenting on any of the specifics of the interface calls (I trust 
>> you guys to make that be sane :-) I'm just responding the the idea that the 
>> interface actually needs to be locked down to an ABI as opposed to just 
>> source-level compatability.
>
> you are right that the interface to the HV should be stable. But those are 
> going
> to be specific to the HV, the paravirt_ops allows the kernel to smoothly deal
> with having different HV's.
> So in a way it's an API interface to allow the kernel to deal with multiple
> different ABIs that exist today and will in the future.

so if I understand this correctly we are saying that a kernel compiled to run on 
hypervisor A would need to be recompiled to run on hypervisor B, and recompiled 
again to run on hypervisor C, etc

where A could be bare hardware, B could be Xen 2, C could be Xen 3, D could be 
vmware, E could be vanilla Linux, etc.

this sounds like something that the distros would not support, they would pick 
their one hypervisor to support and leave out the others. the big problem with 
this is that the preferred hypervisor will change over time and people will be 
left with incompatable choices (or having to compile their own kernels, 
including having to recompile older kernels to support newer hypervisors)

David Lang


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