From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751359AbdKLXGw (ORCPT ); Sun, 12 Nov 2017 18:06:52 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52025 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750943AbdKLXGu (ORCPT ); Sun, 12 Nov 2017 18:06:50 -0500 X-ME-Sender: Date: Mon, 13 Nov 2017 10:06:46 +1100 From: "Tobin C. Harding" To: "Kirill A. Shutemov" 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 , 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 Subject: Re: [PATCH v4] scripts: add leaking_addresses.pl Message-ID: <20171112230646.GM19752@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> 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 Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov 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. > > Well, it's not going to work as well as intented on x86 machine with > 5-level paging. Kernel address space there starts at 0xff10000000000000. > It will still catch pointers to kernel/modules text, but the rest is > outside of 0xffff... space. See Documentation/x86/x86_64/mm.txt. Thanks for the link. So it looks like we need to refactor the kernel address regular expression into a function that takes into account the machine architecture and the number of page table levels. We will need to add this to the false positive checks also. > Not sure if we care. It won't work too for other 64-bit architectrues that > have more than 256TB of virtual address space. Is this because of the virtual memory map? Did you mean 512TB? from mm.txt: ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB) Perhaps an option (--terse) that only checks the virtual memory map range (above for 5-level paging) and ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) for 4-level paging? > Just wanted to point to the limitation. Appreciate it, 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: Mon, 13 Nov 2017 10:06:46 +1100 Message-ID: <20171112230646.GM19752@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> 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 , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Steven Rostedt , Chris Fries , Dave Weinstein Return-path: Content-Disposition: inline In-Reply-To: <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov 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. > > Well, it's not going to work as well as intented on x86 machine with > 5-level paging. Kernel address space there starts at 0xff10000000000000. > It will still catch pointers to kernel/modules text, but the rest is > outside of 0xffff... space. See Documentation/x86/x86_64/mm.txt. Thanks for the link. So it looks like we need to refactor the kernel address regular expression into a function that takes into account the machine architecture and the number of page table levels. We will need to add this to the false positive checks also. > Not sure if we care. It won't work too for other 64-bit architectrues that > have more than 256TB of virtual address space. Is this because of the virtual memory map? Did you mean 512TB? from mm.txt: ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB) Perhaps an option (--terse) that only checks the virtual memory map range (above for 5-level paging) and ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) for 4-level paging? > Just wanted to point to the limitation. Appreciate it, thanks. Tobin. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 13 Nov 2017 10:06:46 +1100 From: "Tobin C. Harding" Message-ID: <20171112230646.GM19752@eros> References: <1510050731-32446-1-git-send-email-me@tobin.cc> <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> Subject: [kernel-hardening] Re: [PATCH v4] scripts: add leaking_addresses.pl To: "Kirill A. Shutemov" 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 , 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 List-ID: On Sun, Nov 12, 2017 at 02:10:07AM +0300, Kirill A. Shutemov 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. > > Well, it's not going to work as well as intented on x86 machine with > 5-level paging. Kernel address space there starts at 0xff10000000000000. > It will still catch pointers to kernel/modules text, but the rest is > outside of 0xffff... space. See Documentation/x86/x86_64/mm.txt. Thanks for the link. So it looks like we need to refactor the kernel address regular expression into a function that takes into account the machine architecture and the number of page table levels. We will need to add this to the false positive checks also. > Not sure if we care. It won't work too for other 64-bit architectrues that > have more than 256TB of virtual address space. Is this because of the virtual memory map? Did you mean 512TB? from mm.txt: ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB) Perhaps an option (--terse) that only checks the virtual memory map range (above for 5-level paging) and ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) for 4-level paging? > Just wanted to point to the limitation. Appreciate it, thanks. Tobin.