Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp44055pxb; Tue, 23 Feb 2021 17:29:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJx+RE7USsNd79xNb7J0CczdkxNxqS8Jf1Z3bqhtq1ISQENXlgAjW4D5HgIYQvlauaIdfkhY X-Received: by 2002:a17:906:b6cc:: with SMTP id ec12mr28935811ejb.520.1614130186007; Tue, 23 Feb 2021 17:29:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614130186; cv=none; d=google.com; s=arc-20160816; b=1JMi/MbWtNUEWQU+U+/fct6TuzyP7GYyxnn1XOAyAJ6GnTr2PWqEAZn67tZ6soamdR YnxCyD1NoAiVNGfmQI7AynNWcR9HtrtNzZHU5EvOIPj6RFrek/Y0emIDeHpU2rLVACLh X0+s2sZEeWIMdvX16APAUN4s03Gtsn9i1t2R6JD18mdvganNSJ6brZCcHHy1tl2odHRM ejMUqYntyJOYAn4LCQvcPaelHp/aEPNU248W6xvGOLwh9VN33OIw3oBkthVa5k0YxjiZ u/MWAt1NUl5C9bs+GLgOiAMN7fG/WRvSzigePCeokuiuFuaHJybpxYzPzmsjvrIZXA67 368Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=9jat+M64zwLkPpJ2LdvqAws+qnXozzZceplst4wVToM=; b=XzBoIQgky7Ta69tJMayJNlj7rrie7AUkkycK+HtU8o7RWyHB56QuFSNhqrTmKTuhgz 7opE23TH+3gUMrc/kl+e/MODyYeRDFFIsQm2LUWSug1h5apjfWl+Z+GMrQM1ik7SFK4r Q1+T502SD9fvHQ/uvaN68ZzxESLc44OviuprnCLeowbFZWu9wmOCjJcHmrm+GRkQf4Yc HWlLG629WmaztBu6FFsHIxnZjYr3hJf4uBYYa9Y6acYsboOBCIzV9Lw1O3KtWoz8twtu o2jUzTDcTudugiDAfTrV7/X3fg+7w1DW20OnIaDwnQTGVwHyxBZWzsdreYZgz0QXOkd+ Dd5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ueF7RoYx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t8si119232edy.573.2021.02.23.17.29.17; Tue, 23 Feb 2021 17:29:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ueF7RoYx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230498AbhBXBYr (ORCPT + 99 others); Tue, 23 Feb 2021 20:24:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:39702 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234266AbhBXBSr (ORCPT ); Tue, 23 Feb 2021 20:18:47 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 19AEA64E21; Wed, 24 Feb 2021 01:17:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614129480; bh=86XcHlF24lJqHiMo+fdjoQ2fYPikmlQK7DrPdc7bRno=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ueF7RoYxYz8iPaU9NGA6xd65paklKB+k8vqv8jFT+QWFq43XD+lcj/6kxXniAKOiu PmsB7JPU0LmUzK0EUjftALWmFJh3WBZvmx72CcyvOyRuyhKEDNa4MmY2C/sAw6FyKp GfTu9UUybxPsICc5zYkkdK1xQsoQaoRxEM1GKEU0EZ8X4RHVIhtzxnVSdLkGoxrIve V8psx+Tjstaj4FDhagIquZTKhphbUtu0j43qyOirMHlQ0R8C7b6bwX1NKKrKerfkVO TPI3nVhMyjW61EMM90NJTbubqXiUydLRSH10yluwNveTEqqLFGEs3ZnrZxPS38Y5Q0 /aRchvxKO1Sng== Date: Wed, 24 Feb 2021 10:17:56 +0900 From: Masami Hiramatsu To: Andy Lutomirski Cc: Oleg Nesterov , Peter Zijlstra , LKML , Anil S Keshavamurthy , "David S. Miller" , X86 ML , Andrew Cooper Subject: Re: Why do kprobes and uprobes singlestep? Message-Id: <20210224101756.bbdf95b9b6dfc982bff21324@kernel.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Feb 2021 15:24:19 -0800 Andy Lutomirski wrote: > A while back, I let myself be convinced that kprobes genuinely need to > single-step the kernel on occasion, and I decided that this sucked but > I could live with it. it would, however, be Really Really Nice (tm) > if we could have a rule that anyone running x86 Linux who single-steps > the kernel (e.g. kgdb and nothing else) gets to keep all the pieces > when the system falls apart around them. Specifically, if we don't > allow kernel single-stepping and if we suitably limit kernel > instruction breakpoints (the latter isn't actually a major problem), > then we don't really really need to use IRET to return to the kernel, > and that means we can avoid some massive NMI nastiness. Would you mean using "pop regs + popf + ret" instead of IRET after int3 handled for avoiding IRET releasing the NMI mask? Yeah, it is possible. I don't complain about that. However, what is the relationship between the IRET and single-stepping? I think we can do same thing in do_debug... > But I was contemplating the code, and I'm no longer convinced. > Uprobes seem to single-step user code for no discernable reason. > (They want to trap after executing an out of line instruction, AFAICT. > Surely INT3 or even CALL after the out-of-line insn would work as well > or better.) Why does kprobe single-step? I spend a while staring at > the code, and it was entirely unclear to me what the purpose of the > single-step is. For kprobes, there are 2 major reasons for (still relaying on) single stepping. One is to provide post_handler, another is executing the original code, which is replaced by int3, without modifying code nor emulation. Indeed, most of the instructions actually not depends on the ip register, in that case (and user doesn't set post_handler), kprobe already skips single stepping (a.k.a. kprobe booster, jump back to the kernel code after executing out-of-line instruction.) However, since some instructions, e.g. jump, call and ret, changes the ip register (and stack), we have to do a fixup afterwards. But yes, it is possible to emulate, as same as arm/arm64 does. I just concern about side-effects of the emulation, need to be carefully implemented. Thank you, -- Masami Hiramatsu