lkml.org 
[lkml]   [2017]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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@shutemov.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

    \
     
     \ /
      Last update: 2017-04-18 13:10    [W:3.469 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site