Re: [PATCH v2 00/20] crypto: crypto API library interfaces for WireGuard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux