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]

Date:	Fri, 4 Aug 2006 09:19:44 +0200
From:	"Antonio Vargas" <windenntw@...il.com>
To:	"Chris Wright" <chrisw@...s-sol.org>,
	"Andrew Morton" <akpm@...l.org>,
	"Jeremy Fitzhardinge" <jeremy@...source.com>, greg@...ah.com,
	zach@...are.com, linux-kernel@...r.kernel.org, torvalds@...l.org,
	hch@...radead.org, rusty@...tcorp.com.au, jlo@...are.com,
	xen-devel@...ts.xensource.com, simon@...source.com,
	ian.pratt@...source.com, jeremy@...p.org
Subject: Re: A proposal - binary

On 8/4/06, Chris Wright <chrisw@...s-sol.org> wrote:
> * Antonio Vargas (windenntw@...il.com) wrote:
> > One feature I found missing at the paravirt patches is to allow the
> > user to forbid the use of paravirtualization of certain features (via
> > a bitmask on the kernel commandline for example) so that the execution
> > drops into the native hardware virtualization system. Such a feature
>
> There is no native harware virtualization system in this picture.  Maybe
> I'm just misunderstanding you.

What I was refering with "native hardware virtualization" is just the
VT or Pacitifica -provided trapping into the hypervisor upon executing
"dangerous" instructions such as tlb-flushes, reading/setting the
current ring-level, cli/sti...

> > would provide a big upwards compatibility for the kernel<->hypervisor
> > system. The case for this would be needing to forcefully upgrade the
> > hypervisor due to security issues and finding out that the hypervisor
> > is  incompatible at the paravirtualizatrion level, then the user would
> > be at least capable of continuing to run the old kernel with the new
> > hypervisor until the compatibility is reached again.
>
> This seems a bit like a trumped up example, as randomly disabling a part
> of the pv interface is likely to cause correctness issues, not just
> performance degradation.

Yes, maybe just providing a switch to force paravirtops to use the
native hardware implementation would be enough, or just in case,
making the default the native hardware and allowing the kernel
commandline to select another one (just like on io-schedulers)

> Hypervisor compatibility is a slightly separate issue here.  There's two
> interfaces.  The linux paravirt interface is internal to the kernel.
> The hypervisor interface is external to the kernel.
>
> kernel <--pv interface--> paravirt glue layer <--hv interface--> hypervisor
>
> So changes to the hypervisor must remain ABI compatible to continue
> working with the same kernel.  This is the same requirement the kernel
> has with the syscall interface it provides to userspace.

Yes. What I propose is allowing the systems to continue running (only
with degraded performance) when the hv-interface between the running
kernel and the running hypervisor doesn't match.

> > BTW, what is the recommended distro or kernel setup to help testing
> > the latest paravirt patches? I've got a spare machine (with no needed
> > data) at hand which could be put to good use.
>
> Distro of choice.  Current kernel with the pv patches[1], but be
> forewarned, they are very early, and not fully booting.

Thanks, will be setting it up :)

-- 
Greetz, Antonio Vargas aka winden of network
-
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/