From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kirill A. Shutemov" Subject: Re: [PATCH v4] scripts: add leaking_addresses.pl Date: Sun, 12 Nov 2017 02:10:07 +0300 Message-ID: <20171111231007.iirqce3r7xqqnxd3@node.shutemov.name> References: <1510050731-32446-1-git-send-email-me@tobin.cc> 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: <1510050731-32446-1-git-send-email-me@tobin.cc> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org 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. Not sure if we care. It won't work too for other 64-bit architectrues that have more than 256TB of virtual address space. Just wanted to point to the limitation. -- Kirill A. Shutemov