From patchwork Wed Nov 8 03:24:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tobin Harding X-Patchwork-Id: 10047589 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5A7F56031B for ; Wed, 8 Nov 2017 03:24:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4D0012A341 for ; Wed, 8 Nov 2017 03:24:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 412802A360; Wed, 8 Nov 2017 03:24:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 4FCE72A341 for ; Wed, 8 Nov 2017 03:24:35 +0000 (UTC) Received: (qmail 28021 invoked by uid 550); 8 Nov 2017 03:24:34 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 27997 invoked from network); 8 Nov 2017 03:24:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tobin.cc; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=vFCUPUFCTm2oAgYhCBmiUyN3Y5ssEgjztxFKoNyxyIQ=; b=I9Z/lHwP 6Zzh6EK0gLCOUZYvDNKGrCi3OdbAycOIo05wTDsXPmQueuEdF7qXZMcAMSRiPxgF ++Y2Q/jipIsJ9bOS5pfsm7CT/MzIKr05GqVXXTF1g/L+w2wuHNKLq1V49mxhpJ7g qem4oTx/35UAuwURJvjeU7fuALyqqgSo/q1RsA4MEQzkC/NleZAtcR5zY0I/rRZ2 FxqNgJZwYFQulVzJQbmVLIqgd2Uj20v1cLW6LcYO22alAKtVpcNuluK1gtBU0+s2 DOHFcSlSD+wCRbKBXJFkuuVHyXds2Jhfo3WEGHJHdxqv6OEuKOx75iZiw0f4wB9Z iNpQi83Akhtk5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=vFCUPUFCTm2oAgYhCBmiUyN3Y5ssE gjztxFKoNyxyIQ=; b=demxr3g0UIR+UBGor2AWMWId2OvLwd17a+z23kmWS4jNf mncTx4GEkVpgqZ0VR/aLkzuPQd1Lm1dHPWcDVGAlgPxdFBD3Jv2ze0cJjkgRegt/ HeJrYWSUgGNPkhwh22SUcnSISeFl5dfZ/05JPo5jpajNXwDCQaH+cyFSS61ZecSz RItu4GYP23uSaZtjyWSavc0DD1jzZXVJ5U2JvE9IXApMGtPgqvXZv6Fdo9zdYnOL CZeewW9AbJ1KCAJMnBv7Ia5cLdO3HaXYu61MABpUcWLUC1QSvJGPueUv9sI/MQQ0 gYZASt4ZPiXcvMea2qXvg+9OSiTBSQVKrxX2zpYPg== X-ME-Sender: Date: Wed, 8 Nov 2017 14:24:18 +1100 From: "Tobin C. Harding" To: Linus Torvalds Cc: Network Development , David Miller , "kernel-hardening@lists.openwall.com" , "Jason A. Donenfeld" , Theodore Ts'o , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , Linux Kernel Mailing List Message-ID: <20171108032418.GB18478@eros> References: <1509945567-11801-1-git-send-email-me@tobin.cc> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Mailer: Mutt 1.5.24 (2015-08-30) User-Agent: Mutt/1.5.24 (2015-08-30) Subject: [kernel-hardening] Re: [PATCH v3] scripts: add leaking_addresses.pl X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Nov 06, 2017 at 09:27:09AM -0800, Linus Torvalds wrote: > On Sun, Nov 5, 2017 at 9:19 PM, Tobin C. Harding wrote: > > Currently we are leaking addresses from the kernel to user space. This > > script is an attempt to find some of those leakages. Script parses > > `dmesg` output and /proc and /sys files for hex strings that look like > > kernel addresses. > > Lovely. This is great. It shows just how much totally pointless stuff > we leak, and to normal users that really shouldn't need it. > > I had planned to wait for 4.15 to look at the printk hashing stuff > etc, but this part I think I could/should merge early just because I > think a lot of kernel developers will go "Why the f*ck would we expose > that kernel address there?" If we assume kptr_restrict is totally broken. Running this (with kptr_restrict==0 and outputting a summary) hints that plugging all these leaks is not an insurmountable problem. Perhaps we do not need to hash %p by default? If we add %pX (or what ever) that hashes the address then using the script to find the problems we can migrate to %pX as needed. This approach relies on a concrete concensus (do we have those ;) as to how and when we should print pointers. I just replied to you on that topic in another thread. This raises the issue that this hashing discussion is crazy fragmented and hard for people to follow (CC lists are different on a few of the threads also), is it correct protocol to patch Documentation with the concensus we have so far? --- Documentation/leaking_addresses.rst | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/leaking_addresses.rst diff --git a/Documentation/leaking_addresses.rst b/Documentation/leaking_addresses.rst new file mode 100644 index 000000000000..737a1b76b3f7 --- /dev/null +++ b/Documentation/leaking_addresses.rst @@ -0,0 +1,33 @@ +Leaking Kernel Addresses +======================== + +If we show kernel addresses to user space bad things can happen. + +Work in Progress +---------------- + +- Create a tool to scan the kernel for leaking addresses. + - Partially done, see scripts/leaking_addresses.pl +- Provide some sort of pointer hashing (i.e unique identifier). +- Move away from kptr_restrict (and %pK). +- Fix leaks on a case by case basis. + +WTF, just tell me how to print a pointer +---------------------------------------- + +Essentially you must consider _carefully_ who the needs to see the address and why. + +- If it is for profiling guard with perf_event_paranoid. +- If the file is intended for root-only, then guard via file permissions. +- If a unique identifier will suffice use hashing specifier (still to do). + +- If you really need the address ... + +Ideas +----- + +- Add a printk specifier that prints conditionally based on + perf_event_paranoid? + +- Add seq_printf_sanitize() that only shows addresses to root (based on the + permissions of the process that opens the file)?