[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170418111030.5zc4zhxlrbpi4bwm@node.shutemov.name>
Date: Tue, 18 Apr 2017 14:10:31 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andi Kleen <ak@...ux.intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andy Lutomirski <luto@...capital.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Dave Hansen <dave.hansen@...el.com>,
linux-arch@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/8] x86/boot/64: Add support of additional page table
level during early boot
On Tue, Apr 18, 2017 at 01:15:34PM +0300, Kirill A. Shutemov wrote:
> On Tue, Apr 18, 2017 at 11:59:26AM +0300, Kirill A. Shutemov wrote:
> > On Mon, Apr 17, 2017 at 12:32:25PM +0200, Ingo Molnar wrote:
> > >
> > > * Kirill A. Shutemov <kirill@...temov.name> wrote:
> > >
> > > > On Tue, Apr 11, 2017 at 07:09:07AM -0700, Andi Kleen wrote:
> > > > > > I'll look closer (building proccess it's rather complicated), but my
> > > > > > understanding is that VDSO is stand-alone binary and doesn't really links
> > > > > > with the rest of the kernel, rather included as blob, no?
> > > > > >
> > > > > > Andy, may be you have an idea?
> > > > >
> > > > > There isn't any way I know of to directly link them together. The ELF
> > > > > format wasn't designed for that. You would need to merge blobs and then use
> > > > > manual jump vectors, like the 16bit startup code does. It would be likely
> > > > > complicated and ugly.
> > > >
> > > > Ingo, can we proceed without coverting this assembly to C?
> > > >
> > > > I'm committed to convert it to C later if we'll find reasonable solution
> > > > to the issue.
> > >
> > > So one way to do it would be to build it standalone as a .o, then add it not to
> > > the regular kernel objects link target (as you found out it's not possible to link
> > > 32-bit and 64-bit objects), but to link it in a manual fashion, as part of
> > > vmlinux.bin.all-y in arch/x86/boot/compressed/Makefile.
> > >
> > > But there would be other complications with this approach, such as we'd have to
> > > add a size field and there might be symbol linking problems ...
> > >
> > > Another, pretty hacky way would be to generate a .S from the .c, then post-process
> > > the .S and essentially generate today's 32-bit .S from it.
> > >
> > > Probably not worth the trouble.
> >
> > So, do I need to do anything else to get part 4 applied?
>
> Doh!
>
> I've just realized we don't really need to enable 5-level paging in
> decompression code. Leaving 4-level paging there works perfectly fine.
>
> I'll drop changes to arch/x86/boot/compressed/head_64.S and resubmit the
> patchset.
No. This breaks KASLR. Decompression code has to use 5-level paging to
keep KASLR working.
So, v4 of part 4 is up-to-date.
Sorry for noise.
--
Kirill A. Shutemov
Powered by blists - more mailing lists