Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1097690yba; Fri, 3 May 2019 16:11:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqysIm/sk06HSwT2d8QuVY4svZ9bDhYMvxu9axvUvlL8i32vdL4tfTDCFyK5IBKY2sGxPO+3 X-Received: by 2002:a62:1a0d:: with SMTP id a13mr14753692pfa.198.1556925074792; Fri, 03 May 2019 16:11:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556925074; cv=none; d=google.com; s=arc-20160816; b=Iweaab1lYpBpONiF5EkmtrA/njeQowD2jBj0676V2P4KO7PmNkx6Bf3AREtC5qHIGb iZSFWgh8JKhFwoAAxC5AdBksXx3W5PYdBjTxkl+vCPk6PGCJf0OX5J998w1niTX7cZPi EZHoRaUOdWHT59c1mZqSTQabA6Bfi1ycIXiTDpm/kuWR8+9WcBgCnBPgX/54pArJBewx hYtVtyvh3wPLgrg6vhe6ba3Fs7aVQsLdiYQO0ECGK/H/AwTYm/xg79ukIivPXqb23+ha jXzkc0IiL+0p6+LJ/Oe3siSYCfJvhbCBjOjNzApojl9hL0DERkoNerJgPMN5VoadkojS dOAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=PJAflPmQogNQpRfYKXa4wncPdUKgvcxegImOYQZ9y4M=; b=h0HMaCfBAR+wDO2UNf2LKX8O2yfVkhshMhSNi+OkAI6jJGjuA6x0Aoo8lTh1DDUhAg 6i0nCcBG4RWvirXDXYWvr5HwOCcY4Zh570RtkzxN8YVjb8XLxCEF2TsyxtZuA6qM9IzB hTP5tXIqa1wTiz+HmPU5Q51jdHz1Vor/rY8FjNY4iA4qC32tse9YBac74U4Ai/rcN967 3kzc2OU6fDVMTqujwZe66SuIeSRVxOzdboUqh2CYMsjFKT6fkfsQm4NhLPDy3pXHDt4O iY6CUBPK9za0ZpqcWQ2TNXo1PDmFnScFJrsinAzpIYNr0di/4gMHYEa3ZH1+3/qokZMC UjMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=YRB1C4a8; 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 cn19si5062232plb.400.2019.05.03.16.10.23; Fri, 03 May 2019 16:11:14 -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=@linux-foundation.org header.s=google header.b=YRB1C4a8; 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 S1726885AbfECXIU (ORCPT + 99 others); Fri, 3 May 2019 19:08:20 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:37919 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726042AbfECXIU (ORCPT ); Fri, 3 May 2019 19:08:20 -0400 Received: by mail-lf1-f65.google.com with SMTP id v1so5482285lfg.5 for ; Fri, 03 May 2019 16:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PJAflPmQogNQpRfYKXa4wncPdUKgvcxegImOYQZ9y4M=; b=YRB1C4a8aY6oNQ4Dcz6qJG4DjRq4rRf5c96hJky+mFEos14uxAjmg5IRtblz5Zm/+p AIWWkKxTm6hIurYsOfUWuKlPO3f3CKS4z4ENU/Uxi4oZSRGIkqbYn5VX66A1WW96OEeW VfyeY+ZH75pBqOv3uAMq5kkfebEdfOYQXUMAE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PJAflPmQogNQpRfYKXa4wncPdUKgvcxegImOYQZ9y4M=; b=q0o/nvQpdQGExiWh1S1EK9sF6ixGKVJrlWm6QH/+2pHtE12nzQSz0eNpIXL702sjkE xWE/uT3BxszhOX7JSfMKaEN+VbMrye9BA7DaKKqDLf4sl3HtkrhLdGavlZ+wuhb18y5h HVCNAaljUag0q+j/YDKiXthXRjZrf5bGVHHqxDtUQiK3ck7Dm6HL8t7+BUxqtquWzL0Q cWE7OLSO7SIbEUkYa3T4NZM+cF3aTcKJ0Sp6pIX/QG2jUsDk4JJ3uIrnQXxvH/TIJW80 8sszWHd3XauqIVYke5pRyXkDM8CeIqe8M/C9fjBgfSGMoF3aVdWWzeMJ5shumt5UBshF 9+bg== X-Gm-Message-State: APjAAAVIDSXhkvEkYlFVjiasfDhfcxW33fnONA/HFJMMUwre5K/1F/lw F30z332st0zDjBpQGVxkQz6kP79QoEw= X-Received: by 2002:ac2:50ca:: with SMTP id h10mr6556786lfm.31.1556924896866; Fri, 03 May 2019 16:08:16 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com. [209.85.208.170]) by smtp.gmail.com with ESMTPSA id v11sm655643lfb.68.2019.05.03.16.08.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2019 16:08:15 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id y8so6314047ljd.3 for ; Fri, 03 May 2019 16:08:15 -0700 (PDT) X-Received: by 2002:a2e:9a84:: with SMTP id p4mr6156404lji.22.1556924895019; Fri, 03 May 2019 16:08:15 -0700 (PDT) MIME-Version: 1.0 References: <20190501202830.347656894@goodmis.org> <20190501203152.397154664@goodmis.org> <20190501232412.1196ef18@oasis.local.home> <20190502162133.GX2623@hirez.programming.kicks-ass.net> <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190502202146.GZ2623@hirez.programming.kicks-ass.net> <20190503152405.2d741af8@gandalf.local.home> <20190503184919.2b7ef242@gandalf.local.home> In-Reply-To: <20190503184919.2b7ef242@gandalf.local.home> From: Linus Torvalds Date: Fri, 3 May 2019 16:07:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions To: Steven Rostedt Cc: Peter Zijlstra , 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 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, May 3, 2019 at 3:49 PM Steven Rostedt wrote: > > You are saying that we have a do_int3() for user space int3, and > do_kernel_int3() for kernel space. That would need to be done in asm > for both, because having x86_64 call do_int3() for kernel and > user would be interesting. The clean/simple way is to just do this - x86-32 does the special asm for the kernel_do_int3(), case and calls user_do_int3 otherwise. - x86-64 doesn't care, and just calls "do_int3()". We have a trivial helper function like dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code) { if (user_mode(regs)) user_int3(regs); else WARN_ON_ONCE(kernel_int3(regs) != regs); } which adds that warning just for debug purposes. Then we make the rule be that user_int3() does the normal stuff, and kernel_int3() returns the pt_regs it was passed in. Easy-peasy, there is absolutely no difference between x86-64 and x86-32 here except for the trivial case that x86-32 does its thing at the asm layer, which is what allows "kernel_int3()" to move pt_regs around by a small amount. Now, the _real_ difference is when you do the "call_emulate()" case, which will have to do something like this static struct pt_regs *emulate_call(struct pt_regs *regs, unsigned long return, unsigned long target) { #ifdef CONFIG_X86_32 /* BIG comment about how we need to move pt_regs to make room and to update the return 'sp' */ struct pt_regs *new = (void *)regs - 4; unsigned long *sp = (unsigned long *)(new + 1); memmove(new, regs, sizeof(*regs)); regs = new; #else unsigned long *sp = regs->sp; regs->sp -= 4; #endif *sp = value; regs->ip = target; return regs; } but look, the above isn't that complicated, is it? And notice how the subtle pt_regs movement is exactly where it needs to be and nowhere else. And what's the cost of all of this? NOTHING. The x86-32 entry code has to do the test for kernel space anyway, and *all* it does now is to call "kernel_int3" for the kernel case after having made a bit of extra room on the stack so that you *can* move pt_regs around (maybe people want to pop things too? It would work as well). See what I mean by "localized to the cases the need it"? Linus