From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC PATCH 0/9] patchable function pointers for pluggable crypto routines Date: Fri, 5 Oct 2018 10:26:08 -0700 Message-ID: References: <20181005081333.15018-1-ard.biesheuvel@linaro.org> <20181005133705.GA4588@zx2c4.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: "Jason A. Donenfeld" , LKML , Eric Biggers , Samuel Neves , Andrew Lutomirski , Arnd Bergmann , Herbert Xu , "David S. Miller" , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Ingo Molnar , Kees Cook , "Martin K. Petersen" , Greg KH , Andrew Morton , Richard To: Ard Biesheuvel Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On Fri, Oct 5, 2018 at 10:15 AM Ard Biesheuvel wrote: > > On 5 October 2018 at 15:37, Jason A. Donenfeld wrote: > ... > > Therefore, I think this patch goes in exactly the wrong direction. I > > mean, if you want to introduce dynamic patching as a means for making > > the crypto API's dynamic dispatch stuff not as slow in a post-spectre > > world, sure, go for it; that may very well be a good idea. But > > presenting it as an alternative to Zinc very widely misses the point and > > serves to prolong a series of bad design choices, which are now able to > > be rectified by putting energy into Zinc instead. > > > > This series has nothing to do with dynamic dispatch: the call sites > call crypto functions using ordinary function calls (although my > example uses CRC-T10DIF), and these calls are redirected via what is > essentially a PLT entry, so that we can supsersede those routines at > runtime. If you really want to do it PLT-style, then just do: extern void whatever_func(args); Call it like: whatever_func(args here); And rig up something to emit asm like: GLOBAL(whatever_func) jmpq default_whatever_func ENDPROC(whatever_func) Architectures without support can instead do: void whatever_func(args) { READ_ONCE(patchable_function_struct_for_whatever_func->ptr)(args); } and patch the asm function for basic support. It will be slower than necessary, but maybe the relocation trick could be used on top of this to redirect the call to whatever_func directly to the target for architectures that want to squeeze out the last bit of performance. This might actually be the best of all worlds: easy implementation on all architectures, no inline asm, and the totally non-magical version works with okay performance. (Is this what your code is doing? I admit I didn't follow all the way through all the macros.) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F03E1C00449 for ; Fri, 5 Oct 2018 17:26:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B71352148D for ; Fri, 5 Oct 2018 17:26:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ogbD5313" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B71352148D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728755AbeJFA0E (ORCPT ); Fri, 5 Oct 2018 20:26:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:49376 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727941AbeJFA0D (ORCPT ); Fri, 5 Oct 2018 20:26:03 -0400 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DB5DB2147D for ; Fri, 5 Oct 2018 17:26:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1538760382; bh=BtUlJXPxzROTLh5ruMHdsHXX1cniMwLqNEy6YBOxFLs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ogbD53136bMyzbUp+AM5lY86M5wI4GC/2eqIE5nF/p9BR8+YU3qEI24enlHUImd+q 9VqU9PDHVrk6rVGLNNpQkQIEB+qE3rHEsqj7byjxw4Uaujs97vuzCA6VbNiMjafP3Y kkIGCzpCEFlTKHOQpIFhcZWVYqWLvVc6+x7Hqh00= Received: by mail-wr1-f54.google.com with SMTP id e4-v6so14364115wrs.0 for ; Fri, 05 Oct 2018 10:26:21 -0700 (PDT) X-Gm-Message-State: ABuFfohq6CKEQBBiFuMFdL8TJUPqD28x0gQ8o84imGdWXYdK/F06OrfM 36e6jAQGiFnKQ8PdQzetRIjZpeLcIZcMaIW0Z6hANw== X-Google-Smtp-Source: ACcGV63+AuOHy0b95rEYlVpCtCt0DDMWrn3Jmw20yMApLh17Axv0MfvrRS34XYxbDPUkWS2zSyBBjpgjCwN+kPowR7I= X-Received: by 2002:adf:82e3:: with SMTP id 90-v6mr8597642wrc.131.1538760380286; Fri, 05 Oct 2018 10:26:20 -0700 (PDT) MIME-Version: 1.0 References: <20181005081333.15018-1-ard.biesheuvel@linaro.org> <20181005133705.GA4588@zx2c4.com> In-Reply-To: From: Andy Lutomirski Date: Fri, 5 Oct 2018 10:26:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/9] patchable function pointers for pluggable crypto routines To: Ard Biesheuvel Cc: "Jason A. Donenfeld" , LKML , Eric Biggers , Samuel Neves , Andrew Lutomirski , Arnd Bergmann , Herbert Xu , "David S. Miller" , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Ingo Molnar , Kees Cook , "Martin K. Petersen" , Greg KH , Andrew Morton , Richard Weinberger , Peter Zijlstra , Linux Crypto Mailing List , linux-arm-kernel , linuxppc-dev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 5, 2018 at 10:15 AM Ard Biesheuvel wrote: > > On 5 October 2018 at 15:37, Jason A. Donenfeld wrote: > ... > > Therefore, I think this patch goes in exactly the wrong direction. I > > mean, if you want to introduce dynamic patching as a means for making > > the crypto API's dynamic dispatch stuff not as slow in a post-spectre > > world, sure, go for it; that may very well be a good idea. But > > presenting it as an alternative to Zinc very widely misses the point and > > serves to prolong a series of bad design choices, which are now able to > > be rectified by putting energy into Zinc instead. > > > > This series has nothing to do with dynamic dispatch: the call sites > call crypto functions using ordinary function calls (although my > example uses CRC-T10DIF), and these calls are redirected via what is > essentially a PLT entry, so that we can supsersede those routines at > runtime. If you really want to do it PLT-style, then just do: extern void whatever_func(args); Call it like: whatever_func(args here); And rig up something to emit asm like: GLOBAL(whatever_func) jmpq default_whatever_func ENDPROC(whatever_func) Architectures without support can instead do: void whatever_func(args) { READ_ONCE(patchable_function_struct_for_whatever_func->ptr)(args); } and patch the asm function for basic support. It will be slower than necessary, but maybe the relocation trick could be used on top of this to redirect the call to whatever_func directly to the target for architectures that want to squeeze out the last bit of performance. This might actually be the best of all worlds: easy implementation on all architectures, no inline asm, and the totally non-magical version works with okay performance. (Is this what your code is doing? I admit I didn't follow all the way through all the macros.) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53DD5C00449 for ; Fri, 5 Oct 2018 18:30:09 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 23BB42084D for ; Fri, 5 Oct 2018 18:30:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="WpyCaBkm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 23BB42084D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 42RdbK5c7MzDqCq for ; Sat, 6 Oct 2018 04:30:05 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="WpyCaBkm"; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=luto@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="WpyCaBkm"; dkim-atps=neutral Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 42Rc9s6LHGzF3Sb for ; Sat, 6 Oct 2018 03:26:25 +1000 (AEST) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DAB092148C for ; Fri, 5 Oct 2018 17:26:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1538760384; bh=BtUlJXPxzROTLh5ruMHdsHXX1cniMwLqNEy6YBOxFLs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WpyCaBkmY13bYCX9Dm6dlNgD3zKBzhcv59HVq1kD4kNNE2LhIPGlcgGJamww/O+Mu e/OcNrh8Zat9KbJXHeKrGHsLxwg6TWnrA9MDI4TlMU6vRGl8DbMpxV8wcSSwYOs4yW IUpIW9wWBPqj1fDQ+xA9cEMLO44CbSPEMoC1BIEY= Received: by mail-wr1-f42.google.com with SMTP id e4-v6so14364206wrs.0 for ; Fri, 05 Oct 2018 10:26:23 -0700 (PDT) X-Gm-Message-State: ABuFfogLRtJOxhj5WiMTfGJAUV6yOATCW7E5OmWHPSgTT4Ok+1AokeM3 uUvP8e8cxIokfRaGEB/gsx4GcyTpXYPX8U22lqbN6A== X-Google-Smtp-Source: ACcGV63+AuOHy0b95rEYlVpCtCt0DDMWrn3Jmw20yMApLh17Axv0MfvrRS34XYxbDPUkWS2zSyBBjpgjCwN+kPowR7I= X-Received: by 2002:adf:82e3:: with SMTP id 90-v6mr8597642wrc.131.1538760380286; Fri, 05 Oct 2018 10:26:20 -0700 (PDT) MIME-Version: 1.0 References: <20181005081333.15018-1-ard.biesheuvel@linaro.org> <20181005133705.GA4588@zx2c4.com> In-Reply-To: From: Andy Lutomirski Date: Fri, 5 Oct 2018 10:26:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/9] patchable function pointers for pluggable crypto routines To: Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Jason A. Donenfeld" , Peter Zijlstra , Catalin Marinas , Will Deacon , Samuel Neves , Paul Mackerras , Herbert Xu , Richard Weinberger , Eric Biggers , Ingo Molnar , Kees Cook , Arnd Bergmann , Andrew Lutomirski , Thomas Gleixner , linux-arm-kernel , "Martin K. Petersen" , Greg KH , LKML , Linux Crypto Mailing List , Andrew Morton , linuxppc-dev , "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Oct 5, 2018 at 10:15 AM Ard Biesheuvel wrote: > > On 5 October 2018 at 15:37, Jason A. Donenfeld wrote: > ... > > Therefore, I think this patch goes in exactly the wrong direction. I > > mean, if you want to introduce dynamic patching as a means for making > > the crypto API's dynamic dispatch stuff not as slow in a post-spectre > > world, sure, go for it; that may very well be a good idea. But > > presenting it as an alternative to Zinc very widely misses the point and > > serves to prolong a series of bad design choices, which are now able to > > be rectified by putting energy into Zinc instead. > > > > This series has nothing to do with dynamic dispatch: the call sites > call crypto functions using ordinary function calls (although my > example uses CRC-T10DIF), and these calls are redirected via what is > essentially a PLT entry, so that we can supsersede those routines at > runtime. If you really want to do it PLT-style, then just do: extern void whatever_func(args); Call it like: whatever_func(args here); And rig up something to emit asm like: GLOBAL(whatever_func) jmpq default_whatever_func ENDPROC(whatever_func) Architectures without support can instead do: void whatever_func(args) { READ_ONCE(patchable_function_struct_for_whatever_func->ptr)(args); } and patch the asm function for basic support. It will be slower than necessary, but maybe the relocation trick could be used on top of this to redirect the call to whatever_func directly to the target for architectures that want to squeeze out the last bit of performance. This might actually be the best of all worlds: easy implementation on all architectures, no inline asm, and the totally non-magical version works with okay performance. (Is this what your code is doing? I admit I didn't follow all the way through all the macros.) From mboxrd@z Thu Jan 1 00:00:00 1970 From: luto@kernel.org (Andy Lutomirski) Date: Fri, 5 Oct 2018 10:26:08 -0700 Subject: [RFC PATCH 0/9] patchable function pointers for pluggable crypto routines In-Reply-To: References: <20181005081333.15018-1-ard.biesheuvel@linaro.org> <20181005133705.GA4588@zx2c4.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Oct 5, 2018 at 10:15 AM Ard Biesheuvel wrote: > > On 5 October 2018 at 15:37, Jason A. Donenfeld wrote: > ... > > Therefore, I think this patch goes in exactly the wrong direction. I > > mean, if you want to introduce dynamic patching as a means for making > > the crypto API's dynamic dispatch stuff not as slow in a post-spectre > > world, sure, go for it; that may very well be a good idea. But > > presenting it as an alternative to Zinc very widely misses the point and > > serves to prolong a series of bad design choices, which are now able to > > be rectified by putting energy into Zinc instead. > > > > This series has nothing to do with dynamic dispatch: the call sites > call crypto functions using ordinary function calls (although my > example uses CRC-T10DIF), and these calls are redirected via what is > essentially a PLT entry, so that we can supsersede those routines at > runtime. If you really want to do it PLT-style, then just do: extern void whatever_func(args); Call it like: whatever_func(args here); And rig up something to emit asm like: GLOBAL(whatever_func) jmpq default_whatever_func ENDPROC(whatever_func) Architectures without support can instead do: void whatever_func(args) { READ_ONCE(patchable_function_struct_for_whatever_func->ptr)(args); } and patch the asm function for basic support. It will be slower than necessary, but maybe the relocation trick could be used on top of this to redirect the call to whatever_func directly to the target for architectures that want to squeeze out the last bit of performance. This might actually be the best of all worlds: easy implementation on all architectures, no inline asm, and the totally non-magical version works with okay performance. (Is this what your code is doing? I admit I didn't follow all the way through all the macros.)