linux-kernel - Re: [Xen-devel] [PATCH] xen: Add support for dom0 with Linux kernel 3.19 and newer

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] [day] [month] [year] [list]

Message-ID: <20160122142206.GZ3485@olila.local.net-space.pl>
Date:	Fri, 22 Jan 2016 15:22:06 +0100
From:	Daniel Kiper <daniel.kiper@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>
Cc:	crash-utility@...hat.com, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org,
	jgross@...e.com, olaf@...fle.de, keir@....org,
	andrew.cooper3@...rix.com, ptesarik@...e.cz, dslutz@...izon.com,
	anderson@...hat.com, dmair@...e.com, boris.ostrovsky@...cle.com
Subject: Re: [Xen-devel] [PATCH] xen: Add support for dom0 with Linux kernel
 3.19 and newer

On Fri, Jan 22, 2016 at 10:03:34AM +0000, David Vrabel wrote:
> On 21/01/16 20:13, Daniel Kiper wrote:
> > Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8
> > (xen: switch to linear virtual mapped sparse p2m list), which
> > appeared in 3.19, introduced linear virtual mapped sparse p2m
> > list. If readmem() reads p2m then it access this list using
> > physical addresses. Sadly, VMA to physical address translation
> > in crash requires access to p2m list. This means that we have
> > a chicken and egg problem. In general this issue must be solved
> > by introducing some changes in libxl, Linux kernel and crash
> > (I have added this task to my long TODO list). However, in dom0
> > case we can use crash_xen_info_t.dom0_pfn_to_mfn_frame_list_list
> > which is available out of the box. So, let's use it and make
> > at least some users happy.
>
> I'm confused.  How does a virtual address to (pseudo-)physical address
> lookup require access to the p2m?  Surely this is a walk of the page
> tables followed by a M2P lookup on the MFN in the L1 PTE?

Correct but crash does it a bit backward and scans p2m. I am not sure way,
however, I am going to look at it during work on PV guests support.

Daniel