From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 18C8D3857C4F for ; Wed, 11 Oct 2023 17:23:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18C8D3857C4F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-6969b391791so5118319b3a.3 for ; Wed, 11 Oct 2023 10:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1697045028; x=1697649828; darn=sourceware.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=oZ6txKhambNh0CADcG+CZaHT9QYb4xZfPVtpCA0yr7U=; b=TxBqCMvUqO+PSdxylv+GQToS7eaje0fo4GvtMkO0/jmgl1wg4FgsHzNg/YcaIRAPCO zf4vdgJZB/BQmN5BHo1fy9ju+qRqxssXNfFMkPoQgRK0AMuZbxDFpfU5HvQ8LjDK2biC BHSUSh3wjZxF4lHqx2syzbrTk8sOCp+FeV0Aw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697045028; x=1697649828; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oZ6txKhambNh0CADcG+CZaHT9QYb4xZfPVtpCA0yr7U=; b=aAwMN5qxcF/J43S/3g3OUA+PRh+CE7Ac91DAelVZoXRJn1WP7E/qfnE3zWE4/2524W Ry8R7pKhHEHHtTFK9T+EPX1gjmqXPeAggKFN2ZR6Tg5wgcO+GoGEVYwXM/NwZ71KXx/U Usuj7/ownRVT74Y4rW/PgR4epNnjyZVBdv5Ced337s+IsR2HsscTAbchtaWQZOtHSZc/ 9M3Qj9gzRv1jgnFIuokSERUWQbX/A3WhDIlY3K1I/L612pN1zVGX7MoAcCbloHmz0fyv mA6ZPT0enEB+F+R0YkERdipgjzugNwFlVGXRmcZ9fDehzaIKAnzpWvZowXSkjfRBR2Is niiw== X-Gm-Message-State: AOJu0YyE5jcMo1GV9B4zF51DwOMmf23XZQ50vrGXVCSv1b+MT+zKbNIJ rtChYA0pWXY/DE6TiwjbFq2k+7QcEN4UqBBmOWU= X-Google-Smtp-Source: AGHT+IH5mUbcwR0KdveKRRtJ4lO1SXuJyl72643D0qxSViQ+QOIX683fuKKMPkT72MVhwVN3jlwJRg== X-Received: by 2002:a05:6a20:8e29:b0:171:6cb0:6295 with SMTP id y41-20020a056a208e2900b001716cb06295mr7127490pzj.43.1697045027992; Wed, 11 Oct 2023 10:23:47 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id t21-20020a639555000000b00583f73b7bcbsm118171pgn.58.2023.10.11.10.23.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 10:23:47 -0700 (PDT) Date: Wed, 11 Oct 2023 10:23:45 -0700 From: Kees Cook To: Nick Clifton Cc: binutils@sourceware.org, maskray@google.com Subject: Re: ld: provide /PASSTHRU/ section rule to avoid orphan warnings? Message-ID: <202310111006.5195BE8FF@keescook> References: <202308291330.05609E535@keescook> <8b17facc-30b7-ab24-efdd-6d094a57298d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b17facc-30b7-ab24-efdd-6d094a57298d@redhat.com> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Sep 04, 2023 at 01:12:18PM +0100, Nick Clifton wrote: > Hi Kees, Hi! Thanks for the looking at this and sorry I got distracted until now to reply to this. :) > > The Linux kernel would like to have a way for the linker to emit sections > > without changing their section name, using wildcards. > > I take it that it is hard/impossible for the kernel build process to know > beforehand what these section names will be ? If the build process did > know then it could probably use a linker script fragment to ensure that > they were copied through. It's certainly possible, but it's "extra work" that really doesn't seems to be done in the right place. "Make a list of all section names that are in the files that the linker is about to read where it finds the same list." :) More specifically, when this is done, we end up with a 65,000 line linker script, and the link stage (which normally takes a handful of seconds) ends up taking something like 10 minutes -- I assume the linker is doing repeated linear searches. So while that pathological condition could certainly be found it illustrates to me that listing all sections explicitly is going down the wrong solution path. > > Normally this happens automatically if a section > > doesn't match an existing rule, but then the --orphan-handling=warn > > option will report it. There is currently no way to silence these > > "expected sections". > > So one way to address this problem would be to extend the --orphan-handling > option so that it does not emit messages for certain sections. This has the > advantage of not needing to extend the linker script syntax. How about > something like --no-warn-orphan= option which could suppress warnings > for matching sections ? Or --orphan-handling=warn-except-text which would > warn for any unplaced section that is not executable ? Yeah, that could work, for sure. My instinct is that this would become ungainly over time, though, since we'd now be splitting section naming logic between the linker script and the command-line invocation, which we've never had to do before: all the section name patterns we're dealing with are only in the linker script right now. And as we start adding more than just .text.* to the pass-through list, we'll end up having to make the linker invocation more and more complex. Right now all of the section patterns are built with various macros and conditions in the linker script. Having to bring that out into the invocation seems like poor ergonomics. > > e.g. if we had something like: > > > > /PASSTHRU/ : { > > *(.text.*) > > } > > > > Then stuff like ".text.func1" and ".text.func2" will pass through as-is, > > but something unexpected, like ".other" would still get correctly > > reported by --orphan-handling=warn. > > I have a feeling that this solution would be difficult to implement since the > linker script processing is not really set up for generating an unknown number > of output sections from a single clause in the script. I am not 100% sure of > this though, since I have not actually tried to implement it. I assumed that it wouldn't be too hard since the orphan handling already does what we want: it just copies an input section to an identically named output section. I figured the patterns loaded from a "/PASSTHRU/" list would just be used to silence the orphan warning. > In theory the script extension seems like a good idea, although I do wonder > about section ordering. For example, suppose a script had this: > > /PASSTHRU/ : { *(.text.*) *(.init.*) } > > and then you have two input files - a.o containing .text.a.foo and .init.a.foo > and b.o containing .text.b.foo and .init.b.foo. In the resulting output, what > order should the sections appear ? > > .text.a.foo > .init.a.foo > .text.b.foo > .init.b.foo > > (assuming that a.o comes before b.o on the linker command line) or: > > .text.a.foo > .text.b.foo > .init.a.foo > .init.b.foo > > (because the .text.* pattern appears before the .init.* pattern in the linker script) > > Or maybe no ordering should be expected and the user gets whatever the linker > decides to do. Right -- I think the ordering is just whatever order the linker encounters the sections. The orphan handling appears to do this already (though it does seem to attempt to "group" similar stuff, but that's heuristic we don't depend on at all). Our use of /PASSTHRU/ very much doesn't care about ordering since we're literally going to randomize the order of those sections at load time anyway. :) But yes, I see why you'd want some kind of declaration of intended behavior. > Obviously it would be best if LLD and LD.BFD and LD.GOLD all supported the > same solution, so lets see if we can coordinate our response. Agreed! It was Fangrui Song who suggested I make sure LD.BFD was involved in the discussion, as I originally had just asked about LLD. (I'd wanted to gauge how difficult this feature would be.) So, as a strawman, how about this: - When warning about orphan sections, anything matching a /PASSTHRU/ rule is silenced (as it is now an 'expected' pass-through. - Therefore for ordering purposes the /PASSTHRU/ section behaves like it is "last" in the linker script, regardless of its actual position. -- Kees Cook