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: <4FBB0DB7.3040909@cn.fujitsu.com>
Date:	Tue, 22 May 2012 11:53:27 +0800
From:	Yanfei Zhang <zhangyanfei@...fujitsu.com>
To:	Eric Northup <digitaleric@...gle.com>
CC:	Avi Kivity <avi@...hat.com>, mtosatti@...hat.com,
	ebiederm@...ssion.com, luto@....edu,
	Joerg Roedel <joerg.roedel@....com>, dzickus@...hat.com,
	paul.gortmaker@...driver.com, ludwig.nussel@...e.de,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	kexec@...ts.infradead.org, Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information
 for kdump

于 2012年05月22日 02:58, Eric Northup 写道:
> On Wed, May 16, 2012 at 12:50 AM, zhangyanfei
> <zhangyanfei@...fujitsu.com> wrote:
>>
>> This patch set exports offsets of VMCS fields as note information for
>> kdump. We call it VMCSINFO. The purpose of VMCSINFO is to retrieve
>> runtime state of guest machine image, such as registers, in host
>> machine's crash dump as VMCS format. The problem is that VMCS internal
>> is hidden by Intel in its specification. So, we slove this problem
>> by reverse engineering implemented in this patch set. The VMCSINFO
>> is exported via sysfs to kexec-tools just like VMCOREINFO.
> 
> Perhaps I'm wrong, but this solution seems much, much more dynamic
> than it needs to be.
> 
> The VMCS offsets aren't going to change between different boots on the
> same CPU, unless perhaps the microcode has been updated.
> 
> So you can have the VMCS offset dumping be a manually-loaded module.
> Build a database mapping from (CPUID, microcode revision) -> (VMCSINFO).
> There's no need for anything beyond the (CPUID, microcode revision) to
> be put in the kdump, since your offline processing of a kdump can then
> look up the rest.
> 
> It means you don't have to interact with the vmx module at all, and
> no extra modules or code have to be loaded on the millions of Linux
> machines that won't need the functionality.
> 

We have considered this way, but there are two issues:
1) vmx resource is unique for a single cpu, and it's risky to grab it forcibly
on the environment where kvm module is used, in particular on customer's environment.
To do this safely, kvm support is needed.

2) It highly costs to prepare each cpu to each customer environment to collect
vmcsinfo. After all, there are various environments on our customer's.

Our patch provides a module, so those who doesn't want this feature can just
stop it being auto-loaded when system starts up.

Thanks
Zhang Yanfei

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