Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2 00/20] crypto: crypto API library interfaces for WireGuard
Date:   Fri, 4 Oct 2019 07:50:09 -0700
Message-Id: <63B7E067-9D6D-4F42-940D-37EDFCDD2E80@amacapital.net>
References: <20191004134233.GD112631@zx2c4.com>
Cc:     Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        David Miller <davem@davemloft.net>,
        Greg KH <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Samuel Neves <sneves@dei.uc.pt>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Eric Biggers <ebiggers@google.com>,
        Andy Lutomirski <luto@kernel.org>,
        Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Martin Willi <martin@strongswan.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>
In-Reply-To: <20191004134233.GD112631@zx2c4.com>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk


> On Oct 4, 2019, at 6:42 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>=20
> =EF=BB=BFOn Thu, Oct 03, 2019 at 10:43:29AM +0200, Ard Biesheuvel wrote:
>>> On Wed, 2 Oct 2019 at 16:17, Ard Biesheuvel <ard.biesheuvel@linaro.org> w=
rote:
>>>=20
>> ...
>>>=20
>>> In the future, I would like to extend these interfaces to use static cal=
ls,
>>> so that the accelerated implementations can be [un]plugged at runtime. Fo=
r
>>> the time being, we rely on weak aliases and conditional exports so that t=
he
>>> users of the library interfaces link directly to the accelerated version=
s,
>>> but without the ability to unplug them.
>>>=20
>>=20
>> 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.
>=20
> You're saying that at module insertion time, the kernel will override
> weak symbols with those provided by the module itself? At runtime?
>=20
> 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?
>=20
> 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=E2=80=99m 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 modu=
le loader when a module that exports a corresponding symbol is loaded.  Unlo=
ading such a module would be interesting.

Ard, what exactly are you imagining?=