Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp559247imm; Fri, 5 Oct 2018 08:09:15 -0700 (PDT) X-Google-Smtp-Source: ACcGV63KauFXiZ6YlYjnx6FNe+ExXvdLgRDpTWKnoFaj3P7ar8lJUlEbR3YJT3XvRgSgrmICU09v X-Received: by 2002:a17:902:8f8f:: with SMTP id z15-v6mr9749392plo.305.1538752155314; Fri, 05 Oct 2018 08:09:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538752155; cv=none; d=google.com; s=arc-20160816; b=bxJvQxuG2LK9Z5woe7Sb+ra98PAxwPtkAyb/DeyiE5HU4aS37xRVaqJytScBRPCz+G YBxWKCcKAGKHOW1yc7AHGHXW/8DQe4Lze/arczOsqHLmHYTqHpC1l0crRLJFMy5scksk kARs0lf62HtwPDutHeHs9SkSeD3G8K0FckrkzTJQI7uIEh11BZGb9cMpm61TgmaNpUIT pBM+mjcrJnq7fe7JdDxdRd9F0NO5rvUJYj05m+PODTZEQOiobJYEhooH1Ny0FULSZrL6 6bQRKOuFz5CORvOa8r5txwtbBeWn0ZE6BFiYk+fkbY3jEU6FhnnQn4oyuQVudZQ8GUxy nCRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=alDE5Hfszt+ScKCD3O8u014AQQo/tXWyhSxaRXEN6Ok=; b=blhK7rzPQS+BIVnDLlFgXJbFFD97/ZQDWR4mIrQc+jEfIw+vHSunXveVOoW1mxByuK xAWb3nCsGobWfJSUhlIl9nNQWU5bVD9SXsv+/n7gxdyzuqewuuvvKClPsSwC9cxi4uHo 50pCThk75fIEZ2X27KAOO6d1uTw9Z8YectUezlB72mRzyUQ1UebJtwdEDVIJVPW2g+jQ KtREZo0qHF2V9WmfHM5GySxwFZMNS/If/T+HW7JAu7+CnIgpNNuMGTSDeNltqKL/LNIe jt5Z3AaaJ1aRDO9PVaFiTURML4N+fwJTV9Euxx8rEEtqKIMMm49dFCneqFgIn1jg7mof VPxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=EJivZJHy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p18-v6si8212648pgb.217.2018.10.05.08.08.59; Fri, 05 Oct 2018 08:09:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=EJivZJHy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728387AbeJEWHS (ORCPT + 99 others); Fri, 5 Oct 2018 18:07:18 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:34581 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727572AbeJEWHS (ORCPT ); Fri, 5 Oct 2018 18:07:18 -0400 Received: by mail-pg1-f194.google.com with SMTP id g12-v6so4888542pgs.1 for ; Fri, 05 Oct 2018 08:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=alDE5Hfszt+ScKCD3O8u014AQQo/tXWyhSxaRXEN6Ok=; b=EJivZJHyA5UUFgWMSowXL2LfrP1RKeHAoJS+LjY0JkvqHRZHu47bN7GLA+X3Pyh/Pp uGqX9EROhLmH6wI8LWSqODJgJMe387TJqgq9vUHti3BSgbhI3nUkpAkecJIVsTtrbDbX bynb5vA2ByZWlbUQJSlzFQiH4jz4oyd9n7rFSfjjP8XH7H1IRWg9muqJYanUnQch6Pqg cIvci/cf1oUT9FijZ0jU7cCUtAsmB2McZetaQT8tVTMdVwYMf2DWgxuSV3nPKSQuxbT2 sJ3duHEbE8fefCH/G5ZpIE/eorKz7m51r0SjWSQqPiuNB7DtSfC6y/QJQ4V5l2OYDAbk a6Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=alDE5Hfszt+ScKCD3O8u014AQQo/tXWyhSxaRXEN6Ok=; b=MZBpiWf9XIAgH4c10Ira/ploO0thPYpr89L3fgY106kH34sswi04B+LFjQeQfMQ0rt 1NOoSbnh2q1ghep7pxnPOJPEvSzUta9EvjH+/cFpKo56XYxKp9f2VfgnAYClWS/nacLD FT9+NU/1D3cYayj09x3dk9UkhAXVYDSWMYpgzYF2ryfwz1/iLqLN9t4Pg9VCWJSePsez pmmfsBMgxPAbsFmmKXpSWGsTuda4LGm+6tRcXOPwyObYup2T+WEOK0yzjrJaOtJImEKa g6RsLnQ1zMh78oICl7A6tLgyQHoESrq3fxoGNgsalgGFFgQVzknEKD31ZZ243y+QVaSE wqHA== X-Gm-Message-State: ABuFfohIuSzT2GNOgsGAfQf/VPhQ3aXO3q/Rj4fat7EGCeAZBv9eReSE 3tAY/7YzTz/X2nVBMmoi3oi6J9tsQ9Y= X-Received: by 2002:a62:18a:: with SMTP id 132-v6mr12403308pfb.207.1538752090767; Fri, 05 Oct 2018 08:08:10 -0700 (PDT) Received: from ?IPv6:2601:646:c200:7429:d01e:eb5d:f949:e221? ([2601:646:c200:7429:d01e:eb5d:f949:e221]) by smtp.gmail.com with ESMTPSA id v63-v6sm9761718pgd.69.2018.10.05.08.08.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 08:08:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH 1/9] kernel: add support for patchable function pointers From: Andy Lutomirski X-Mailer: iPhone Mail (16A366) In-Reply-To: <20181005141433.GS19272@hirez.programming.kicks-ass.net> Date: Fri, 5 Oct 2018 08:08:08 -0700 Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, "Jason A . Donenfeld" , Eric Biggers , Samuel Neves , Andy 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 Kroah-Hartman , Andrew Morton , Richard Weinberger , linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E0E08C8-0DFC-4E50-A4FA-73208835EF9E@amacapital.net> References: <20181005081333.15018-1-ard.biesheuvel@linaro.org> <20181005081333.15018-2-ard.biesheuvel@linaro.org> <20181005141433.GS19272@hirez.programming.kicks-ass.net> To: Peter Zijlstra Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Oct 5, 2018, at 7:14 AM, Peter Zijlstra wrote: >=20 >> On Fri, Oct 05, 2018 at 10:13:25AM +0200, Ard Biesheuvel wrote: >> diff --git a/include/linux/ffp.h b/include/linux/ffp.h >> new file mode 100644 >> index 000000000000..8fc3b4c9b38f >> --- /dev/null >> +++ b/include/linux/ffp.h >> @@ -0,0 +1,43 @@ >> +/* SPDX-License-Identifier: GPL-2.0 */ >> + >> +#ifndef __LINUX_FFP_H >> +#define __LINUX_FFP_H >> + >> +#include >> +#include >> + >> +#ifdef CONFIG_HAVE_ARCH_FFP >> +#include >> +#else >> + >> +struct ffp { >> + void (**fn)(void); >> + void (*default_fn)(void); >> +}; >> + >> +#define DECLARE_FFP(_fn, _def) \ >> + extern typeof(_def) *_fn; \ >> + extern struct ffp const __ffp_ ## _fn >> + >> +#define DEFINE_FFP(_fn, _def) \ >> + typeof(_def) *_fn =3D &_def; \ >> + struct ffp const __ffp_ ## _fn \ >> + =3D { (void(**)(void))&_fn, (void(*)(void))&_def }; \ >> + EXPORT_SYMBOL(__ffp_ ## _fn) >> + >> +static inline void ffp_set_target(const struct ffp *m, void *new_fn) >> +{ >> + WRITE_ONCE(*m->fn, new_fn); >> +} >> + >> +static inline void ffp_reset_target(const struct ffp *m) >> +{ >> + WRITE_ONCE(*m->fn, m->default_fn); >> +} >> + >> +#endif >> + >> +#define SET_FFP(_fn, _new) ffp_set_target(&__ffp_ ## _fn, _new) >> +#define RESET_FFP(_fn) ffp_reset_target(&__ffp_ ## _fn) >> + >> +#endif >=20 > I don't understand this interface. There is no wrapper for the call > site, so how are we going to patch all call-sites when you update the > target? I=E2=80=99m also confused. Anyway, we have patchable functions on x86. They=E2=80=99re called PVOPs, an= d they=E2=80=99re way overcomplicated. I=E2=80=99ve proposed a better way that should generate better code, be more= portable, and be more maintainable. It goes like this. To call the function, you literally just call the default implementation. I= t *might* be necessary to call a nonexistent wrapper to avoid annoying optim= izations. At build time, the kernel is built with relocations, so the object= files contain relocation entries for the call. We collect these entries int= o a table. If we=E2=80=99re using the =E2=80=9Cnonexistent wrapper=E2=80=9D a= pproach, we can link in a .S or linker script to alias them to the default i= mplementation. To patch them, we just patch them. It can=E2=80=99t necessarily be done conc= urrently because nothing forces the right alignment. But we can do it at boo= t time and module load time. (Maybe we can patch at runtime on architectures= with appropriate instruction alignment. Or we ask gcc for an extension to a= lign calls to a function.) Most of the machinery already exists: this is roughly how the module loader r= esolves calls outside of a module.=