Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp790335ybv; Sat, 22 Feb 2020 15:21:12 -0800 (PST) X-Google-Smtp-Source: APXvYqxI0mFaMfbyZLE3zDGNoAdUmUWLDhDc9tI/1jxAGmw19Hyr0vt3K3wwG7CddgSHGhGxkAzh X-Received: by 2002:a05:6830:1e2b:: with SMTP id t11mr34825457otr.81.1582413672617; Sat, 22 Feb 2020 15:21:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582413672; cv=none; d=google.com; s=arc-20160816; b=AQpl3NJp7OXbNyoaRpr9bpuNVXljl1s1839MYnhzM+oYUIM3OimwlQzY8f3hcH/mQe rkFFWb7inaxmKuxjrIoq8qBeEF6ZwsvWUid8vSBXEN5S8uxWFqzpaFQg2SWEI93CgKbI R1009BsMgNs2TxiDr4Go2EL4x0YcdQpTpgPPpGUe8vvS0goJM876GKVGDjwEshSGTkFZ reVNlbzfmfM+ZSaz4cqezzDZb6JkKblLkOlN+UmB7tDRpJUvOi8EGtxYVks178U6mOZt vmeYg+y0aZdgUabeRF1ynGWTjgJXHxTJOf1JthOFEaCAhoUK+4ZUZkBdEHyv+BswlCXH ocww== 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=SCgyQ9eHHbv+RMv6VChalN/zKk5dTdLe/epnyzLq5Ig=; b=x5zYRHihZwG/puYapQyBTKQw1q2l3G35gcDRvexOI1HBGsavaQIAfRxR13qxQU/z6m XYJ/l9ud3F2E/cEwFGMFZB5SxQ/D2aZLeK88DJtNfDx59KzR7O4ej1SCbueP7gs4KS6D 64NTTpZI4jf0j3NGaJoqHfImkX/o7WVf17fU0NGULFox8g832KLo4zBXj6UY9pKcmVkZ NFV5Kmw9MFUshJJIU4gij+Z7Qmotz8pE0DZzVUpNx9o0I4azXe2tEZSprcJt0oHwxiRJ VHORTMq6Yw+kBawrKgPlpZgDdGD35r7rzRXLFY7kR559fHMiETKedFXFvR4YClBWzjXE y7+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=GKgquhT9; 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 h16si3851523otk.193.2020.02.22.15.20.59; Sat, 22 Feb 2020 15:21:12 -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=GKgquhT9; 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 S1726923AbgBVXUx (ORCPT + 99 others); Sat, 22 Feb 2020 18:20:53 -0500 Received: from mail-pl1-f195.google.com ([209.85.214.195]:33982 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726865AbgBVXUx (ORCPT ); Sat, 22 Feb 2020 18:20:53 -0500 Received: by mail-pl1-f195.google.com with SMTP id j7so2448449plt.1 for ; Sat, 22 Feb 2020 15:20:53 -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=SCgyQ9eHHbv+RMv6VChalN/zKk5dTdLe/epnyzLq5Ig=; b=GKgquhT9Rz+XgDRPEE1q4VXGPcr5n3heGESRTbtAd9yWqkSYrtuaGs+BY4KW4QfHv8 MEWJZe8IctQI537D4k54tWKkjQQiv6Yhn4P7nv5Nhs7jknhYJGgjYkZHH6kJcpwPb8Ui 29s2MQROlgaW1Ib5lSAZlYWuReeDIczG8bE//m9Vx4qLl01/mrD91NaaMwel2YwlQzdG MSsCiGz/yTwRxw2Yf0B5Wam21cY28Eg/eAiThDOfdalFDtL/cip8HzGalpgxCU2zoBhd sMUeyi+p76lE4G99vOgd/RBZ4fO+kRErv3cuJ3fGRRPYMsomyBUMUSQ+uZ4xMaDrdnwS mQxA== 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=SCgyQ9eHHbv+RMv6VChalN/zKk5dTdLe/epnyzLq5Ig=; b=pliwbpDv+b4MtWB29C8WEkw/8TSmxMooh6pJ05bqyjFsgiFd0vrsvxFSebhKWd6RaG l1A/k3M6GraW+ihH1ce6RKpq1l7u6L90UL9Umk0VEps/0pvayEqi2eDJKPrFtbY3cM9+ 5xULczYoEa+u3WNfullH7WrLXoqrwI4AOh2X/eWQSxmeibbOWfLbR6OWcLVO6mYFyvS1 ThMm7a4jpFrMEpyZOnDow5xkcyOPcbV/Qd2GCjLgbooRAXg+eojPYA961uqQ0IG2+EyO sXLfD54F/6Fkawe6coTyGUuWenDS5GZmb7qbje4IuwduAnpapLInwR3puQnbYYk7w/Qf DMNA== X-Gm-Message-State: APjAAAUDYkDrprAgHxj+h4d3mxhSoqY5DBFBhUaOMK1K4ztPuiV++zao d9gOU0h0mucIOaAlsBc852e2ESndS/0H+/xVR9H2Rw== X-Received: by 2002:a17:90a:3745:: with SMTP id u63mr11356233pjb.123.1582413652237; Sat, 22 Feb 2020 15:20:52 -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: <20200222162225.GA3326744@rani.riverdale.lan> From: Nick Desaulniers Date: Sat, 22 Feb 2020 15:20:39 -0800 Message-ID: Subject: Re: [PATCH 2/2] x86/boot/compressed: Remove unnecessary sections from bzImage To: Arvind Sankar , Fangrui Song Cc: Borislav Petkov , Nathan Chancellor , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , LKML , clang-built-linux , Michael Matz , 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 Sat, Feb 22, 2020 at 8:22 AM Arvind Sankar wrote: > > On Sat, Feb 22, 2020 at 08:42:54AM +0100, Borislav Petkov wrote: > > On Fri, Feb 21, 2020 at 11:21:44PM -0800, Fangrui Song 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. Kees is working on a series to just be explicit about what sections are ordered where, and what's discarded, which should better handle incompatibilities between linkers in regards to orphan section placement and "what does `*` mean." Kees, that series can't come soon enough. ;) (I think it's intended to help "fine grain" (per function) KASLR). More comments in the other thread. Taken from the Zen of Python, but in regards to sections in linker scripts, "explicit is better than implicit." -- Thanks, ~Nick Desaulniers