Message-ID: <540693F4.8080109@suse.com>
Date:	Wed, 03 Sep 2014 06:07:16 +0200
From:	Juergen Gross <jgross@...e.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.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 09/02/2014 09:22 PM, Konrad Rzeszutek Wilk wrote:
> 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 :-)

Oh yeah. Only one or two lines missing in xl to support it. :-)

I hope to have the >500GB patch ready for testing soon. I'd prefer to
combine this and the large initrd patch in one series, as both need the
same headers to be synced with Xen. In case I'm meeting some serious
issues I'll post the large initrd patch on Friday.

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/

Powered by blists - more mailing lists