linux-kernel - Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

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:	Tue, 2 Sep 2014 15:22:04 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Juergen Gross <jgross@...e.com>
Cc:	Jan Beulich <JBeulich@...e.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Kees Cook <keescook@...omium.org>,
	Stefan Bader <stefan.bader@...onical.com>,
	David Vrabel <david.vrabel@...rix.com>
Subject: Re: [Xen-devel] [PATCH] Solved the Xen PV/KASLR riddle

On Mon, Sep 01, 2014 at 06:03:06AM +0200, Juergen Gross wrote:
> On 08/29/2014 04:55 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Aug 29, 2014 at 03:44:06PM +0100, Jan Beulich wrote:
> >>>>>On 29.08.14 at 16:27, <stefan.bader@...onical.com> wrote:
> >>>Sure. Btw, someone also contacted me saying they have the same problem
> >>>without
> >>>changing the layout but having really big initrd (500M). While that feels
> >>>like
> >>>it should be impossible (if the kernel+initrd+xen stuff has to fix the 512M
> >>>kernel image size area then). But if it can happen, then surely it does
> >>>cause
> >>>mappings to be where the module space starts then.
> >>
> >>Since the initrd doesn't really need to be mapped into the (limited)
> >>virtual address space a pv guest starts with, we specifically got
> >>
> >>/*
> >>  * Whether or not the guest can deal with being passed an initrd not
> >>  * mapped through its initial page tables.
> >>  */
> >>#define XEN_ELFNOTE_MOD_START_PFN 16
> >>
> >>to deal with that situation. The hypervisor side for Dom0 is in place,
> >>and the kernel side works in our (classic) kernels. Whether it got
> >>implemented for DomU meanwhile I don't know; I'm pretty certain
> >>pv-ops kernels don't support it so far.
> >
> >Correct - Not implemented. Here is what I had mentioned in the past:
> >(see http://lists.xen.org/archives/html/xen-devel/2014-03/msg00580.html)
> >
> >
> >XEN_ELFNOTE_INIT_P2M, XEN_ELFNOTE_MOD_START_PFN - I had been looking
> >     at that but I can't figure out a nice way of implementing this
> >     without the usage of SPARSEMAP_VMAP virtual addresses - which is how
> >     the classic Xen does it. But then - I don't know who is using huge PV
> >     guests - as the PVHVM does a fine job? But then with PVH, now you can
> >     boot with large amount of memory (1TB?) - so some of these issues
> >     would go away? Except the 'large ramdisk' as that would eat in the
> >     MODULES_VADDR I think? Needs more thinking.
> >
> >.. and then I left it and to my suprise saw on Luis's slides that
> >Jurgen is going to take a look at that (500GB support).
> 
> I have a patch which should do the job. It is based on the classic
> kernel patch Jan mentioned above. The system is coming up with it, I
> haven't tested it with a huge initrd up to now. My plan was to post the
> patch together with the rest of the >500GB support, but I can send it
> on it's own if required.

Oooh goodies! I think it makes sense to post it whenever you think
it is in the right state to be posted.

Now that your pvSCSI drivers are in, you have tons of free time
I suspect :-)


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