qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/21] WIP: dump: add kaslr support (for after 2


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 00/21] WIP: dump: add kaslr support (for after 2.9)
Date: Wed, 5 Apr 2017 18:01:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0


On 11/03/2017 15:31, Dave Anderson wrote:
> ----- Original Message -----
>> Hi,
>>
>> Latest linux kernel enabled kaslr to randomize phys/virt memory
>> addresses. There has been some effort to support kexec/kdump so that
>> crash utility can still works in case crashed kernel has kaslr
>> enabled.
>>
>> This series aims to provide enough information in qemu dumps so that
>> crash utility can work with kaslr kernel too, with x86_64 guests (it
>> hasn't been tested on other archs, help welcome).
>>
>> Two pieces of informations are necessary: the phys_base (the physical
>> address where the kernel is loaded) and the kaslr offset. Other useful
>> informations for debugging are provided in Linux vmcoreinfo too.
>>
>> There has been discussions to provide those details in early boot,
>> with ACPI, fw_cfg, virtio-pstore etc, but none has reached a consensus
>> yet. A possiblity for now is to provide the information when qemu-ga
>> starts. This has the advantage of working with older guests and may
>> not be incompatible with future methods (in this case it could ignore
>> qga info for example). The drawback is that qemu will have to parse
>> the json stream. For now it stops processing it whem VMDUMP_INFO is
>> received. It would be wise to introduce a QMP welcome message, so that
>> qemu would stop immediately processing the stream if the agent doesn't
>> have the event. Another option is to create a seperate channel...
>> I welcome other ideas and discussion.
>>
>> crash upstream doesn't yet parse NUMBER(phys_base). You may pass it to
>> crash with --machdep phys_base=0x.. provided you snooped on qga.
> 
> FYI: a patch to utilize NUMBER(phys_base) has been checked in upstream:
> 
>   
> https://github.com/crash-utility/crash/commit/ed60e97e319a1cfc9e2779aa1baac305677393d8
> 
>   Linux 4.10 commit 401721ecd1dcb0a428aa5d6832ee05ffbdbffbbe finally
>   exports the x86_64 "phys_base" value in the VMCOREINFO note, so
>   utilize it whenever it exists.
>   (address@hidden)

Marc-André, what is the plan here?  Do we still need it (maybe for Windows)?

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]