> On Oct 4, 2019, at 6:42 AM, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > On Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote: >>> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: >>> >> ... >>> >>> In the future, I would like to extend these interfaces to use static calls, >>> so that the accelerated implementations can be [un]plugged at runtime. For >>> the time being, we rely on weak aliases and conditional exports so that the >>> users of the library interfaces link directly to the accelerated versions, >>> but without the ability to unplug them. >>> >> >> As it turns out, we don't actually need static calls for this. >> Instead, we can simply permit weak symbol references to go unresolved >> between modules (as we already do in the kernel itself, due to the >> fact that ELF permits it), and have the accelerated code live in >> separate modules that may not be loadable on certain systems, or be >> blacklisted by the user. > > You're saying that at module insertion time, the kernel will override > weak symbols with those provided by the module itself? At runtime? > > Do you know offhand how this patching works? Is there a PLT that gets > patched, and so the calls all go through a layer of function pointer > indirection? Or are all call sites fixed up at insertion time and the > call instructions rewritten with some runtime patching magic? > > Unless the method is the latter, I would assume that static calls are > much faster in general? Or the approach already in this series is > perhaps fine enough, and we don't need to break this apart into > individual modules complicating everything? I admit I’m a bit mystified too. I think it would be great to have a feature where a special type of static call could be redirected by the module loader when a module that exports a corresponding symbol is loaded. Unloading such a module would be interesting. Ard, what exactly are you imagining?
