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: <500E8280.6050905@parallels.com>
Date:	Tue, 24 Jul 2012 15:09:52 +0400
From:	Vladimir Davydov <vdavydov@...allels.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Andre Przywara <andre.przywara@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
	Borislav Petkov <borislav.petkov@....com>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andreas Herrmann <andreas.herrmann3@....com>
Subject: Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features

On 07/24/2012 02:10 PM, Borislav Petkov wrote:
> On Tue, Jul 24, 2012 at 12:29:19PM +0400, Vladimir Davydov wrote:
>> I guess that when the more advanced features become widely-used,
>> vendors will offer new MSRs and/or CPUID faulting.
> And this right there is the dealbreaker:
>
> So what are you doing for cpus which have the advanced CPUID features
> leafs but there are no MSRs to turn those bits off?

We have not encountered this situation in our environments and I hope we 
won't :-)

But look, these CPUID functions cover majority of CPU features, don't 
they? So, most of "normal" apps inside VM will survive migration. 
Perhaps, some low-level utils won't. I guess that's why there are no 
MSRs for other levels provided by vendors.

> You surely need some software-only solution for the migration to work,
> no?

Yes.

> If so, why not apply that solution to your hypervisor without touching
> the kernel at all?

In most hypervisor-based virtualization products, this is already 
implemented using VMM-exits, so that each VM can have arbitrary CPUID 
mask set by the admin.

The problem is that we have no hypervisor. "Virtualization" we want this 
feature for is based on cgroups and namespaces (examples are OpenVZ and 
mainstream LXC). Tasks are just grouped into virtual environments and 
share the same kernel, which is proved to be more memory usage efficient 
than traditional hypervisor-based approaches.

> Thanks.
>

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