[Top] [All Lists]

Re: [PATCH v6 2/8] module: use relative references for __ksymtab entries

To: Ard Biesheuvel <>
Subject: Re: [PATCH v6 2/8] module: use relative references for __ksymtab entries
From: Ingo Molnar <>
Date: Thu, 28 Dec 2017 13:05:31 +0100
Cc: Linus Torvalds <>, Linux Kernel Mailing List <>, "H. Peter Anvin" <>, Ralf Baechle <>, Arnd Bergmann <>, Heiko Carstens <>, Kees Cook <>, Will Deacon <>, Michael Ellerman <>, Thomas Garnier <>, Thomas Gleixner <>, "Serge E. Hallyn" <>, Bjorn Helgaas <>, Benjamin Herrenschmidt <>, Russell King <>, Paul Mackerras <>, Catalin Marinas <>, "David S. Miller" <>, Petr Mladek <>, Ingo Molnar <>, James Morris <>, Andrew Morton <>, Nicolas Pitre <>, Josh Poimboeuf <>, Steven Rostedt <>, Martin Schwidefsky <>, Sergey Senozhatsky <>, Jessica Yu <>,, linux-mips <>, ppc-dev <>, linux-s390 <>,, the arch/x86 maintainers <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=c8ThJi7Z19P8NCi218uOeC+PtbUEzzH9qTe4znqO9Jc=; b=OBLVxxbO8+Vx5UEpGux2MC8vFl4nwwfoRSJ52dKsoEiYzjd071J8LvFSYi7qNbwt6a NEuxZgCirVw7bw9ys3ISv3R3ffHJBRQpcBrpGE5i3syKHdM8H3/qDzj/+f6fE2LkWECG mlleRlqATnkBXP0QU0m2Uj42/JaMAi+qefSZorrBQKm3vlqt5Muq1aiS7ja7p0EZ/ocu tw4t8tgWAbm08elPVXHUFEhiCb8MiDAqN/xZ12TPFeF+qOszjXao9s6b9h27ObBCfjnP MyLFWcI6iGAFrrZ/LNpFht7axUJpypFaswfrBRrsC/AGjfUIThlJzXQeBFu5zptVJAQM ZR1w==
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
User-agent: NeoMutt/20170609 (1.8.3)
* Ard Biesheuvel <> wrote:

> Annoyingly, we need this because there is a single instance of a
> special section that ends up in the EFI stub code: we build lib/sort.c
> again as a EFI libstub object, and given that sort() is exported, we
> end up with a ksymtab section in the EFI stub. The sort() thing has
> caused issues before [0], so perhaps I should just clone sort.c into
> drivers/firmware/efi/libstub and get rid of that hack.
> [0] 

If the root problem is early bootstrap code randomly using generic facility 
isn't __init, then we should definitely improve tooling to at least detect 

As bootstrap code gets improved (KASLR, more complex decompression, etc. etc.) 
keep using new bits of generic facilities...

So this should definitely not be hidden by open coding that function (which has 
various other disadvantages as well), but should be turned from silent breakage 
either into non-breakage (and do so not only for sort() but for other generic 
functions as well), or should be turned into a build failure.



<Prev in Thread] Current Thread [Next in Thread>