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.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 73670C004C9 for ; Tue, 7 May 2019 15:12:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4CE2F205C9 for ; Tue, 7 May 2019 15:12:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726978AbfEGPMd (ORCPT ); Tue, 7 May 2019 11:12:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:47564 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726556AbfEGPMc (ORCPT ); Tue, 7 May 2019 11:12:32 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 126A7205ED; Tue, 7 May 2019 15:12:28 +0000 (UTC) Date: Tue, 7 May 2019 11:12:27 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Peter Zijlstra , Andy Lutomirski , Linux List Kernel Mailing , Ingo Molnar , Andrew Morton , Andy Lutomirski , Nicolai Stange , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , Shuah Khan , Konrad Rzeszutek Wilk , Tim Chen , Sebastian Andrzej Siewior , Mimi Zohar , Juergen Gross , Nick Desaulniers , Nayna Jain , Masahiro Yamada , Joerg Roedel , "open list:KERNEL SELFTEST FRAMEWORK" , stable , Masami Hiramatsu Subject: Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions Message-ID: <20190507111227.1d4268d7@gandalf.local.home> In-Reply-To: References: <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190506145745.17c59596@gandalf.local.home> <20190506162915.380993f9@gandalf.local.home> <20190506174511.2f8b696b@gandalf.local.home> <20190506210416.2489a659@oasis.local.home> <20190506215353.14a8ef78@oasis.local.home> <20190506225819.11756974@oasis.local.home> <20190506232158.13c9123b@oasis.local.home> X-Mailer: Claws Mail 3.17.3 (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 Tue, 7 May 2019 07:54:53 -0700 Linus Torvalds wrote: > And honestly, I absolutely despise PeterZ's patch. The notion that we > should suddenly say that "oh, the i386 kernel stack is odd" after 28 > years of having that standard i386 stack is just crazy. And this: > > arch/x86/entry/entry_32.S | 136 ++++++++++++++++++++++++++++------- > ... > 12 files changed, 323 insertions(+), 140 deletions(-) > > > vs this: > > arch/x86/entry/entry_32.S | 7 +++- > ... > 6 files changed, 120 insertions(+), 13 deletions(-) > > is still pretty damn conclusive. Not to mention that the simple > approach had a truly mindbogglingly simple solution with no actual > subtle changes anywhere else. > > So I still claim that we should do my patch. Because it is SIMPLE. > It's straightforward, and I can explain every single line in it. Even > if I spent *way* too long until I realized that the "trivial" > memmove() wasn't so trivial. Yes, band-aids are usually simpler than a proper fix. We have 28 years of hacks built on hacks. There's a lot of hacks in the C code to handle the differences between the crappy way x86_32 does pt_regs and the proper way x86_64 does them. If the goal was just to add another band-aid to this, we now have one more subtle work around caused by two different methods being handled by a single code base. I don't look at Peter's patch and think "this is the solution for int3 emulate calls". I see Peter's patch as "Thanks God, we are finally getting rid of the cause of all theses work around hacks all over the place! and oh by the way, we can easily implement int3 call emulation because of it". To implement your way, we need to change how the int3 handler works. It will be the only exception handler having to return regs, otherwise it will crash. Sure, it's an easily solution for the one off change of emulating calls, but it's just another complex work around that nobody is going to understand in 5 years. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt at goodmis.org (Steven Rostedt) Date: Tue, 7 May 2019 11:12:27 -0400 Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions In-Reply-To: References: <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190506145745.17c59596@gandalf.local.home> <20190506162915.380993f9@gandalf.local.home> <20190506174511.2f8b696b@gandalf.local.home> <20190506210416.2489a659@oasis.local.home> <20190506215353.14a8ef78@oasis.local.home> <20190506225819.11756974@oasis.local.home> <20190506232158.13c9123b@oasis.local.home> Message-ID: <20190507111227.1d4268d7@gandalf.local.home> On Tue, 7 May 2019 07:54:53 -0700 Linus Torvalds wrote: > And honestly, I absolutely despise PeterZ's patch. The notion that we > should suddenly say that "oh, the i386 kernel stack is odd" after 28 > years of having that standard i386 stack is just crazy. And this: > > arch/x86/entry/entry_32.S | 136 ++++++++++++++++++++++++++++------- > ... > 12 files changed, 323 insertions(+), 140 deletions(-) > > > vs this: > > arch/x86/entry/entry_32.S | 7 +++- > ... > 6 files changed, 120 insertions(+), 13 deletions(-) > > is still pretty damn conclusive. Not to mention that the simple > approach had a truly mindbogglingly simple solution with no actual > subtle changes anywhere else. > > So I still claim that we should do my patch. Because it is SIMPLE. > It's straightforward, and I can explain every single line in it. Even > if I spent *way* too long until I realized that the "trivial" > memmove() wasn't so trivial. Yes, band-aids are usually simpler than a proper fix. We have 28 years of hacks built on hacks. There's a lot of hacks in the C code to handle the differences between the crappy way x86_32 does pt_regs and the proper way x86_64 does them. If the goal was just to add another band-aid to this, we now have one more subtle work around caused by two different methods being handled by a single code base. I don't look at Peter's patch and think "this is the solution for int3 emulate calls". I see Peter's patch as "Thanks God, we are finally getting rid of the cause of all theses work around hacks all over the place! and oh by the way, we can easily implement int3 call emulation because of it". To implement your way, we need to change how the int3 handler works. It will be the only exception handler having to return regs, otherwise it will crash. Sure, it's an easily solution for the one off change of emulating calls, but it's just another complex work around that nobody is going to understand in 5 years. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt@goodmis.org (Steven Rostedt) Date: Tue, 7 May 2019 11:12:27 -0400 Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions In-Reply-To: References: <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190506145745.17c59596@gandalf.local.home> <20190506162915.380993f9@gandalf.local.home> <20190506174511.2f8b696b@gandalf.local.home> <20190506210416.2489a659@oasis.local.home> <20190506215353.14a8ef78@oasis.local.home> <20190506225819.11756974@oasis.local.home> <20190506232158.13c9123b@oasis.local.home> Message-ID: <20190507111227.1d4268d7@gandalf.local.home> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190507151227.-L5mL_ihZ56kUbZlkNFqQoFfzfDH33NQ2uYqZmH48CQ@z> On Tue, 7 May 2019 07:54:53 -0700 Linus Torvalds wrote: > And honestly, I absolutely despise PeterZ's patch. The notion that we > should suddenly say that "oh, the i386 kernel stack is odd" after 28 > years of having that standard i386 stack is just crazy. And this: > > arch/x86/entry/entry_32.S | 136 ++++++++++++++++++++++++++++------- > ... > 12 files changed, 323 insertions(+), 140 deletions(-) > > > vs this: > > arch/x86/entry/entry_32.S | 7 +++- > ... > 6 files changed, 120 insertions(+), 13 deletions(-) > > is still pretty damn conclusive. Not to mention that the simple > approach had a truly mindbogglingly simple solution with no actual > subtle changes anywhere else. > > So I still claim that we should do my patch. Because it is SIMPLE. > It's straightforward, and I can explain every single line in it. Even > if I spent *way* too long until I realized that the "trivial" > memmove() wasn't so trivial. Yes, band-aids are usually simpler than a proper fix. We have 28 years of hacks built on hacks. There's a lot of hacks in the C code to handle the differences between the crappy way x86_32 does pt_regs and the proper way x86_64 does them. If the goal was just to add another band-aid to this, we now have one more subtle work around caused by two different methods being handled by a single code base. I don't look at Peter's patch and think "this is the solution for int3 emulate calls". I see Peter's patch as "Thanks God, we are finally getting rid of the cause of all theses work around hacks all over the place! and oh by the way, we can easily implement int3 call emulation because of it". To implement your way, we need to change how the int3 handler works. It will be the only exception handler having to return regs, otherwise it will crash. Sure, it's an easily solution for the one off change of emulating calls, but it's just another complex work around that nobody is going to understand in 5 years. -- Steve