From: Arvind Sankar <email@example.com> To: Kees Cook <firstname.lastname@example.org> Cc: "Arvind Sankar" <email@example.com>, "Thomas Gleixner" <firstname.lastname@example.org>, "Will Deacon" <email@example.com>, "Nick Desaulniers" <firstname.lastname@example.org>, "Jian Cai" <email@example.com>, "Fāng-ruì Sòng" <firstname.lastname@example.org>, "Luis Lozano" <email@example.com>, "Manoj Gupta" <firstname.lastname@example.org>, email@example.com, "Catalin Marinas" <firstname.lastname@example.org>, "Mark Rutland" <email@example.com>, "Ard Biesheuvel" <firstname.lastname@example.org>, "Peter Collingbourne" <email@example.com>, "James Morse" <firstname.lastname@example.org>, "Borislav Petkov" <email@example.com>, "Ingo Molnar" <firstname.lastname@example.org>, "Russell King" <email@example.com>, "Masahiro Yamada" <firstname.lastname@example.org>, "Nathan Chancellor" <email@example.com>, "Arnd Bergmann" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, "Andi Kleen" <email@example.com>, "Michal Marek" <firstname.lastname@example.org>, "Kristen Carlson Accardi" <email@example.com> Subject: Re: [PATCH v5 13/36] vmlinux.lds.h: add PGO and AutoFDO input sections Date: Sat, 1 Aug 2020 13:27:46 -0400 Message-ID: <20200801172746.GC3249534@rani.riverdale.lan> (raw) In-Reply-To: <202007312237.4F385EB3@keescook> On Fri, Jul 31, 2020 at 11:18:02PM -0700, Kees Cook wrote: > On Fri, Jul 31, 2020 at 11:51:28PM -0400, Arvind Sankar wrote: > > > > This also changes the ordering to place all hot resp unlikely sections separate > > from other text, while currently it places the hot/unlikely bits of each file > > together with the rest of the code in that file. That seems like a reasonable > > Oh, hmm, yes, we aren't explicitly using SORT() here. Does that mean the > input sections were entirely be ordered in compilation unit link order, > even in the case of orphan sections? (And I think either way, the answer > isn't the same between bfd and lld.) I actually thought the like-named > input sections were collected together first with lld, but bfd strictly > appended to the output section. I guess it's time for me to stare at -M > output from ld... I don't know what happened to the orphans previously. But .text.hot and .text.unlikely will now change ordering. It sounds from below like this wasn't intentional? Though it does seem to be how BFD's default linker scripts lay it out. > > Regardless, this patch is attempting to fix the problem where bfd and lld > lay out the orphans differently (as mentioned above, lld seems to sort > them in a way that is not strictly appended, and bfd seems to sort them > strictly appended). In the case of being appended to the .text output > section, this would cause boot failures due to _etext not covering the > resulting sections (which this also encountered and fixed to be more > robust for such appended collection -- that series actually _depends_ on > orphan handling doing the appending, because there is no current way > to map wildcard input sections to their own separate output sections). > > > change and should be mentioned in the commit message. > > > > However, the history of their being together comes from > > > > 9bebe9e5b0f3 ("kbuild: Fix .text.unlikely placement") > > > > which seems to indicate there was some problem with having them separated out, > > although I don't quite understand what the issue was from the commit message. > > Looking at this again, I actually wonder if we have bigger issues here > with dead code elimination: > > #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION > #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* > ... > > that would catch: .text.hot .text.fixup .text.unlikely and .text.unknown > but not .text.hot.*, etc (i.e. the third dot isn't matched, which is, > I assume, why Clang switched to adding a trailing dot). However, this > patch lists .text.hot .text.hot.* first, so they'd get pulled to the > front correctly, but the trailing ones (with 2 dots) would not, since > they'd match the TEXT_MAIN wildcard first. (This problem actually existed > before this patch too, and is not the fault of 9bebe9e5b0f3, but rather > the addition of TEXT_MAIN, which could potentially match .text.unlikely > and .text.fixup) The existing comment on TEXT_TEXT mentions that issue. However, note that the dead code stuff is only available currently on mips and ppc, and is hidden behind EXPERT for those, so I'm not sure if anyone actually uses it. 9bebe9e5b0f3 predates LD_DEAD_CODE_DATA_ELIMINATION, and there were no wildcards I can see in .text at the time, which is why I don't understand what problem is referred to in the commit message. Btw, for the FGKASLR stuff, instead of keeping the output sections per function, couldn't you generate a table of functions with sizes, and use that when randomizing the order? Then the sections themselves could be collected into .text explicitly.
next prev parent reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> 2020-07-31 23:07 ` Kees Cook 2020-08-01 3:51 ` Arvind Sankar 2020-08-01 6:18 ` Kees Cook 2020-08-01 17:27 ` Arvind Sankar [this message] 2020-08-03 19:05 ` Andi Kleen 2020-08-03 20:15 ` Arvind Sankar 2020-08-04 1:19 ` Fāng-ruì Sòng 2020-08-04 4:45 ` Andi Kleen 2020-08-04 5:32 ` Fāng-ruì Sòng 2020-08-04 16:06 ` Arvind Sankar 2020-08-06 1:24 ` Sasha Levin 2020-08-06 1:28 ` Nick Desaulniers
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200801172746.GC3249534@rani.riverdale.lan \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Stable Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/stable/0 stable/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 stable stable/ https://lore.kernel.org/stable \ email@example.com public-inbox-index stable Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.stable AGPL code for this site: git clone https://public-inbox.org/public-inbox.git