Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1742875ybh; Tue, 14 Jul 2020 06:17:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWn1mO0bxGZCRBdNlRW8FLXlkvNXTWRGc1lxzX0LJexR0RYX2su5p2wWUh7Pl2p3HIbupB X-Received: by 2002:a17:906:2988:: with SMTP id x8mr4652543eje.141.1594732661416; Tue, 14 Jul 2020 06:17:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594732661; cv=none; d=google.com; s=arc-20160816; b=PEFaj4WD5lQH4Zq6rouxAMaQVzsA4rkjADMXm/+JK0QHdKWwR37wll9wD3oZT2iaxB qGctSFbQCiEZlOqlzbyGiet3SSScCggMdgO5/z32LLJoe9QDNsKP3ithVVFiwUOMs6sA xra7fHy7U4D63sN7Oncng4ox7EODuba79DA0jdbEYnOAg5RkzMIkHtAmEvXIJ7qUvvvU ByIzrEX1belMo4R5NwNsg7qX8xakaTQLK5Q5esiz+C06zzcJQ1NM1dqW1m2Rpe1s2u2x nsQhxELjditW52Pi0rKCzSzHUp5p27YTSiK9Mz3GDxelbOrdoVO9HeJV+3nYx/Liyv52 zTbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=JcppHeuWEWp3uvCgDjwRJ0BnWulErceTXsEzD39nLZE=; b=cDLZPfL4KCBrM3UWjvFYvqaRyH/S3Z05u2x1n+tIcl9bp+W0Wdomw/8y1konfJ66KH RGUFldhnAmJsc/EDEsBQgcWCuvYm4VrWqGDEy0j8+aH66/PkmB1vvcL1VKZzYEniAeLo um4h8K58SlFfFvubclFO6YJT5nxRssbuyvdbAWbrwpi2N4OM15DkLKT9dS638QfCAJJT qj5NuOf8nXennBRWBybNsro6zQ9gze0rHuhBElNS3PNuO7wSHaHReTZuW+LIac7z70Rm iY13w1Mfe/CnTrIVLqNIzNvAOyOGCqoJuIvoeoHYTY8SddEAOHuYnH6q1qV4AYOOfKUT gASg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=c9vLiUrX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n8si11148736edi.222.2020.07.14.06.17.16; Tue, 14 Jul 2020 06:17:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=c9vLiUrX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728439AbgGNNQC (ORCPT + 99 others); Tue, 14 Jul 2020 09:16:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728294AbgGNNQC (ORCPT ); Tue, 14 Jul 2020 09:16:02 -0400 Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1B10C061755 for ; Tue, 14 Jul 2020 06:16:01 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id x9so14153784ila.3 for ; Tue, 14 Jul 2020 06:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=JcppHeuWEWp3uvCgDjwRJ0BnWulErceTXsEzD39nLZE=; b=c9vLiUrXUAWYv0FD++CVcZ1GAtiNRR7bSHgIM7lL4DbuHgbfcYJwnwva+prRCHC65Y Dyw+53n4/f1kNq8EV3G1kxBEiIT1XbIqlJocKGSnBuCUWTMNA2WSoNTbhCSMl8uc/D1D BiSJlZeQv/ehgMADDdypZGP03dImnwVce3FEViVstfWvv84nqiRQU+cP00vb3Rvi1Myv MFvoD01u2DejPmmU4TOnk0fZsAqwQaeY6cjz/iagEODUQdB/1ZbIti/V41Imti4ecgUc oE5GJXi2VYIpMEGSCgyW5H5wjgRCfpz7+lNGMSdG5y5EPFzTBOqCzDfxmhAZR1SLHjpn fxug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=JcppHeuWEWp3uvCgDjwRJ0BnWulErceTXsEzD39nLZE=; b=rBdlFGVwPBiU4vM6zQOD4ogEvO27QZgYKLTyYCPLqzdwcRrieWJuavF+n35e0Fmvrx LbMmMifpR5voshn/ahwvxMH9+Tv1puUt98ZaiJJ6yGNzXeNYuJsnun5QDDFAT8+DFm56 j2I5GX+03p/it0pZz4C0laAaA/La+F/Qbh89C/lPrxx1xVFYL7s85lFXhKdG0m0OagYJ yNcpuFMQmRfkngj2DCNxiQh5tnIDYvXeclUsFU+QsxAseqvX8y97ONMPaNUhQHW++vIr 2TA/+LfWR6DHMA9Sca3nXmF+NjQWoyAtVNdhJGZfkOyprVwAbQ7whdmAmKTDitb/SDnM w1Wg== X-Gm-Message-State: AOAM531YX2Mr7RkF2R4/0CAvFxXcB3vacteNt35Cqyw9yRRsRXSJk6mP R1ADB2Y0BGY+FNnZJMMhVKKzvI9MthS7haAvdUM= X-Received: by 2002:a92:dc09:: with SMTP id t9mr4830937iln.226.1594732561149; Tue, 14 Jul 2020 06:16:01 -0700 (PDT) MIME-Version: 1.0 References: <20200629140928.858507-1-nivedita@alum.mit.edu> <20200714023836.2310569-1-nivedita@alum.mit.edu> In-Reply-To: <20200714023836.2310569-1-nivedita@alum.mit.edu> Reply-To: sedat.dilek@gmail.com From: Sedat Dilek Date: Tue, 14 Jul 2020 15:15:49 +0200 Message-ID: Subject: Re: [PATCH v4 0/7] x86/boot: Remove runtime relocations from compressed kernel To: Arvind Sankar Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, Nick Desaulniers , Fangrui Song , Dmitry Golovin , Clang-Built-Linux ML , Ard Biesheuvel , Masahiro Yamada , Daniel Kiper , Kees Cook , Nathan Chancellor , Arnd Bergmann , "H . J . Lu" , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 14, 2020 at 4:38 AM Arvind Sankar wrote: > > The compressed kernel currently contains bogus runtime relocations in > the startup code in head_{32,64}.S, which are generated by the linker, > but must not actually be processed at runtime. > > This generates warnings when linking with the BFD linker, and errors > with LLD, which defaults to erroring on runtime relocations in read-only > sections. It also requires the -z noreloc-overflow hack for the 64-bit > kernel, which prevents us from linking it as -pie on an older BFD linker > (<= 2.26) or on LLD, because the locations that are to be apparently > relocated are only 32-bits in size and so cannot really have > R_X86_64_RELATIVE relocations. > > This series aims to get rid of these relocations. I've build- and > boot-tested with combinations of clang/gcc-10 with lld/bfd-2.34, and > gcc-4.9.0 with bfd-2.24, skipping clang on 32-bit because it currently > has other issues [0]. > > The first three patches by Ard remove indirection via the GOT from the > compressed kernel code. > > The next patch is an independent fix for LLD, to avoid an orphan > section in arch/x86/boot/setup.elf. > > The fifth patch gets rid of almost all the relocations. It uses > standard PIC addressing technique for 32-bit, i.e. loading a register > with the address of _GLOBAL_OFFSET_TABLE_ and then using GOTOFF > references to access variables. For 64-bit, there is 32-bit code that > cannot use RIP-relative addressing, and also cannot use the 32-bit > method, since GOTOFF references are 64-bit only. This is instead handled > using a macro to replace a reference like gdt with (gdt-startup_32) > instead. The assembler will generate a PC32 relocation entry, with > addend set to (.-startup_32), and these will be replaced with constants > at link time. This works as long as all the code using such references > lives in the same section as startup_32, i.e. in .head.text. > > The sixth patch addresses a remaining issue with the BFD linker, which > generates runtime relocations for absolute symbols. We use z_input_len > and z_output_len, defined in the generated piggy.S file, as symbols > whose absolute "addresses" are actually the size of the compressed > payload and the size of the decompressed kernel image respectively. LLD > does not generate relocations for these two symbols, but the BFD linker > does, prior to the upcoming 2.35. To get around this, piggy.S is > extended to also define two u32 variables (in .rodata) with the lengths, > and the head code is modified to use those instead of the symbol > addresses. > > An alternative way to handle z_input_len/z_output_len would be to just > include piggy.S in head_{32,64}.S instead of as a separate object file, > since the GNU assembler doesn't generate relocations for symbols set to > constants. > > The last patch adds a check in the linker script to ensure that no > runtime relocations get reintroduced. > > [0] https://lore.kernel.org/lkml/20200504230309.237398-1-ndesaulniers@google.com/ > How to test this series without building a full new kernel? make $make_opts vmlinux - Sedat - > Changes from v3: > - Move hidden.h to include/linux so the EFI stub and the compressed > kernel can share the same file > > Changes from v2: > - Incorporate Ard's patches for eliminating GOT references into this > series > - Rebase on v5.8-rc3 > > v2: https://lore.kernel.org/lkml/20200525225918.1624470-1-nivedita@alum.mit.edu/ > > Changes from v1: > - Add .text.* to setup.ld instead of just .text.startup > - Rename the la() macro introduced in the second patch for 64-bit to > rva(), and rework the explanatory comment. > - In the last patch, check both .rel.dyn and .rela.dyn, instead of just > one per arch. > > > Ard Biesheuvel (3): > x86/boot/compressed: Move .got.plt entries out of the .got section > x86/boot/compressed: Force hidden visibility for all symbol references > x86/boot/compressed: Get rid of GOT fixup code > > Arvind Sankar (4): > x86/boot: Add .text.* to setup.ld > x86/boot: Remove run-time relocations from .head.text code > x86/boot: Remove runtime relocations from head_{32,64}.S > x86/boot: Check that there are no runtime relocations > > arch/x86/boot/compressed/Makefile | 37 +----- > arch/x86/boot/compressed/head_32.S | 99 +++++---------- > arch/x86/boot/compressed/head_64.S | 165 ++++++++++--------------- > arch/x86/boot/compressed/mkpiggy.c | 6 + > arch/x86/boot/compressed/vmlinux.lds.S | 24 +++- > arch/x86/boot/setup.ld | 2 +- > drivers/firmware/efi/libstub/Makefile | 2 +- > drivers/firmware/efi/libstub/hidden.h | 6 - > include/linux/hidden.h | 19 +++ > 9 files changed, 152 insertions(+), 208 deletions(-) > delete mode 100644 drivers/firmware/efi/libstub/hidden.h > create mode 100644 include/linux/hidden.h > > > base-commit: 11ba468877bb23f28956a35e896356252d63c983 > -- > 2.26.2 >