Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 6 Feb 2020 03:18:38 -0800
From:   Kees Cook <keescook@chromium.org>
To:     Arvind Sankar <nivedita@alum.mit.edu>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] x86/boot/compressed/64: Remove .bss/.pgtable from
 bzImage
Message-ID: <202002060316.A0027DEB@keescook>
References: <20200109150218.16544-1-nivedita@alum.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200109150218.16544-1-nivedita@alum.mit.edu>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jan 09, 2020 at 10:02:17AM -0500, Arvind Sankar wrote:
> Commit 5b11f1cee579 ("x86, boot: straighten out ranges to copy/zero in
> compressed/head*.S") introduced a separate .pgtable section, splitting
> it out from the rest of .bss. This section was added without the
> writeable flag, marking it as read-only. This results in the linker
> putting the .rela.dyn section (containing bogus dynamic relocations from
> head_64.o) after the .bss and .pgtable sections.

Thank you! As you know from the fg-kaslr thread[1], I ran into this (10
year old!) bug while helping there. I could not figure out why .bss was
getting allocated into the on-disk image.

> When we use objcopy to convert compressed/vmlinux into a binary for the
> bzImage, the .bss and .pgtable sections get materialized as ~176KiB of
> zero bytes in the binary in order to place .rela.dyn at the correct
> location.
> 
> Fix this by marking .pgtable as writeable. This moves the .rela.dyn
> section earlier so that .bss and .pgtable are the last allocated
> sections and so don't appear in bzImage.
> 
> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

[1] https://lore.kernel.org/lkml/202002060251.681292DE63@keescook/

-- 
Kees Cook