From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 8 Nov 2017 07:51:48 +1100 From: "Tobin C. Harding" Message-ID: <20171107205148.GW18478@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <20171107105027.GA1464@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171107105027.GA1464@kroah.com> Subject: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl To: Greg KH Cc: kernel-hardening@lists.openwall.com, "Jason A. Donenfeld" , Theodore Ts'o , Linus Torvalds , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , linux-kernel@vger.kernel.org, Network Development , David Miller List-ID: On Tue, Nov 07, 2017 at 11:50:27AM +0100, Greg KH wrote: > On Tue, Nov 07, 2017 at 09:32:11PM +1100, 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. > > > > Only works for 64 bit kernels, the reason being that kernel addresses > > on 64 bit kernels have 'ffff' as the leading bit pattern making greping > > possible. On 32 kernels we don't have this luxury. > > > > Scripts is _slightly_ smarter than a straight grep, we check for false > > positives (all 0's or all 1's, and vsyscall start/finish addresses). > > > > Output is saved to file to expedite repeated formatting/viewing of > > output. > > > > Signed-off-by: Tobin C. Harding > > --- > > > > This version outputs a report instead of the raw results by default. Designing > > this proved to be non-trivial, the reason being that it is not immediately clear > > what constitutes a duplicate entry (similar message, address range, same > > file?). Also, the aim of the report is to assist users _not_ missing correct > > results; limiting the output is inherently a trade off between noise and > > correct, clear results. > > > > Without testing on various real kernels its not clear that this reporting is any > > good, my test cases were a bit contrived. Your usage may vary. > > > > It would be super helpful to get some comments from people running this with > > different set ups. > > > > Please feel free to say 'try harder Tobin, this reporting is shit'. > > > > Thanks, appreciate your time, > > Tobin. > > > > v4: > > - Add `scan` and `format` sub-commands. > > - Output report by default. > > - Add command line option to send scan results (to me). > > As the script is already in Linus's tree, you might need to send a patch > on top of that, instead of this one, as this one will not apply anymore. Your awareness of what is going on never ceases to amaze me Greg, you're the man. thanks, Tobin. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933528AbdKGUvy (ORCPT ); Tue, 7 Nov 2017 15:51:54 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:36041 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932298AbdKGUvw (ORCPT ); Tue, 7 Nov 2017 15:51:52 -0500 X-ME-Sender: Date: Wed, 8 Nov 2017 07:51:48 +1100 From: "Tobin C. Harding" To: Greg KH Cc: kernel-hardening@lists.openwall.com, "Jason A. Donenfeld" , "Theodore Ts'o" , Linus Torvalds , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , linux-kernel@vger.kernel.org, Network Development , David Miller Subject: Re: [PATCH v4] scripts: add leaking_addresses.pl Message-ID: <20171107205148.GW18478@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <20171107105027.GA1464@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171107105027.GA1464@kroah.com> X-Mailer: Mutt 1.5.24 (2015-08-30) User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 07, 2017 at 11:50:27AM +0100, Greg KH wrote: > On Tue, Nov 07, 2017 at 09:32:11PM +1100, 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. > > > > Only works for 64 bit kernels, the reason being that kernel addresses > > on 64 bit kernels have 'ffff' as the leading bit pattern making greping > > possible. On 32 kernels we don't have this luxury. > > > > Scripts is _slightly_ smarter than a straight grep, we check for false > > positives (all 0's or all 1's, and vsyscall start/finish addresses). > > > > Output is saved to file to expedite repeated formatting/viewing of > > output. > > > > Signed-off-by: Tobin C. Harding > > --- > > > > This version outputs a report instead of the raw results by default. Designing > > this proved to be non-trivial, the reason being that it is not immediately clear > > what constitutes a duplicate entry (similar message, address range, same > > file?). Also, the aim of the report is to assist users _not_ missing correct > > results; limiting the output is inherently a trade off between noise and > > correct, clear results. > > > > Without testing on various real kernels its not clear that this reporting is any > > good, my test cases were a bit contrived. Your usage may vary. > > > > It would be super helpful to get some comments from people running this with > > different set ups. > > > > Please feel free to say 'try harder Tobin, this reporting is shit'. > > > > Thanks, appreciate your time, > > Tobin. > > > > v4: > > - Add `scan` and `format` sub-commands. > > - Output report by default. > > - Add command line option to send scan results (to me). > > As the script is already in Linus's tree, you might need to send a patch > on top of that, instead of this one, as this one will not apply anymore. Your awareness of what is going on never ceases to amaze me Greg, you're the man. thanks, Tobin. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tobin C. Harding" Subject: Re: [PATCH v4] scripts: add leaking_addresses.pl Date: Wed, 8 Nov 2017 07:51:48 +1100 Message-ID: <20171107205148.GW18478@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <20171107105027.GA1464@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kernel-hardening@lists.openwall.com, "Jason A. Donenfeld" , Theodore Ts'o , Linus Torvalds , Kees Cook , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein , Daniel Micay Return-path: Content-Disposition: inline In-Reply-To: <20171107105027.GA1464@kroah.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Tue, Nov 07, 2017 at 11:50:27AM +0100, Greg KH wrote: > On Tue, Nov 07, 2017 at 09:32:11PM +1100, 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. > > > > Only works for 64 bit kernels, the reason being that kernel addresses > > on 64 bit kernels have 'ffff' as the leading bit pattern making greping > > possible. On 32 kernels we don't have this luxury. > > > > Scripts is _slightly_ smarter than a straight grep, we check for false > > positives (all 0's or all 1's, and vsyscall start/finish addresses). > > > > Output is saved to file to expedite repeated formatting/viewing of > > output. > > > > Signed-off-by: Tobin C. Harding > > --- > > > > This version outputs a report instead of the raw results by default. Designing > > this proved to be non-trivial, the reason being that it is not immediately clear > > what constitutes a duplicate entry (similar message, address range, same > > file?). Also, the aim of the report is to assist users _not_ missing correct > > results; limiting the output is inherently a trade off between noise and > > correct, clear results. > > > > Without testing on various real kernels its not clear that this reporting is any > > good, my test cases were a bit contrived. Your usage may vary. > > > > It would be super helpful to get some comments from people running this with > > different set ups. > > > > Please feel free to say 'try harder Tobin, this reporting is shit'. > > > > Thanks, appreciate your time, > > Tobin. > > > > v4: > > - Add `scan` and `format` sub-commands. > > - Output report by default. > > - Add command line option to send scan results (to me). > > As the script is already in Linus's tree, you might need to send a patch > on top of that, instead of this one, as this one will not apply anymore. Your awareness of what is going on never ceases to amaze me Greg, you're the man. thanks, Tobin.