Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp3119584imc; Sat, 23 Feb 2019 20:40:22 -0800 (PST) X-Google-Smtp-Source: AHgI3IZZBnnNulrZePCR7fqlGtTeXZ1II4e7DIE6csD7VZ8M5eOsVcOfDxx0omyaGXJ9I/PHGjEo X-Received: by 2002:a63:69c2:: with SMTP id e185mr4058692pgc.4.1550983222039; Sat, 23 Feb 2019 20:40:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550983222; cv=none; d=google.com; s=arc-20160816; b=G0WdACv79pKAtygBG3bfza5F0FCOn9zt+9I4W31L42TQqeS5zyXiCnFonxNguCOwuc wdbWXYK56FxPrw+46rDwt0gsLOFhKgMcX2HbnorLp8f0rDaZl3c0WvNP+aNTvU97fQfa aJ+tqsJ9PGNwImK6ftJaLf/S8uKH1EhQbqF5U1dohpdNieQMK6atxsU5VgzV+Y2yzg+n dw2B+NDWDKj9DEAzRacQ/9MTE/dTcf6CyjHTHplRvgw/NliH4bbcmEsbjRIqevtzQ4Bi InlSM4UVq89ShvTLZ01nqM6Piq/wunsyBbdcmIrMsWBfwHxv8jr/BUcpruiKOq+eKp9/ 0GpQ== 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=zTxvCa5PD6AEVQk7KJiihOoZwKiboGLRQIT4nAeOWDc=; b=IOuqpn6nCfXe+4eBXcFbmfmS3l1rLquTGgPoHOtlXplQ95Aibr/xTS2vZmjWgJsFWJ 1aBBFklDwOY1f3XkrXvbTXFfz5MzZaTMkSEEJvqUSckQDpdRKaQP2tFTFANQ1+C6q0Pi GU+INHTb88N0hQLyk6T58sGK266zRUJhmjr70Nz+KtkrtUCnoRwDKDubXNSM4vs8o+c+ 0wPI+V47dOvCmNBRLHYg7Sdea36XAWfcBxbB+f9u3jgtLuaFMbJwSwgDK9Yb3LoBlMmg uA8yZEJiT6BKnWbcIic0COQ5RoHB9SnqKsC1hR4GNmVM36FKRV5GmWiOnpT8cdv+Xqvn G4iA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NNAPEBEI; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ci1si5626767plb.352.2019.02.23.20.39.30; Sat, 23 Feb 2019 20:40:22 -0800 (PST) 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=@kernel.org header.s=default header.b=NNAPEBEI; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728031AbfBXEiT (ORCPT + 99 others); Sat, 23 Feb 2019 23:38:19 -0500 Received: from mail.kernel.org ([198.145.29.99]:52428 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727800AbfBXEiS (ORCPT ); Sat, 23 Feb 2019 23:38:18 -0500 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E026F20880 for ; Sun, 24 Feb 2019 04:38:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550983098; bh=I0rIrmSR60dc4ryKHi9UYHHUli44sWLiycj03ohpd+c=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NNAPEBEIAJC8eTAxFxBCHnRQHdJm9KRdYhH0m0aFw0Q0mRAgoDfJj5c6WLAUGg8JR ivhY51HQNZ/3eLNH3JREuJiUZouz9uBqM/a/0FfMAF3Oqo1Of6HniUsIZ7v/vMbt7q B25Pj78fks2wdk3fEYmTJIBfQHyoh7cFuONF+HYw= Received: by mail-wm1-f44.google.com with SMTP id o10so542290wmc.1 for ; Sat, 23 Feb 2019 20:38:17 -0800 (PST) X-Gm-Message-State: AHQUAuaeUaHAvkRzKLZ47HDNaI9mvQcy9IOglYbmSifiKgpcqwe5Zxqp Thw5t+4mKSU0klJULyy7eMLHuRdxNNSOSjZzcXSyEQ== X-Received: by 2002:a1c:7906:: with SMTP id l6mr6549894wme.83.1550983096320; Sat, 23 Feb 2019 20:38:16 -0800 (PST) MIME-Version: 1.0 References: <20190215174712.372898450@goodmis.org> <20190215174945.557218316@goodmis.org> <20190215171539.4682f0b4@gandalf.local.home> <300C4516-A093-43AE-8707-1C42486807A4@amacapital.net> <20190215191949.04604191@gandalf.local.home> <20190219111802.1d6dbaa3@gandalf.local.home> <20190219140330.5dd9e876@gandalf.local.home> <20190220171019.5e81a4946b56982f324f7c45@kernel.org> <20190220094926.0ab575b3@gandalf.local.home> <20190222172745.2c7205d62003c0a858e33278@kernel.org> <20190222173509.88489b7c5d1bf0e2ec2382ee@kernel.org> <20190223124746.d021973004c7c892c3b3fde1@kernel.org> <20190223194421.725a03fd@oasis.local.home> In-Reply-To: <20190223194421.725a03fd@oasis.local.home> From: Andy Lutomirski Date: Sat, 23 Feb 2019 20:38:03 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault To: Steven Rostedt Cc: Masami Hiramatsu , Linus Torvalds , Linux List Kernel Mailing , Ingo Molnar , Andrew Morton , stable , Changbin Du , Jann Horn , Kees Cook , Andy Lutomirski 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 Sat, Feb 23, 2019 at 4:44 PM Steven Rostedt wrote: > > On Sat, 23 Feb 2019 12:47:46 +0900 > Masami Hiramatsu wrote: > > > Since kprobes handler runs in IRQ context, we can not use access_ok() in it. > > (only on x86 + CONFIG_DEBUG_ATOMIC_SLEEP=y) > > Is it really IRQ context or exception context? That is, one > (interrupts) happen for any task, but exceptions happen because of the > software that is executed (like a breakpoint). Although you can have a > kprobe trigger in an interrupt handler (where user access wouldn't make > sense anyway). But there should be no problem with user access from an > exception handler. > Can we just get rid of this might_sleep()? access_ok() doesn't sleep as far as I know.