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: <20060804073754.GY2654@sequoia.sous-sol.org>
Date:	Fri, 4 Aug 2006 00:37:54 -0700
From:	Chris Wright <chrisw@...s-sol.org>
To:	Antonio Vargas <windenntw@...il.com>
Cc:	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

* Antonio Vargas (windenntw@...il.com) wrote:
> 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...

We are not talking about VMX or AMDV.  Just plain ol' x86 hardware.

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

In this case native hardware == running on bare metal w/out VMX/AMDV
support and w/out any hypervisor.  So, while this would let you actually
boot the machine, it's probably not really useful for the case you cited
(security update to hypervisor causes ABI breakage) because you'd be
booting a normal kernel w/out any virtualization.  IOW, all the virtual
machines that were running on that physical machine would not be running.

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

This is non-trivial.  If the hv-interface breaks the ABI, then you'd
need to update the pv-glue layer in the kernel.

> >> 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 :)

Thanks for helping.
-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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ