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
| ||
|
Date: Fri, 29 Aug 2014 15:43:43 +0100 From: Andrew Cooper <andrew.cooper3@...rix.com> To: Stefan Bader <stefan.bader@...onical.com>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>, Kees Cook <keescook@...omium.org>, David Vrabel <david.vrabel@...rix.com> Subject: Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle On 29/08/14 15:32, Stefan Bader wrote: > On 29.08.2014 16:19, Andrew Cooper wrote: >> On 29/08/14 09:37, Stefan Bader wrote: >>> On 29.08.2014 00:42, Andrew Cooper wrote: >>>> On 28/08/2014 19:01, Stefan Bader wrote: >>>>>>> So not much further... but then I think I know what I do next. Probably should >>>>>>> have done before. I'll replace the WARN_ON in vmalloc that triggers by a panic >>>>>>> and at least get a crash dump of that situation when it occurs. Then I can dig >>>>>>> in there with crash (really should have thought of that before)... >>>>>> <nods> I dug a bit in the code (arch/x86/xen/mmu.c) but there is nothing there >>>>>> that screams at me, so I fear I will have to wait until you get the crash >>>>>> and get some clues from that. >>>>> Ok, what a journey. So after long hours of painful staring at the code... >>>>> (and btw, if someone could tell me how the heck one can do a mfn_to_pfn >>>>> in crash, I really would appreaciate :-P) >>>> The M2P map lives in the Xen reserved virtual address space in each PV >>>> guest, and forms part of the PV ABI. It is mapped read-only, in the >>>> native width of the guest. >>>> >>>> 32bit PV (PAE) at 0xF5800000 >>>> 64bit PV at 0xFFFF800000000000 >>>> >>>> This is represented by the MACH2PHYS_VIRT_START symbol from the Xen >>>> public header files. You should be able to blindly construct a pointer >>>> to it (if you have nothing better to hand), as it will be hooked into >>>> the guests pagetables before execution starts. Therefore, >>>> "MACH2PHYS_VIRT_START[(unsigned long)pfn]" ought to do in a pinch. >>> machine_to_phys_mapping is set to that address but its not mapped inside the >>> crash dump. Somehow vtop in crash handles translations. I need to have a look at >>> their code, I guess. >>> >>> Thanks, >>> Stefan >> What context is the crash dump? If it is a Xen+dom0 kexec()d to native >> linux, then the m2p should still be accessible given dom0's cr3. If it >> is some state copied off-host then you will need to adjust the copy to >> include that virtual range. > No its a domU dump of a PV guest taken with "xl dump-core" (or actually the > result of on-crash trigger). Ah - I believe the m2p lives in one of the Xen elf notes for a domain coredump. See what readelf -n shows. ~Andrew -- 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