From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751102AbdKLSDA (ORCPT ); Sun, 12 Nov 2017 13:03:00 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:49731 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbdKLSC6 (ORCPT ); Sun, 12 Nov 2017 13:02:58 -0500 X-Google-Smtp-Source: AGs4zMaeRXc6GpQ6UsYK6BGI4VZurJ1wJjmEnYVMUrAJQOmAr7Bdz9Dz3bm/diEtxi1+tRb2NN6wNw== Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl To: Michael Ellerman , "Tobin C. Harding" , kernel-hardening@lists.openwall.com Cc: "Jason A. Donenfeld" , "Theodore Ts'o" , Linus Torvalds , 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@vger.kernel.org, Network Development , David Miller References: <1510050731-32446-1-git-send-email-me@tobin.cc> <87k1z12cof.fsf@concordia.ellerman.id.au> <7fa01b32-4db0-3742-067b-955969020953@gmail.com> <87o9o7wwbl.fsf@concordia.ellerman.id.au> From: Frank Rowand Message-ID: <67c090b8-926a-1637-c335-863c068e62d0@gmail.com> Date: Sun, 12 Nov 2017 10:02:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <87o9o7wwbl.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michael, On 11/12/17 03:49, Michael Ellerman wrote: > Hi Frank, > > Frank Rowand writes: >> Hi Michael, Tobin, >> >> On 11/08/17 04:10, Michael Ellerman wrote: >>> "Tobin C. Harding" writes: >>>> 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. >>> >>> That doesn't work super well on other architectures :D >>> >>> I don't speak perl but presumably you can check the arch somehow and >>> customise the regex? >>> >>> ... >>>> +# Return _all_ non false positive addresses from $line. >>>> +sub extract_addresses >>>> +{ >>>> + my ($line) = @_; >>>> + my $address = '\b(0x)?ffff[[:xdigit:]]{12}\b'; >>> >>> On 64-bit powerpc (ppc64/ppc64le) we'd want: >>> >>> + my $address = '\b(0x)?[89abcdef]00[[:xdigit:]]{13}\b'; >>> >>> >>>> +# Do not parse these files (absolute path). >>>> +my @skip_parse_files_abs = ('/proc/kmsg', >>>> + '/proc/kcore', >>>> + '/proc/fs/ext4/sdb1/mb_groups', >>>> + '/proc/1/fd/3', >>>> + '/sys/kernel/debug/tracing/trace_pipe', >>>> + '/sys/kernel/security/apparmor/revision'); >>> >>> Can you add: >>> >>> /sys/firmware/devicetree >>> >>> and/or /proc/device-tree (which is a symlink to the above). >> >> /proc/device-tree is a symlink to /sys/firmware/devicetree/base > > Oh yep, forgot about the base part. > >> /sys/firmware contains >> fdt -- the flattened device tree that was passed to the >> kernel on boot >> devicetree/base/ -- the data that is currently in the live device tree. >> This live device tree is represented as directories >> and files beneath base/ >> >> The information in fdt is directly available in the kernel source tree > > On ARM that might be true, but not on powerpc. > > Remember FDT comes from DT which comes from OF - in which case the > information is definitely not in the kernel source! :) > > On our bare metal machines the device tree comes from skiboot > (firmware), with some of the content provided by hostboot (other > firmware), both of which are open source, so in theory most of the > information is available in *some* source tree. But there's still > information about runtime allocations etc. that is not available in the > source anywhere. Thanks for the additional information. Can you explain a little bit what "runtime allocations" are? Are you referring to the memory reservation block, the memory node(s) and the chosen node? Or other information? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Rowand Subject: Re: [kernel-hardening] [PATCH v4] scripts: add leaking_addresses.pl Date: Sun, 12 Nov 2017 10:02:55 -0800 Message-ID: <67c090b8-926a-1637-c335-863c068e62d0@gmail.com> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <87k1z12cof.fsf@concordia.ellerman.id.au> <7fa01b32-4db0-3742-067b-955969020953@gmail.com> <87o9o7wwbl.fsf@concordia.ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: "Jason A. Donenfeld" , Theodore Ts'o , Linus Torvalds , 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 , "Tobin C. Harding" , kernel-hardening@lists.openwall.com Return-path: In-Reply-To: <87o9o7wwbl.fsf@concordia.ellerman.id.au> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Hi Michael, On 11/12/17 03:49, Michael Ellerman wrote: > Hi Frank, > > Frank Rowand writes: >> Hi Michael, Tobin, >> >> On 11/08/17 04:10, Michael Ellerman wrote: >>> "Tobin C. Harding" writes: >>>> 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. >>> >>> That doesn't work super well on other architectures :D >>> >>> I don't speak perl but presumably you can check the arch somehow and >>> customise the regex? >>> >>> ... >>>> +# Return _all_ non false positive addresses from $line. >>>> +sub extract_addresses >>>> +{ >>>> + my ($line) = @_; >>>> + my $address = '\b(0x)?ffff[[:xdigit:]]{12}\b'; >>> >>> On 64-bit powerpc (ppc64/ppc64le) we'd want: >>> >>> + my $address = '\b(0x)?[89abcdef]00[[:xdigit:]]{13}\b'; >>> >>> >>>> +# Do not parse these files (absolute path). >>>> +my @skip_parse_files_abs = ('/proc/kmsg', >>>> + '/proc/kcore', >>>> + '/proc/fs/ext4/sdb1/mb_groups', >>>> + '/proc/1/fd/3', >>>> + '/sys/kernel/debug/tracing/trace_pipe', >>>> + '/sys/kernel/security/apparmor/revision'); >>> >>> Can you add: >>> >>> /sys/firmware/devicetree >>> >>> and/or /proc/device-tree (which is a symlink to the above). >> >> /proc/device-tree is a symlink to /sys/firmware/devicetree/base > > Oh yep, forgot about the base part. > >> /sys/firmware contains >> fdt -- the flattened device tree that was passed to the >> kernel on boot >> devicetree/base/ -- the data that is currently in the live device tree. >> This live device tree is represented as directories >> and files beneath base/ >> >> The information in fdt is directly available in the kernel source tree > > On ARM that might be true, but not on powerpc. > > Remember FDT comes from DT which comes from OF - in which case the > information is definitely not in the kernel source! :) > > On our bare metal machines the device tree comes from skiboot > (firmware), with some of the content provided by hostboot (other > firmware), both of which are open source, so in theory most of the > information is available in *some* source tree. But there's still > information about runtime allocations etc. that is not available in the > source anywhere. Thanks for the additional information. Can you explain a little bit what "runtime allocations" are? Are you referring to the memory reservation block, the memory node(s) and the chosen node? Or other information?