linux-kernel - Re: [PATCH 0/4] Export offsets of VMCS fields as note information for kdump

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: <4F8EAFF7.2040505@redhat.com>
Date:	Wed, 18 Apr 2012 15:13:43 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Anthony Liguori <anthony@...emonkey.ws>
CC:	kvm@...r.kernel.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] Export offsets of VMCS fields as note information
 for kdump

On 04/17/2012 07:49 PM, Anthony Liguori wrote:
> On 04/17/2012 02:44 AM, Avi Kivity wrote:
>> On 04/11/2012 04:39 AM, zhangyanfei 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 reverse
>>> engineering it in the way implemented in this patch set. Please note
>>> that this processing never affects any existing kvm logic. The
>>> VMCSINFO is exported via sysfs to kexec-tools just like VMCOREINFO.
>>>
>>> Here is an example:
>>> Processor: Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz
>>>
>>> $cat /sys/kernel/vmcsinfo
>>> 1cba8c0 2000
>>>
>>> crash>  rd -p 1cba8c0 1000
>>>           1cba8c0:  0000127b00000009 53434d5600000000  
>>> ....{.......VMCS
>>>           1cba8d0:  000000004f464e49 4e4f495349564552  
>>> INFO....REVISION
>>>           1cba8e0:  49460a643d44495f 5f4e495028444c45  
>>> _ID=d.FIELD(PIN_
>>>           1cba8f0:  4d565f4445534142 4f435f434558455f  
>>> BASED_VM_EXEC_CO
>>>           1cba900:  303d294c4f52544e 0a30383130343831  
>>> NTROL)=01840180.
>>>           1cba910:  504328444c454946 5f44455341425f55  
>>> FIELD(CPU_BASED_
>>>           1cba920:  5f434558455f4d56 294c4f52544e4f43  
>>> VM_EXEC_CONTROL)
>>>           1cba930:  393130343931303d 28444c4549460a30  
>>> =01940190.FIELD(
>>>           1cba940:  5241444e4f434553 4558455f4d565f59  
>>> SECONDARY_VM_EXE
>>>           1cba950:  4f52544e4f435f43 30346566303d294c  
>>> C_CONTROL)=0fe40
>>>           1cba960:  4c4549460a306566 4958455f4d562844  
>>> fe0.FIELD(VM_EXI
>>>           1cba970:  4f52544e4f435f54 346531303d29534c  
>>> T_CONTROLS)=01e4
>>>           1cba980:  4549460a30653130 4e455f4d5628444c  
>>> 01e0.FIELD(VM_EN
>>>           1cba990:  544e4f435f595254 33303d29534c4f52  
>>> TRY_CONTROLS)=03
>>>           1cba9a0:  460a303133303431 45554728444c4549  
>>> 140310.FIELD(GUE
>>>           1cba9b0:  45535f53455f5453 3d29524f5443454c  
>>> ST_ES_SELECTOR)=
>>>           1cba9c0:  4549460a30303530 545345554728444c  
>>> 0500.FIELD(GUEST
>>>           1cba9d0:  454c45535f53435f 35303d29524f5443  
>>> _CS_SELECTOR)=05
>>>           ......
>>>
>>> TODO:
>>>    1. In kexec-tools, get VMCSINFO via sysfs and dump it as note
>>> information
>>>       into vmcore.
>>>    2. Dump VMCS region of each guest vcpu and VMCSINFO into
>>> qemu-process
>>>       core file. To do this, we will modify kernel core dumper, gdb
>>> gcore
>>>       and crash gcore.
>>>    3. Dump guest image from the qemu-process core file into a vmcore.
>>>
>>
>> Taking a step back, can you describe the problem scenario you're fixing
>> here?
>
> Note that assuming that VMCS fields map to offsets within memory is
> not guaranteed to work for future processors.
>
> There is no guarantee that fields won't be compressed or stored with
> inverted bit ordering.
>

Right; they're also not required to be in memory at all - the processor
can cache them, even for VMCSs that are not active at this time. 
Running VMXOFF at panic time can fix that, but you have to broadcast it
to all processors, probably using NMI...

Still, some information is better than nothing.  What I doubt is whether
that information will ever be used.

-- 
error compiling committee.c: too many arguments to function

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