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=DKIM_SIGNED,DKIM_VALID, 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 55BD8C04AAA for ; Sat, 4 May 2019 20:12:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 23CD02063F for ; Sat, 4 May 2019 20:12:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="QuR1yzxQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727321AbfEDUMN (ORCPT ); Sat, 4 May 2019 16:12:13 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:44126 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727037AbfEDUMM (ORCPT ); Sat, 4 May 2019 16:12:12 -0400 Received: by mail-pl1-f195.google.com with SMTP id d3so345691plj.11 for ; Sat, 04 May 2019 13:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NCMi/IJcY48aFW4si21DdOI0x27Xmxnd2GdXSGtj0KE=; b=QuR1yzxQKn7DFRWWMR7fSBvuGvXauTjs+QWjPOOSysETTl7I7IUQZRZYJGQZEWrzXC aXLuopskBKG1lhvC6mZrbZ19GZQbAXZxbgrHcEY7Ne2rv2yRv1+wyy9Aed2EFweFh6sT MgUpM2KgnYL4er2RhJuziduNFgdJtQUuNY+rxGB6YYm4L5wZ1h2YrICNBMRWST/sIk1d x9FS2IhTzzNlLOEXa4KJ5A+G6yffez6cK9ONx3kgBDi79QMtaQN7mE+Ead5KYOCSP/ew B8BvOEnVYxCJoBIzbJDeiLf8mBt3Ri3eWcg7XWeNKx9f/9jOlgXQYd9q1O//WCtIlh13 V6Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NCMi/IJcY48aFW4si21DdOI0x27Xmxnd2GdXSGtj0KE=; b=S4Vl+VtW7aY8/KPZgtp/P+6868Ew+W6u6oMtltoT7vvj3pdhh32xVxZx84gkRYOpF/ BfQWTHFaGqCK7v1UaP/PvY/NtyvuPHWFcMjBoZAuy+V91kyer49m+JYHsQyCicofMOsM kiMqs+HdZIfJAq0zjFYweee3oAOMwfCL3jkFezHNV1xsDVvzrZTJAdjceUmsbqqWr+rs ndjJXaV4RMgwGSN0OtVSUXD6vqotCl5Tlbo7Jlw7hhW6yBulq8Tjn1jMdf86lKqmFStb 8R+YwHIjl88zUtJVq2/dUn3PCrwsYog5+w1lE1VflT34EQeH6eDVgpCbpzmNrFIJ/5OG id0Q== X-Gm-Message-State: APjAAAUYzVd3NqEcFXZaRga2Lve7foz11jTdf9PSufe2c05t6+TIzBPy PtvaenihsK6/kNMLCkFxKfyZ9A== X-Google-Smtp-Source: APXvYqxkMzmtMZymSQaZOjrq9gCEfLF9um4RJzYrrParpn8NStb9c8UxiLkvDWVFYtWVnpgI8AzCFg== X-Received: by 2002:a17:902:e293:: with SMTP id cf19mr21832986plb.151.1557000731668; Sat, 04 May 2019 13:12:11 -0700 (PDT) Received: from ?IPv6:2600:1010:b01f:7d2b:6939:d09e:b43f:2a80? ([2600:1010:b01f:7d2b:6939:d09e:b43f:2a80]) by smtp.gmail.com with ESMTPSA id c137sm8834253pfb.154.2019.05.04.13.12.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 May 2019 13:12:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions From: Andy Lutomirski X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Sat, 4 May 2019 13:12:09 -0700 Cc: Steven Rostedt , 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-Transfer-Encoding: quoted-printable Message-Id: <2BF1AE4B-8105-49F0-8B6A-AA3B11FD66FD@amacapital.net> 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> <20190504001756.17fad840@oasis.local.home> To: Linus Torvalds Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On May 4, 2019, at 11:59 AM, Linus Torvalds wrote: >=20 > On Fri, May 3, 2019 at 10:08 PM Linus Torvalds > wrote: >>=20 >> I'll look at it tomorrow, but I think this actually makes unnecessary cha= nges. >>=20 >> In particular, I think we could keep the existing entry code almost uncha= nged with this whole approach. >=20 > So here's what I *think* should work. Note that I also removed your > test-case code, because it really didn't have a chance in hell of > working. Doing that >=20 > int3_emulate_call(regs, (unsigned long)&int3_magic); >=20 > inside of int3_exception_notify() could not possibly be valid, since > int3_emulate_call() returns the new pt_regs that need to be used, and > throwing it away is clearly wrong. >=20 > So you can't use a register_die_notifier() to try to intercept the > 'int3' error and then do it manually, it needs to be done by the > ftrace_int3_handler() code that actually returns the new regs, and > where do_kernel_int3() will then return it to the low-level handler. I hate register_die_notifier(), so I consider this a plus. I=E2=80=99ve occa= sionally considered removing the ability for the notifiers to skip normal pr= ocessing, because, as it stands, figuring out what actually happens in the t= rap handlers is almost impossible. It generally looks sane to me. As an aside, is it even *possible* to get #BP from v8086 mode? On a quick S= DM read, the INT3 instruction causes #GP if VM=3D1 and IOPL<3. And, if we a= llow vm86() to have IOPL=3D3, we should just remove that ability. It=E2=80=99= s nuts. (We should maybe consider a config option for iopl() that defaults off. We=E2= =80=99ve supported ioperm() for a long, long time.)= From mboxrd@z Thu Jan 1 00:00:00 1970 From: luto at amacapital.net (Andy Lutomirski) Date: Sat, 4 May 2019 13:12:09 -0700 Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions In-Reply-To: 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> <20190504001756.17fad840@oasis.local.home> Message-ID: <2BF1AE4B-8105-49F0-8B6A-AA3B11FD66FD@amacapital.net> > On May 4, 2019, at 11:59 AM, Linus Torvalds wrote: > > On Fri, May 3, 2019 at 10:08 PM Linus Torvalds > wrote: >> >> I'll look at it tomorrow, but I think this actually makes unnecessary changes. >> >> In particular, I think we could keep the existing entry code almost unchanged with this whole approach. > > So here's what I *think* should work. Note that I also removed your > test-case code, because it really didn't have a chance in hell of > working. Doing that > > int3_emulate_call(regs, (unsigned long)&int3_magic); > > inside of int3_exception_notify() could not possibly be valid, since > int3_emulate_call() returns the new pt_regs that need to be used, and > throwing it away is clearly wrong. > > So you can't use a register_die_notifier() to try to intercept the > 'int3' error and then do it manually, it needs to be done by the > ftrace_int3_handler() code that actually returns the new regs, and > where do_kernel_int3() will then return it to the low-level handler. I hate register_die_notifier(), so I consider this a plus. I’ve occasionally considered removing the ability for the notifiers to skip normal processing, because, as it stands, figuring out what actually happens in the trap handlers is almost impossible. It generally looks sane to me. As an aside, is it even *possible* to get #BP from v8086 mode? On a quick SDM read, the INT3 instruction causes #GP if VM=1 and IOPL<3. And, if we allow vm86() to have IOPL=3, we should just remove that ability. It’s nuts. (We should maybe consider a config option for iopl() that defaults off. We’ve supported ioperm() for a long, long time.) From mboxrd@z Thu Jan 1 00:00:00 1970 From: luto@amacapital.net (Andy Lutomirski) Date: Sat, 4 May 2019 13:12:09 -0700 Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions In-Reply-To: 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> <20190504001756.17fad840@oasis.local.home> Message-ID: <2BF1AE4B-8105-49F0-8B6A-AA3B11FD66FD@amacapital.net> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190504201209.GtRIQtSpUc_TcTrsYXHFITJJ013maal0eEMMG8yo7Lc@z> > On May 4, 2019,@11:59 AM, Linus Torvalds wrote: > > On Fri, May 3, 2019 at 10:08 PM Linus Torvalds > wrote: >> >> I'll look at it tomorrow, but I think this actually makes unnecessary changes. >> >> In particular, I think we could keep the existing entry code almost unchanged with this whole approach. > > So here's what I *think* should work. Note that I also removed your > test-case code, because it really didn't have a chance in hell of > working. Doing that > > int3_emulate_call(regs, (unsigned long)&int3_magic); > > inside of int3_exception_notify() could not possibly be valid, since > int3_emulate_call() returns the new pt_regs that need to be used, and > throwing it away is clearly wrong. > > So you can't use a register_die_notifier() to try to intercept the > 'int3' error and then do it manually, it needs to be done by the > ftrace_int3_handler() code that actually returns the new regs, and > where do_kernel_int3() will then return it to the low-level handler. I hate register_die_notifier(), so I consider this a plus. I’ve occasionally considered removing the ability for the notifiers to skip normal processing, because, as it stands, figuring out what actually happens in the trap handlers is almost impossible. It generally looks sane to me. As an aside, is it even *possible* to get #BP from v8086 mode? On a quick SDM read, the INT3 instruction causes #GP if VM=1 and IOPL<3. And, if we allow vm86() to have IOPL=3, we should just remove that ability. It’s nuts. (We should maybe consider a config option for iopl() that defaults off. We’ve supported ioperm() for a long, long time.)