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.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 02C42C43441 for ; Thu, 29 Nov 2018 17:59:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B83A2213A2 for ; Thu, 29 Nov 2018 17:59:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B83A2213A2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.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 S1726577AbeK3FFN (ORCPT ); Fri, 30 Nov 2018 00:05:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:58454 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725821AbeK3FFM (ORCPT ); Fri, 30 Nov 2018 00:05:12 -0500 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F1E8F21019; Thu, 29 Nov 2018 17:58:58 +0000 (UTC) Date: Thu, 29 Nov 2018 12:58:57 -0500 From: Steven Rostedt To: Linus Torvalds Cc: Andy Lutomirski , Josh Poimboeuf , Peter Zijlstra , Andrew Lutomirski , "the arch/x86 maintainers" , Linux List Kernel Mailing , Ard Biesheuvel , Ingo Molnar , Thomas Gleixner , mhiramat@kernel.org, jbaron@akamai.com, Jiri Kosina , David.Laight@aculab.com, bp@alien8.de, julia@ni.com, jeyu@kernel.org, Peter Anvin Subject: Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64 Message-ID: <20181129125857.75c55b96@gandalf.local.home> In-Reply-To: References: <20181126160217.GR2113@hirez.programming.kicks-ass.net> <20181126171036.chcbmb35ygpxziub@treble> <20181126175624.bruqfbkngbucpvxr@treble> <20181126200801.GW2113@hirez.programming.kicks-ass.net> <20181126212628.4apztfazichxnt7r@treble> <20181127084330.GX2113@hirez.programming.kicks-ass.net> <20181129094210.GC2131@hirez.programming.kicks-ass.net> <20181129143853.GO2131@hirez.programming.kicks-ass.net> <20181129163342.tp5wlfcyiazwwyoh@treble> <0A629D30-ADCF-4159-9443-E5727146F65F@amacapital.net> <20181129121307.12393c57@gandalf.local.home> <20181129124404.2fe55dd0@gandalf.local.home> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Nov 2018 09:50:28 -0800 Linus Torvalds wrote: > On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote: > > > > Well, the current method (as Jiri mentioned) did get the OK from at > > least Intel (and that was with a lot of arm twisting to do so). > > Guys, when the comparison is to: > > - create a huge honking security hole by screwing up the stack frame > > or > > - corrupt random registers because we "know" they aren't in use > > then it really sounds pretty safe to just say "ok, just make it > aligned and update the instruction with an atomic cmpxchg or > something". Do you realize that the cmpxchg used by the first attempts of the dynamic modification of code by ftrace was the source of the e1000e NVRAM corruption bug. It's because it happened to do it to IO write only memory, and a cmpxchg will *always* write, even if it didn't match. It will just write out what it read. In the case of the e1000e bug, it read 0xffffffff and that's what it wrote back out. So no, I don't think that's a better solution. -- Steve > > Of course, another option is to just say "we don't do the inline case, > then", and only ever do a call to a stub that does a "jmp" > instruction. > > Problem solved, at the cost of some I$. Emulating a "jmp" is trivial, > in ways emulating a "call" is not. > > Linus