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]
Date:	Fri, 11 Jan 2013 14:36:51 +0100
From:	Daniel Kiper <daniel.kiper@...cle.com>
To:	David Vrabel <david.vrabel@...rix.com>
Cc:	Jan Beulich <JBeulich@...e.com>, hpa@...or.com,
	konrad.wilk@...cle.com, andrew.cooper3@...rix.com, x86@...nel.org,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	xen-devel <xen-devel@...ts.xen.org>, mingo@...hat.com,
	ebiederm@...ssion.com, maxim.uvarov@...cle.com, tglx@...utronix.de,
	virtualization@...ts.linux-foundation.org, vgoyal@...hat.com
Subject: Re: [Xen-devel] [PATCH v3 02/11] x86/kexec: Add extra pointers to
 transition page table PGD, PUD, PMD and PTE

On Thu, Jan 10, 2013 at 02:07:31PM +0000, David Vrabel wrote:
> On 04/01/13 15:15, Daniel Kiper wrote:
> > On Thu, Jan 03, 2013 at 09:34:55AM +0000, Jan Beulich wrote:
> >>>>> On 27.12.12 at 03:18, Daniel Kiper <daniel.kiper@...cle.com> wrote:
> >>> Some implementations (e.g. Xen PVOPS) could not use part of identity page table
> >>> to construct transition page table. It means that they require separate PUDs,
> >>> PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that
> >>> requirement add extra pointer to PGD, PUD, PMD and PTE and align existing
> >>> code.
> >>
> >> So you keep posting this despite it having got pointed out on each
> >> earlier submission that this is unnecessary, proven by the fact that
> >> the non-pvops Xen kernels can get away without it. Why?
> >
> > Sorry but I forgot to reply for your email last time.
> >
> > I am still not convinced. I have tested SUSE kernel itself and it does not work.
> > Maybe I missed something but... Please check arch/x86/kernel/machine_kexec_64.c:init_transition_pgtable()
> >
> > I can see:
> >
> > vaddr = (unsigned long)relocate_kernel;
> >
> > and later:
> >
> > pgd += pgd_index(vaddr);
> > ...
> >
> > It is wrong. relocate_kernel() virtual address in Xen is different
> > than its virtual address in Linux Kernel. That is why transition
> > page table could not be established in Linux Kernel and so on...
> > How does this work in SUSE? I do not have an idea.
>
> The real problem here is attempting to transition from the Xen page
> tables to an identity mapping set of page tables by using some
> trampoline code and page tables provided by the dom0 kernel.
>
> This works[*] with PV because the page tables from the PV dom0 have
> machine addresses and get mapped into the fixmap on kexec load, but it's
> completely broken for a PVH dom0.
>
> I shall be ditching this (bizarre) method and putting the trampoline and
> transition/identity map page tables into Xen.

Great... Maybe I am boring but please look into
linux/arch/x86/kernel/{machine_kexec_$(BITS).c,relocate_kernel_$(BITS).c}
You could find there a lot of things which could be useful.

> David
>
> [*] Works for us in our old classic kernels, YMMV.

Ha... It works because virtual mapping of control page in transtition page table
is established in relocate_kernel() which sits during kexec/kdump execution
in control page. If you did not change something...

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