Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2847939ybv; Mon, 24 Feb 2020 12:51:49 -0800 (PST) X-Google-Smtp-Source: APXvYqyPRtsSAbLE8pL/6dq5kUCQpr++5ViKShI0GBb5Vo5vENqoAF005br3PoN9RuHIEvIWwrJL X-Received: by 2002:aca:2207:: with SMTP id b7mr752845oic.109.1582577509047; Mon, 24 Feb 2020 12:51:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582577509; cv=none; d=google.com; s=arc-20160816; b=MslI3rc2vExcs2g8rdoWGIenONU0tzxiQ2DOKZdRG0R+svK+Oaun6g2LBrk29wHf1k lGjd9NaeprZSUQln8STluyPTpFZaPp5KR/olmbYhHlp95YGxuBgETDnHXnaXdocw2/kO J9x47z4FbF/uwVDfZDaXM+FAEwScSeuYaoAyOZ3cbRfjfi+MfRuPwS5G6hHivR6EvByg fPXsa0PHEd/qWtoZtTndu6/2tljSE69rIZacqDKjnQ8M2kKXWg17TYItTc3sbww+0J8f kU7ZNJHpqzg5jhRDfX/UhX5yiP+ra2dL0jaqwU6nYjHKQnnP/YtWVF8tfcXNZz3qKbEc bZvw== 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 :in-reply-to:references:mime-version:dkim-signature; bh=jRq4pHDxuVRc7aayKg6MpqkDQ8S3ZSOkFs6fEcDKK0o=; b=fpTWZT9tWuCe6qKq7BfQ+DJmD04/T/fYrbauqCQayRJQ+hN/7/nkyreRwgTCvl3au3 JuZ+LZspdHjMjhHxtJuQ+Na3HoTzin4ZKPigqKj/TFgWZR5inDlG3/wQ+G+n+Z5uRR3D tvVmuzf4eWePZXmYHgf1YrDu6oNDPcPAY/lKKzPq/baenkVjklEiShnFQqH33DrVwBMf yjSTHeIDNEtokq9Rngf+yVI1huktRP/gjuR+vJxlu5V+h4rEb1/rxhSmV9aviw+ahYL3 TUNoqSW5ssXt69YqOxMK2TiudhxIffCbUQUjaJHtxRAY8zDd1jO44fLdswSQhNA+Gyps 3LeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="IU480/eX"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q9si5738647oif.92.2020.02.24.12.51.36; Mon, 24 Feb 2020 12:51:49 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="IU480/eX"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727479AbgBXUv0 (ORCPT + 99 others); Mon, 24 Feb 2020 15:51:26 -0500 Received: from mail-pf1-f194.google.com ([209.85.210.194]:37234 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726722AbgBXUv0 (ORCPT ); Mon, 24 Feb 2020 15:51:26 -0500 Received: by mail-pf1-f194.google.com with SMTP id p14so5963649pfn.4 for ; Mon, 24 Feb 2020 12:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jRq4pHDxuVRc7aayKg6MpqkDQ8S3ZSOkFs6fEcDKK0o=; b=IU480/eXPWvhS9EHPf7MNW016x1zh5V4dxlrK8iAuDS26pQgW2+UqLW1Iyqm14qYRQ auJIu2WCWHmhrMXju0bfXnQlEt1DEJmLhG4OHAoYBi88S+AYEb3VEuqq8cE8Iti2Ngvx eGSKwSvng+3K1RVSXF0KXiERYYT12TETUB1Kq5t4kgGNtj5Vop7sCuy+OkW0TDQHwIeU AhHy12YQX/A55dkFcAv2vH0UG3JM3unTcU4ofWodum/YvywpKaTa/rYJLHP/wy4fqEXJ NJrunc/YeqjOveUVA2xBXdRCI4HOgu9nFXDDhScbLqFyg3VwOo3pBOn8Y0AKPfNaODgX kVSA== 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:from:date :message-id:subject:to:cc; bh=jRq4pHDxuVRc7aayKg6MpqkDQ8S3ZSOkFs6fEcDKK0o=; b=Vai0vjPH0Zvp923lV6Styx0gJdLMRlbyShVGvjyIx+aZSm8L0NzXEgk/PR9gJOGYEv ou/cg/HQnSo4XrpYp4sxe+pwzl+kjBQ33oOtLvXKp1ciQVf5ztVK1yQmEEglihNkbDvR DAC2wpsE5+AqfK965Ui7d0imLPeD63zgAj5fJah22GKP6CwdNEm0t3UJJVUoBdZU4C0n sux5/EbuVHhgawEWyTV7dixLRoICv98OcmJXMPNAYK+JMPNk07LxXWFu0xMUJlWLZLqA 07x+y37W4TKDeeRcAwDxhTxYRyjiK853ISR3otTnwYi1MsTASuU8CQZj05shIdSPBi2S ymPw== X-Gm-Message-State: APjAAAUEtzSJEoZQszDo6xO/Ae4VqjQax8lJ9HMN4d7oUeU4zh79ZA2w DoZI/s73B1covFo+Sbes3AU18VuGw5lpAGzFVD+9fg== X-Received: by 2002:a63:4e22:: with SMTP id c34mr18743179pgb.263.1582577485165; Mon, 24 Feb 2020 12:51:25 -0800 (PST) MIME-Version: 1.0 References: <20200109150218.16544-1-nivedita@alum.mit.edu> <20200109150218.16544-2-nivedita@alum.mit.edu> <20200222050845.GA19912@ubuntu-m2-xlarge-x86> <20200222065521.GA11284@zn.tnic> <20200222070218.GA27571@ubuntu-m2-xlarge-x86> <20200222072144.asqaxlv364s6ezbv@google.com> <20200222074254.GB11284@zn.tnic> <20200222162225.GA3326744@rani.riverdale.lan> In-Reply-To: From: Nick Desaulniers Date: Mon, 24 Feb 2020 12:51:14 -0800 Message-ID: Subject: Re: [PATCH 2/2] x86/boot/compressed: Remove unnecessary sections from bzImage To: Michael Matz Cc: Arvind Sankar , Fangrui Song , Borislav Petkov , Nathan Chancellor , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , LKML , clang-built-linux , Kees Cook 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 Mon, Feb 24, 2020 at 5:28 AM Michael Matz wrote: > > Hello, > > On Sat, 22 Feb 2020, Nick Desaulniers wrote: > > > > > > In GNU ld, it seems that .shstrtab .symtab and .strtab are special > > > > > cased. Neither the input section description *(.shstrtab) nor *(*) > > > > > discards .shstrtab . I feel that this is a weird case (probably even a bug) > > > > > that lld should not implement. > > > > > > > > Ok, forget what the tools do for a second: why is .shstrtab special and > > > > why would one want to keep it? > > > > > > > > Because one still wants to know what the section names of an object are > > > > or other tools need it or why? > > > > > > > > Thx. > > > > > > > > -- > > > > Regards/Gruss, > > > > Boris. > > > > > > > > https://people.kernel.org/tglx/notes-about-netiquette > > > > > > .shstrtab is required by the ELF specification. The e_shstrndx field in > > > the ELF header is the index of .shstrtab, and each section in the > > > section table is required to have an sh_name that points into the > > > .shstrtab. > > > > Yeah, I can see it both ways. That `*` doesn't glob all remaining > > sections is surprising to me, but bfd seems to be "extra helpful" in > > not discarding sections that are required via ELF spec. > > In a way the /DISCARD/ assignment should be thought of as applying to > _input_ sections (as all such section references on the RHS), not > necessarily to output sections. What this then means for sections that > are synthesized by the link editor is less clear. Some of them are > generated regardless (as you noted, e.g. the symbol table and associated > string sections, including section name string table), some of them are > suppressed, and either lead to an followup error (e.g. with .gnu.hash), or > to invalid output (e.g. missing .dynsym for executables simply lead to > segfaults when running them). > > That's the reason for the perceived inconsistency with behaviour on '*': > it's application to synthesized sections. Arguably bfd should be fixed to > also not discard the other essential sections (or alternatively to give an > error when an essential section is discarded). The lld behaviour of e.g. > discarding .shstrtab (or other synthesized sections necessary for valid > ELF output) doesn't make much sense either, though. Hi Michael, thank you for the precise feedback. Do you have a list of "synthesized sections necessary for valid ELF output?" Also, could you point me to the documentation about `*` and its relation to "synthesized sections necessary for valid ELF output?" This will help me file a precise bug against LLD. -- Thanks, ~Nick Desaulniers