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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT 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 334C2C2BCA1 for ; Fri, 7 Jun 2019 17:42:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0AE8320652 for ; Fri, 7 Jun 2019 17:42:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="idQPdHad" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731535AbfFGRma (ORCPT ); Fri, 7 Jun 2019 13:42:30 -0400 Received: from merlin.infradead.org ([205.233.59.134]:49430 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728684AbfFGRma (ORCPT ); Fri, 7 Jun 2019 13:42:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Isgbg3AcMVxijCLxeP5g7ucIZ+WTg+Ln6Nf1BOjCEgY=; b=idQPdHadXoPujArpWO9WKxPZQq EOTPbSwN8kx68ck6JsJKGAOmpF9bGmv3mUwLg2wIMPamC6Sym7+0KRjYtHhmnSWKP9LbxjJRabdGR 7LEY46V9vbaE/sEHf0f33ZclYQYVBFYVgzYliD6PJqbd5rs4g4XlOJZiGJtrVWDYVlAlSw6GNJjYo kRxQq5oznlNQPUKEpvG7f4UC4RWlo8DSca3YcjLf5d7S5gNyKZ2y1mESMF4mxvGM+p4KQGCGKi/ns Hr/xNc8JxkJqqlUJ8bNJh8+pqFY/2XHNrUZRtPVl0qwts9/Wmq+qFCYDLr/LpYRWRJgGFNp9zomqP kfV8Cbcg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92 #3 (Red Hat Linux)) id 1hZIs1-00047J-Mf; Fri, 07 Jun 2019 17:41:41 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 8F11220227117; Fri, 7 Jun 2019 19:41:39 +0200 (CEST) Date: Fri, 7 Jun 2019 19:41:39 +0200 From: Peter Zijlstra To: Nadav Amit Cc: the arch/x86 maintainers , LKML , Ard Biesheuvel , Andy Lutomirski , Steven Rostedt , Ingo Molnar , Thomas Gleixner , Linus Torvalds , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov , Julia Cartwright , Jessica Yu , "H. Peter Anvin" , Rasmus Villemoes , Edward Cree , Daniel Bristot de Oliveira , Josh Poimboeuf Subject: Re: [PATCH 11/15] static_call: Add inline static call infrastructure Message-ID: <20190607174139.GL3436@hirez.programming.kicks-ass.net> References: <20190605130753.327195108@infradead.org> <20190605131945.193241464@infradead.org> <37CFAEC1-6D36-4A6D-8C44-F85FCFA053AA@vmware.com> <20190607083756.GW3419@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 07, 2019 at 04:35:42PM +0000, Nadav Amit wrote: > > On Jun 7, 2019, at 1:37 AM, Peter Zijlstra wrote: > > On Thu, Jun 06, 2019 at 10:24:17PM +0000, Nadav Amit wrote: > >>> + if (ret) { > >>> + WARN(1, "Failed to allocate memory for static calls"); > >>> + static_call_del_module(mod); > >> > >> If static_call_add_module() succeeded in changing some of the calls, but not > >> all, I don’t think that static_call_del_module() will correctly undo > >> static_call_add_module(). The code transformations, I think, will remain. > > > > Hurm, jump_labels has the same problem. > > > > I wonder why kernel/module.c:prepare_coming_module() doesn't propagate > > the error from the notifier call. If it were to do that, I think we'll > > abort the module load and any modifications get lost anyway. > > This might be a security problem, since it can leave indirect branches, > which are susceptible to Spectre v2, in the code. It's a correctness problem too; for both jump_label and static_call, since if we don't patch the call site, we also don't patch the trampoline and who knows what random code it ends up running. I'll go stare at the module code once my migrane goes again :/